System Level Design Languages:Component Diagram

Component Diagram

Any system can be considered as a set of components. These components can be software or hardware parts. A component diagram (Figure 86.28) shows the relationship between components of a system, and consists of components and interfaces between them.

A component is a classifier that can include several class instances in run-time. Usually, components use interfaces to communicate with their outside environment. Interfaces are the same as those defined in composite structure diagrams. In UML, a component is displayed with a rectangle with the ((component)) stereotype, or a component icon on the top-right part of the component rectangle. An important advantage of a component is its reusability. Components already implemented in a component diagram can be reused in new designs. As an example, consider the SSimBoard system. If the driver for parallel ports is already implemented in a component diagram in a system, it can be reused elsewhere in the system.

The connection between every two components in a component diagram is performed by assembly connectors. Assembly connectors that connect provided and required interfaces (discussed in Section 86.1.3.7). Similar to structured classifiers, components can also have ports to share their services and requirements with other components in the system.

Class Diagram

A class diagram is a form of a structured diagram. This diagram illustrates classes and the static relationship between them.

A class, an example of which is shown in Figure 86.29, is a named element with several attributes and methods (or operations). A class in UML resembles the class concept in object-oriented languages. Attributes and operations of a class can be of type public (shown by +), private (shown by −), or protected (shown by #). There are special types of classes in UML such as an interface, discussed in Section 86.1.3.7. Another special class type is a table. A table may consist of several columns (with the ((column)) stereotype), primary keys (with the ((PK)) stereotype), and foreign keys (with the ((FK)) stereotype). A table is defined by the ((table)) stereotype.

Another important element in a class diagram is the relationship between two classes. There are different kinds of relationships between classes in a class diagram. A class can be derived from another class (parent class). In this situation, a generalization relationship exists from the child class to its parent class.

One class may have an instance of another class among its attributes. In this situation, an association relationship exists from one class to another. Associations have multiplicity at both ends. If there are attributes or operations suit to neither of the associated classes, then they can be assigned to the association itself. This kind of association is called an association class. A class diagram is shown in Figure 86.30.

A class can be composed of smaller components (for example, in C++, it can contain pointers to other classes). In this situation, an aggregation relationship is drawn between this class and its smaller components (see CKTAnalyzer and GUI in Figure 86.30). If two classes have an aggregation relationship, then the composite object (the GUI in Figure 86.30) is responsible for allocating and deallocating the composed object (CKTAnalyzer). This implies that if a composite object is deleted, then the composed object will also be destroyed.

If operations of a class are implemented by another class, then there is a realization relationship from the implementer class to the implemented one. An interface is a good example for realization. The example depicted in Figure 86.30 is part of the SSimBoard class diagram.

Object Diagram

An object is an instance of a class. An object diagram (Figure 86.31) can be considered as a special case of a class diagram. This diagram emphasizes on the relationship and the multiplicity of class instances in a specified time. Objects, in UML, are displayed with a rectangle with the name of the object followed by a colon followed by the name of its corresponding class. The name of an object must be underlined. In general, object elements cannot have attributes or operations, but in an object diagram they can show the contents of attributes or operation arguments in a specified time. A portion of an object diagram of the class diagram in Figure 86.30 is demonstrated in Figure 86.31.

Package Diagram

Packages are used to organize UML elements. For example, several related classes can be placed into a package. In this case, all of these classes are assumed to have one namespace (which implies that their names must be unique). Package diagrams show packages of a model and their relationships. They are generally used for organizing use-case and class diagrams.

A package usually shows a physical or logical relationship between a set of elements. For example, a set of classes with the same parent can be placed in a package. A package diagram related to our SSimBoard example is shown in Figure 86.32.

CKT Analyzer The connector between packages, in a package diagram, has three stereotypes. A connector with the ((merge)) type shows that all common attributes and operations between the source and the destination package are expanded in the source package.

A connector with the ((import)) type imports the elements of the target package into the source package. For example PPDriver is imported to the GUI in Figure 86.32. The namespace of the source package can access the target’s elements.

It is possible that a package contains another package. In this case nesting relationship exists between two packages. An example is the GUI and Circuit packages in Figure 86.32.