When it comes to system construction, a class diagram is the most widely used diagram. This diagram generally consists of interfaces, classes, associations and collaborations. Such a diagram would illustrate the object-oriented view of a system, which is static in nature. The object orientation of a system is indicated by a class diagram.
Since class diagrams are used for many different purposes, such as making stakeholders aware of requirements to highlighting your detailed design, you need to apply a different style in each circumstance.
The points that are going to be covered are indicated as follows:
- General issues
- Aggregation and Composition
UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying, constructing and documenting the components of software and non-software systems. Hence, visualization is the most important part which needs to be understood and remembered.
UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. The model is useless, unless its purpose is depicted properly.
Hence, learning notations should be emphasized from the very beginning. Different notations are available for things and relationships. UML diagrams are made using the notations of things and relationships. Extensibility is another important feature which makes UML more powerful and flexible.
The chapter describes basic UML notations in detail. This is just an extension to the UML building block section discussed in Chapter Two.
Graphical notations used in structural things are most widely used in UML. These are considered as the nouns of UML models. Following are the list of structural things.
- Use case
- Active classes
UML class is represented by the following figure. The diagram is divided into four parts.
- The top section is used to name the class.
- The second one is used to show the attributes of the class.
- The third section is used to describe the operations performed by the class.
- The fourth section is optional to show any additional components.
Classes are used to represent objects. Objects can be anything having properties and responsibility.
The object is represented in the same way as the class. The only difference is the name which is underlined as shown in the following figure.
As the object is an actual implementation of a class, which is known as the instance of a class. Hence, it has the same usage as the class.
Interface is represented by a circle as shown in the following figure. It has a name which is generally written below the circle.
Interface is used to describe the functionality without implementation. Interface is just like a template where you define different functions, not the implementation. When a class implements the interface, it also implements the functionality as per requirement.
Collaboration is represented by a dotted eclipse as shown in the following figure. It has a name written inside the eclipse.
Collaboration represents responsibilities. Generally, responsibilities are in a group.
Use Case Notation
Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.
Use case is used to capture high level functionalities of a system.
An actor can be defined as some internal or external entity that interacts with the system.
An actor is used in a use case diagram to describe the internal or external entities.
Initial State Notation
Initial state is defined to show the start of a process. This notation is used in almost all diagrams.
The usage of Initial State Notation is to show the starting point of a process.
Final State Notation
Final state is used to show the end of a process. This notation is also used in almost all diagrams to describe the end.
The usage of Final State Notation is to show the termination point of a process.
Active Class Notation
Active class looks similar to a class with a solid border. Active class is generally used to describe the concurrent behavior of a system.
Active class is used to represent the concurrency in a system.
A component in UML is shown in the following figure with a name inside. Additional elements can be added wherever required.
Component is used to represent any part of a system for which UML diagrams are made.
A node in UML is represented by a square box as shown in the following figure with a name. A node represents the physical component of the system.
Node is used to represent the physical part of a system such as the server, network, etc.
Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to represent the dynamic part of software and non-software systems. These features include interactions and state machines.
Interactions can be of two types −
- Sequential (Represented by sequence diagram)
- Collaborative (Represented by collaboration diagram)
Interaction is basically a message exchange between two UML components. The following diagram represents different notations used in an interaction.
Interaction is used to represent the communication among the components of a system.
State Machine Notation
State machine describes the different states of a component in its life cycle. The notations are described in the following diagram.
State machine is used to describe different states of a system component. The state can be active, idle, or any other depending upon the situation.
Organizing the UML models is one of the most important aspects of the design. In UML, there is only one element available for grouping and that is package.
Package notation is shown in the following figure and is used to wrap the components of a system.
In any diagram, explanation of different elements and their functionalities are very important. Hence, UML has notes notation to support this requirement.
This notation is shown in the following figure. These notations are used to provide necessary information of a system.
A model is not complete unless the relationships between elements are described properly. The Relationship gives a proper meaning to a UML model. Following are the different types of relationships available in UML.
Dependency is an important aspect in UML elements. It describes the dependent elements and the direction of dependency.
Dependency is represented by a dotted arrow as shown in the following figure. The arrow head represents the independent element and the other end represents the dependent element.
Dependency is used to represent the dependency between two elements of a system
Association describes how the elements in a UML diagram are associated. In simple words, it describes how many elements are taking part in an interaction.
Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two associated elements as shown in the following figure. The multiplicity is also mentioned at the ends (1, *, etc.) to show how many objects are associated.
Association is used to represent the relationship between two elements of a system.
Generalization describes the inheritance relationship of the object-oriented world. It is a parent and child relationship.
Generalization is represented by an arrow with a hollow arrow head as shown in the following figure. One end represents the parent element and the other end represents the child element.
Generalization is used to describe parent-child relationship of two elements of a system.
All the languages (programming or modeling) have some mechanism to extend its capabilities such as syntax, semantics, etc. UML also has the following mechanisms to provide extensibility features.
- Stereotypes (Represents new elements)
- Tagged values (Represents new attributes)
- Constraints (Represents the boundaries)
Extensibility notations are used to enhance the power of the language. It is basically additional elements used to represent some extra behavior of the system. These extra behaviors are not covered by the standard available notations.
This section describes style guidelines that are relevant to various types of class diagrams.
- Show visibility only on design models
- Assess responsibilities on domain class diagrams
- Highlight language-dependent visibility with property strings
- Highlight types only on design models
- Highlight types on analysis models only when the type is an actual requirement
- – Design class diagrams should reflect language naming conventions. In the “Analysis and design version of a class” image you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDateand calculateTaxes().
- – Model association classes on analysis diagrams. The image that shows the “Modelling association classes” indicates the association classes that are depicted as class attached via a dashed line to an association – the association line, the class, and the dashed line are considered one symbol in the UML.
- – Do not name associations that have association classes.
- – Center the dashed line of an association class.
A class is basically a template from which objects are created. Classes define attributes, information that are relevant to their instances, operations, and functionality that the objects support. Some of the more important guidelines pertinent to classes are listed down below.
- Put common terminology for names
- Choose complete singular nouns over class names
- Name operations with a strong verb
- Name attributes with a domain-based noun
- Do not model scaffolding code. Scaffolding code refers to the attributes and operations required to use basic functionality within your classes, such as the code required to implement relationships with other classes. The image above depicts the difference between the OrderItem class without scaffolding code
- Never show classes with just two compartments
- Label uncommon class compartments
- Include an ellipsis ( … ) at the end of incomplete lists
- List static operations/attributes before instance operations/attributes
- List operations/attributes in decreasing visibility
- For parameters that are objects, only list their type
- Develop consistent method signatures
- Avoid stereotypes implied by language naming conventions
- Indicate exceptions in an operation’s property string. Exceptions can be indicated with a UML property string, an example of which is shown in the above image.
An interface can be defined as collection of operation signature and/or attribute definitions that ideally defines a cohesive set of behaviors. Interfaces are implemented, “realized” in UML parlance, by classes and components. In order to realize an interface, a class or component should use the operations and attributes that are defined by the interface. Any given class or component may use zero or more interfaces and one or more classes or components can use the same interface.
- Interface definitions must reflect implementation language constraints. In the above image, you see that a standard class box has been used to define the interface PersistentObject (note the use of the <<interface>> stereotype).
- Name interfaces according to language naming conventions
- Apply “Lollipop” notation to indicate that a class realizes an interface
- Define interfaces separately from your classes
- Do not model the operations and attributes of an interface in your classes. In the above image, you’ll notice that the shipment class does not include the attributes or operations defined by the two interfaces that it realizes
- Consider an interface to be a contract
Aggregation and Composition
As it is known an object is made up of other objects. If you were to consider as examples where an airplane consists of wings, a fuselage, engines, flaps, landing gear and so on. A delivery shipment would contain one or more packages and a team consists of two or more employees. These are all examples of the concept of aggregation that illustrates “is part of” relationships. An engine is part of a plane, a package is part of a shipment, and an employee is part of a team. Aggregation is a specialization of association, highlighting an entire-part relationship that exists between two objects. Composition is a much potent form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. If you were to consider a stylistic point of view, aggregation and composition are both specializations of association where the guidelines for associations do apply.
- You should be interested in both the whole and the part
- Depict the whole to the left of the part
- Apply composition to aggregates of physical items
Inheritance models “is a” and “is like” relationships, enabling you to rather conveniently reuse data and code that already exist. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.” In addition to this, we have “pure inheritance” when “A” inherits all of the attributes and methods of “B”. The UML modeling notation for inheritance is usually depicted as a line that has a closed arrowhead, which points from the subclass right down to the superclass.
- Plus in the sentence rule for inheritance
- Put subclasses below superclasses
- Ensure that you are aware of data-based inheritance
- A subclass must inherit everything
At this particular juncture, the term “relationships” will encompass all UML concepts such as aggregation, associations, dependencies, composition, realizations, and inheritance. In other words, if it’s a line on a UML class diagram, it can be considered as a relationship. The following guidelines could be considered as “best practices” and and effort should be made to adhere to them at all times.
- Ensure that you model relationships horizontally
- Collaboration means a need for a relationship
- Model a dependency when a relationship is in transition
- Depict similar relationships involving a common class as a tree. In Figure A you see that both Delivery and Order have a dependency on OIDGenerator. Note how the two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to reduce clutter in the diagram.
- As a rule it is best to always indicate the multiplicity
- Avoid a multiplicity of “*” to avoid confusion
- Replace relationships by indicating attribute types. In Figure C you see that the customer has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects.
- Never model implied relationships
- Never model every single dependency
- Center names on associations
- Write concise association names in active voice
- Indicate directionality to clarify an association name
- Name unidirectional associations in the same direction
- Word association names left-to-right
- Indicate role names when multiple associations between two classes exist
- Indicate role names on recursive associations
- Make associations bi-directional only when collaboration occurs in both directions. The lives at association of Figure B is uni-directional.
- Redraw inherited associations only when something changes
- Question multiplicities involving minimums and maximums
UML Class Diagram Tutorial
The UML Class diagram is a graphical notation used to construct and visualize object oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s:
- their attributes,
- operations (or methods),
- and the relationships among objects.
What is a Class?
A Class is a blueprint for an object. Objects and classes go hand in hand. We can’t talk about one without talking about the other. And the entire point of Object-Oriented Design is not about objects, it’s about classes, because we use classes to create objects. So a class describes what an object will be, but it isn’t the object itself.
In fact, classes describe the type of objects, while objects are usable instances of classes. Each Object was built from the same set of blueprints and therefore contains the same components (properties and methods). The standard meaning is that an object is an instance of a class and object – Objects have states and behaviors.
A dog has states – color, name, breed as well as behaviors -wagging, barking, eating. An object is an instance of a class.
UML Class Notation
A class represent a concept which encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information.
- The name of the class appears in the first partition.
- Attributes are shown in the second partition.
- The attribute type is shown after the colon.
- Attributes map onto member variables (data members) in code.
Class Operations (Methods):
- Operations are shown in the third partition. They are services the class provides.
- The return type of a method is shown after the colon at the end of the method signature.
- The return type of method parameters are shown after the colon following the parameter name. Operations map onto class methods in code
The +, – and # symbols before an attribute and operation name in a class denote the visibility of the attribute and operation.
- + denotes public attributes or operations
- – denotes private attributes or operations
- # denotes protected attributes or operations
Each parameter in an operation (method) may be denoted as in, out or inout which specifies its direction with respect to the caller. This directionality is shown before the parameter name.
Perspectives of Class Diagram
The choice of perspective depends on how far along you are in the development process. During the formulation of a domain model, for example, you would seldom move past the conceptual perspective. Analysis models will typically feature a mix of conceptual and specification perspectives. Design model development will typically start with heavy emphasis on the specification perspective, and evolve into the implementation perspective.
A diagram can be interpreted from various perspectives:
- Conceptual: represents the concepts in the domain
- Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
- Implementation: describes how classes will implement their interfaces
The perspective affects the amount of detail to be supplied and the kinds of relationships worth presenting. As we mentioned above, the class name is the only mandatory information.
Relationships between classes
UML is not just about pretty pictures. If used correctly, UML precisely conveys how code should be implemented from diagrams. If precisely interpreted, the implemented code will correctly reflect the intent of the designer. Can you describe what each of the relationships mean relative to your target programming language shown in the Figure below?
If you can’t yet recognize them, no problem this section is meant to help you to understand UML class relationships. A class may be involved in one or more relationships with other classes. A relationship can be one of the following types:
Inheritance (or Generalization):
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier.
- Represents an “is-a” relationship.
- An abstract class name is shown in italics.
- SubClass1 and SubClass2 are specializations of SuperClass.
The figure below shows an example of inheritance hierarchy. SubClass1 and SubClass2 are derived from SuperClass. The relationship is displayed as a solid line with a hollow arrowhead that points from the child element to the parent element.
Inheritance Example – Shapes
The figure below shows an inheritance example with two styles. Although the connectors are drawn differently, they are semantically equivalent.
Associations are relationships between classes in a UML Class Diagram. They are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain.
- A structural link between two peer classes.
- There is an association between Class1 and Class2
The figure below shows an example of simple association. There is an association that connects the <> class Class1 and <> class Class2. The relationship is displayed as a solid line connecting the two classes.
Cardinality is expressed in terms of:
- one to one
- one to many
- many to many
A special type of association.
- It represents a “part of” relationship.
- Class2 is part of Class1.
- Many instances (denoted by the *) of Class2 can be associated with Class1.
- Objects of Class1 and Class2 have separate lifetimes.
The figure below shows an example of aggregation. The relationship is displayed as a solid line with a unfilled diamond at the association end, which is connected to the class that represents the aggregate.
- A special type of aggregation where parts are destroyed when the whole is destroyed.
- Objects of Class2 live and die with Class1.
- Class2 cannot stand by itself.
The figure below shows an example of composition. The relationship is displayed as a solid line with a filled diamond at the association end, which is connected to the class that represents the whole or composite.
An object of one class might use an object of another class in the code of a method. If the object is not stored in any field, then this is modeled as a dependency relationship.
- A special type of association.
- Exists between two classes if changes to the definition of one may cause changes to the other (but not the other way around).
- Class1 depends on Class2
The figure below shows an example of dependency. The relationship is displayed as a dashed line with an open arrow.
The figure below shows another example of dependency. The Person class might have a hasRead method with a Book parameter that returns true if the person has read the book (perhaps by checking some database).
Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.
For example, the Owner interface might specify methods for acquiring property and disposing of property. The Person and Corporation classes need to implement these methods, possibly in very different ways.
Class Diagram Example: Order System
Class Diagram Example: GUI
A class diagram may also have notes attached to classes or relationships.