The Class diagram shows the building blocks of any object-oriented system. Class diagrams describe the static view of the model or part of the model, describing what attributes and behaviors they have instead of detailing the methods to perform operations. Class diagrams are more useful to illustrate relationships between classes and interfaces. Generalizations, aggregations, and associations are all valuable in reflecting inheritances, composition or use, and connections respectively.
The following diagram illustrates aggregation relationships between classes. The addition of the arrowhead in lighter color indicates that the Account class uses AddressBook, but does not necessarily contain an instance of it. Compound aggregations with a darker arrowhead of the other connectors indicate membership or containment of the source classes by the target classes, for example the Contact and ContactGroup values will be contained in AddressBook.
A class is an element that defines the attributes and behaviors that an object can generate. The behavior is the one described by possible messages that the class can understand together with the operations that are appropriate for each message. Classes can also contain definitions of tagged values of constraints and stereotypes.
Classes are represented by rectangles that show the name of the class and optionally the name of the operations and attributes. The compartments are used to divide the name of the class, attributes and operations. Additionally, restrictions, initial values and parameters can be assigned to classes.
In the following diagram the class contains the name of the class in the highest compartment, the following compartment details the attributes, with the attribute “center” showing the initial values. The last compartment shows the operations, the setWidth, setLength and setPosition operations showing their parameters. The notation that precedes the name of the attribute or operation indicates the visibility of the element, if the symbol + the attribute and the operation have a public level of visibility, if a symbol is used – the attribute or operation is private. In addition, the # symbol allows you to define an operation or attribute as protected and the ~ symbol indicates the visibility of the packet.
An interface is a specification that implementers have agreed to perform. It is a contract. If an interface is made, it is guaranteed that the classes support a required behavior, which allows the system to treat the unrelated elements in the same way – that is, through the common interface.
The interfaces can be drawn in a style similar to that of a class, with operations specified as shown below. They can also be drawn as a circle with no detailed explicit operation. When drawn as a circle, realization links are drawn to the circle shape of the notation without target arrows.
A table is a stereotyped class. This is drawn with a small icon of the table in the upper right corner. The attributes of the table are stereotyped “columns”. Most tables will have a primary key, with one or more fields forming a unique combination used to access the table, plus a primary key operation that is “PK” stereotyped. Some tables will have one or more foreign keys, with one or more fields that together trace to a foreign key in a related table, plus a foreign key operation that is “FK” stereotyped.
An association implies that two elements of the model have a relation – usually implemented as an instance variable of a class. This connector can include named roles at each end, cardinality, address, and restrictions. An association is the kind of general relationship between elements. For more than two elements, an element of the diagonal representation toolbox can also be used. When code is generated for class diagrams, the associations are converted into instance variables in the target class.
A generalization is used to indicate inheritance. Drawn from a specific classifier to a general classifier, the general implication is that the origin inherits the characteristics of the destination. The following diagram shows a parent class generalizing a child class. Implicitly, an instantiated object of the Circle class will have attributes x_position, y_position and radius and a display () method. Keep in mind that the Class Form is abstract, shown by the name in italics.
Aggregations are used to describe elements that are made up of smaller components. Aggregation relationships are shown by a diamond-shaped arrowhead pointing to the destination or parent class.
A stronger form of aggregation – a composite aggregation – is shown by a black diamond shaped arrow and used where components can be included in a maximum of one composition at a time. If the parent of a compound aggregation is deleted, usually all its parts are removed with it; however, a part can be individually removed from a composition without having to remove the entire composition. The compositions are transitive, asymmetric relationships and can be recursive.
The following diagram illustrates the difference between strong and weak aggregations. An address book is made up of multiple contacts and contact groups; a contact can be included in more than one contact group. If you delete an address book, all contacts and contact groups will be deleted as well; If you delete a contact group, no contacts will be deleted.
An association class is a structure that allows an association connection to have connections and attributes. The following example shows that there is more to placing an employee to a project than to making a simple association link between two classes: the role that the employee takes in a project is a complex entity and contains details that do not belong to the employee or class of the project . For example, an employee may be working on many projects at the same time and have different job titles and levels of security.
A dependency is used to model a high rank of dependent relationships between elements of the model. This would normally be used early in the design process where it is known that there is some kind of link between two elements but it is too early to know exactly what the relationship is. Then in the design process, the dependencies will be stereotyped (available stereotypes include << instantiate >>, << trace >>, << import >> and others) or replace with a more specific type of connector.
The plot relationship is a specialization of a dependency, linking elements of the model or sets of elements that represent the same idea through the models. Paths are often used to track requirements and model changes. Because changes can occur in two directions, the order of this dependency is usually ignored. Relationship properties can specify path mapping, but the path is usually bi-directional, informal, and rarely computable.
The source object implements or performs the destination. Performing is used to express traceability and integrity in the model – a business process or requirements is performed by one or more use cases that in turn are performed by a component, etc. Assigning requirements, classes, etc. through the design of your system, up through the abstractions levels of the model, it ensures the large images of your system, remembers and reflects all the small images and details that restriction and defines it. A relationship is shown as a dashed line with a solid arrowhead and the << perform >> stereotype.
A nesting is a connector that shows that the source element is nested within the target element. The following diagram shows the definition of an internal class, although in EA it is more usual to show them by their position in the hierarchy of the Project View.