You model a reference from one class to another with an association, not with an attribute whose type is a class; this page is for MDriven Designer users defining class models.
Why a class cannot be an attribute type
An attribute describes a value that belongs to an object, such as a name, amount, date, or Boolean value. For example, a Product class can have attributes such as Name and Price.
A class represents objects. If an object needs to refer to an object of another class, that relationship is an object reference. In MDriven Designer, object references are modeled as associations. MDriven therefore prevents you from selecting a class as an attribute type by design.
| Requirement | Model it as | Example |
|---|---|---|
| Store a value on an object | Attribute | Product.Price is a number.
|
| Connect one object to another object | Association | A Product belongs to a Category.
|
| Show or calculate a value based on a related object | Derived attribute using OCL | An Order displays a customer name obtained through its customer association.
|
Create an association instead
For example, do not try to create an attribute named Category on Product with the type Category. Create an association between the Product and Category classes.
- In the class diagram, select the Association mode tool.
- Drag from the
Productclass to theCategoryclass. - Configure the association ends to express the relationship required by your model.
- Use the association when you need to navigate between the related objects in expressions or in a ViewModel.
The classes remain separate types. The association records that instances of those types are related; it does not turn one class into a scalar data type.
Example: customer and address
A customer can have an address. Model this as two classes, Customer and Address, connected by an association.
| Class | Appropriate attributes | Relationship |
|---|---|---|
Customer
|
Name, CustomerNumber
|
Associated with Address
|
Address
|
Street, PostalCode, City
|
Associated with Customer
|
Do not model the address as an attribute of type Address on Customer. The association lets the model represent the connection between customer and address, while the attributes on Address hold the address values.
When an attribute is still the right choice
Use an attribute when the information is a value rather than a separately modeled object. For example, use a text attribute for CategoryName only when the application needs to store text and does not need a Category object with its own attributes or relationships.
If you already have an association and need a convenient value for a screen or calculation, create a derived attribute and calculate it with OCL. Keep the association as the source of the object relationship. See Attribute for the available attribute kinds, including persisted, transient, and derived attributes.
Diagram visibility does not change the model
An association and its connected classes may be shown on more than one diagram. Hiding features on a diagram changes only what that diagram displays; it does not remove attributes or associations from the repository. For diagram display procedures, see Documentation:State Diagrams.