Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?
Search:         

Welcome to 3SL Reference Section

Class Diagrams Class Diagram (CD)

Class Diagram (CD)

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:

  • ATTRIBUTES
  • OPERATIONS

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:

  • Entity
  • Boundary
  • Control
  • Template
  • Utility

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:

       
  • A name for the relationship
  • A source label, which contains the cardinality of that class in the relationship, as an expression of the form:

 

 

quantity [..quantity]
where:

 

 

quantity is either a number, such as 0, 1 or 26. or * for any number

 

 

..quantity can optionally be used to specify a range and an upper bound
For example:

 

 

1 means exactly 1

 

 

6 means exactly 6

 

 

0..1 means zero or 1

 

 

1..* means any number but at least 1

 

 

0..* means any number but excluding 0
The source label (source class cardinality) is drawn next to the source class and either below or to the left of the relationship
  • A destination label, which contains the cardinality of the destination class is the relationship, as an expression of the form:

 

 

quantity [..quantity]
The destination label (destination class cardinality) is drawn next to the destination class and either below, or to the left of, the relationship
  • A source role, which identifies the role that the source class plays in the relationship with a meaningful name. It is drawn next to the source class and either above, or to the right of, the relationship.
  • A destination role, which identifies the role that the destination class plays in the relationship with a meaningful name. It is drawn next to the destination class and either above, or to the right 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:

Diagram showing the connectivity of a Class Diagram

CDs are available in models in both the Essential and Implementation Domains.

Numbering of CDs

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.

Symbols

An example CD is:

Screenshot of a Class Diagram

The symbols available in CDs are:

Symbol Name Description Definition Expansion

Comment

Comment Makes a note anywhere in the diagram. Are always surrounded by * characters. None None

Class

Class A set of objects with similar structure, behaviour, and relationships. Class
specification
SCD
ACD

Boundary Class

Boundary Class A class whose primary role is to interface with the system environment, a stereotype of class. Class
specification
SCD
ACD

Control Class

Control Class A class whose primary role is to co-ordinate and manage the system behaviour, a stereotype of class. Class
specification
SCD
ACD

Entity Class

Entity Class A class whose primary role is to manage a set of data objects, a stereotype of class. Class
specification
SCD
ACD

Template Class

Template Class A class with one or more unbound formal parameters. Class
specification
SCD
ACD

Utility Class

Utility Class A class that supplies utility behaviour, a stereotype of class. Class
specification
SCD
ACD

Relationship Node

Relationship Node A symbol used to join classes in tertiary or higher relationships, in particular for association classes. None None

Bidirectional Association

Bidirectional Association A bidirectional relationship between classes that involves connections among their instances. Associations may have names, source and destination labels, and source and destination roles. None None

Directional Association

Directional Association Unidirectional association between classes. None None

Bidirectional Aggregation

Bidirectional Aggregation A special form of bidirectional association that specifies a whole-part relationship between the aggregate (whole) and a component part. None None

Directional Aggregation

Directional Aggregation A unidirectional aggregation. None None

Bidirectional Composition

Bidirectional Composition Aggregation with strong ownership and coincident lifetime as part of the whole. None None

Directional Composition

Directional Composition A unidirectional composition. None None

Inheritance Relationship

Inheritance Relationship The mechanism by which more specific elements incorporate structure and behaviour of more general elements related by behaviour. None None

Class Dependency

Class Dependency A relationship between classes. None None

Association Class Link

Association Class Link A link that joins an association class to a relationship node used to create associative relationships between the association class and two or more other classes. None None

Picture

Picture Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. None None