Username:
Password:
Please type the Two words with a space between them to prove you are a real human being.
The Class Diagram (CD) is the heart of any UML modelling activity. CDs are used to identify classes, to characterise these classes, and to define the relationships between them.
Each CD is likely to start in a relatively superficial way, and acquires additional detail as its classes are fully elaborated in appropriate cycles of the development process.
A CD contains classes which have a name and are defined by specifications. The specification for a class is mandatory, because Cradle stores the set of class attributes and operations not within the CD(s) in which the class is shown, but within frames of the specifications, which are called:
On the CD, the ATTRIBUTES and OPERATIONS frames are displayed in the class symbols if the CD is shown in Definitions display mode in the diagram.
Each instance of a class on a CD may have a different symbolic representation, in that a per-instance filter is used by the user to specify which (if any) of the attributes and operations are to be shown, and how much of each is to be shown.
A class may appear on one or more CDs, and potentially more than once on any such CD if desired. A class is said to be defined in the package that contains it, but may be declared within (i.e. used within) any other package that the designer requires. It is usual for the definition of the class to show its attributes and operations in full details, whereas uses of the class in other packages do not show the full detail.
A class may be an instance of a stereotype such as:
The CDs will initially show only terse details of classes, but as the iterative development progresses, the contents of the CDs will become increasingly detailed including, for example, full signatures (including data types and default values) of each class attribute, and full signatures (similar to procedure/function call interfaces) of all class operations. Because Cradle allows CDs in both its analysis and design models, it is expected that users will exploit this flexibility, and will not elaborate Essential Domain CDs to a greater extent than is consistent with the scope of analysis work.
Classes exhibit relationships with other classes. These relationships range from a simple association, through a part-of aggregation or composition relationships, to kind-of inheritance relationships. These relationships are shown in CDs by appropriate types of connection symbol, linking the classes together. However, unlike other connection symbols, these class relationships have 5 parts to their text notation:
where:
For example:
The source label (source class cardinality) is drawn next to the source class and either below or to the left of the relationship
The destination label (destination class cardinality) is drawn next to the destination class and either below, or to the left of, the relationship
As the elaboration of CDs evolves, navigation can be added to the relationships, by replacing them by corresponding symbols that include arrowheads. The navigation for a relationship indicates the direction in which it can be queried. By default, relationships are bidirectional.
CDs are not hierarchical. Their connectivity is:
CDs are available in models in both the Essential and Implementation Domains.
A CD is the expansion of a package. A CD has a name and a number which are both the same as the name of this package. CDs are essentially separate from, and shared by, all of the OO models in a Cradle modelling domain. A CD may be shared between OO models by including a package with the CD’s package name in the Logical View Package Diagram (PD) hierarchy of more than one OO model.
An example CD is:
The symbols available in CDs are:
