Scope
Features (aka properties, aka attributes) describe disembodied characteristics to be associated with individual objects, transient or persistent. Contrary to object and activity types, whose instances can be identified within business contexts, features are pure descriptions of format and semantics, without individual identity of their own, whatever their eventual implementation as system objects.
Format and Semantics
Being tied up to object representations, features have no direct impact on system architectures, yet their interpretation may, depending on what is required to interpret them:
- Literals are symbolic features which can be processed locally .
- Physical features (aka binary objects) can also be processed locally but they must be bound to some analogical device as the source of their value.
- Coded features cannot be processed locally and must associated to some logical device before being interpreted.
- References (non structural connectors) don’t have to be interpreted but cannot be processed locally.
While features can be structured (composite or repeated values), they should not be confused with objects, at least before system objects are introduced, which is not before design.
Structural vs Derived Features
Structural features describe intrinsic values directly associated to individual objects, derived features are computed from structural ones as recorded by symbolic representations. Among derived features, a clear distinction should be maintained between those computed locally and views computed on associated objects with identities of their own, which should be defined as operations.
Features and Model Driven Engineering
Since features are local artifacts without direct counterpart in business context, their development life-cycle can be subsumed within the one of objects, persistent or transient. Hence, providing their dependencies are properly documented, features don’t have to be managed at architecture level. That will enable a layered definition of business rules. More generally, their update can bypass the upper level of model transformation.
Remy: I have come here through a link you provided as answer to my question: Can HOLE be a part of an Object?
This is OK but can features be described without referring to their implementation (programming) interpretations just as concepts for modeling the real-world and or computational systems? That’s how OOAD was introduced.
I am unable to use this information to answer my original question. Thanks for the help.
The litmus test is: is it (1) possible and (2) required, to manage that piece of information by itself. The answer has nothing to do with implementation but, as illustrated by addresses, may not be the same depending on business.