Have you wondered what a UML class diagram is? How can they model software entities? Who are the people who use this artifact? How can this be used in agile project methodology? Follow this article to understand the components of a UML class diagram along with their relationships. Learn how they can be used to model the structure of a software system, and much more.
UML is a graphical modeling language to represent the structural and behavioral artifacts of software systems. The UML class diagram is one such artifact that is used to model the structure of entities along with their relationships.
Business Analysts, Product Owners, Architects, Designers, and Developers use it as a means to communicate the entities of a system.
Business analysts(BA) use class diagrams to model abstract real-world business entities (conceptual / analysis models), whereas architects and developers use these to relate software entities (solution models) of a system.
The Software Development life cycle(SDLC) of a product make use of UML class diagrams from conceptualization to software Architecture & design stage.
Several document including Business Requirement Document(BRD), Software Requirement Specification(SRS)/ Functional Specification Document(FSD), High-level Design(HLD) and Low-level Design(LLD) documents use the UML class diagram.
Agile development methodologies can also use these diagrams. It can effectively communicate the design of the system in development to the development team and Stakeholders.
UML CLASS MODEL
A Class in Object-Oriented programming is a software template with the encapsulated state (data) and behavior (operations), used for creating objects.
By holding the state(data) and associated behavior (operations) in the same entity, a class models the entity as close to reality.
It represents a custom data type from which objects of that type are instantiated in the system. An Object-oriented software system consists of several class objects that communicate, collaborate, and associate with each other.
The UML class diagram shows the static structure of the system, by describing the classes with their state and behavior along with their relationships.
A rectangular box with three horizontal compartments stacked one upon another represents an UML class. The compartments contain information and are as described:
- name of the class is in the top compartment,
- data fields, properties, or attributes are in the middle compartment, and
- operations, functions, or methods are in the bottom compartment.
Several OOP languages provide access specifiers for the data members and functions in a class. They can be either private, protected, public, or package. Any other type of access specifier can be specified using stereotypes in UML.
The access specifiers use symbols to represent them. These symbols are placed before the fields and functions of a class. They restrict the visibility of these members based on the access specifier. The four visibility or access modifiers symbols or notation of the class are as follows:
The data fields are shown in the middle compartment using the following format:
whereas the methods and operations are shown in the last compartment using the following format:
: is the access specifier,
is the attribute name,
is the name of the function or operation name,
: is a comma-separated list of argument data types only, and
: is the return data type of the method or function.
Instance scope refers to instance members of a class, the members that are unique for each instance of the class. Classifier scope refers to fields and functions that are common for all the instances of the class. The UML class model shows classifier scope members with an underline.
Several UML tools are available in the market to model UML diagrams, some of them are freeware and others are commercial. A comprehensive list of UML tools can be found here and here. I have used WhiteStarUML(an earlier version of StarUML) to generate a UML class diagram as shown below:
RELATIONSHIPS IN CLASS DIAGRAM:
The relationships in a class diagram represent the communication link between the participating classes. They are as follows:
- Associations: These relationships are classified as “has-a” kind and are of three types:
- Association: This type of relationship exists when two independent classes need to communicate with each other. It allows one class object to invoke methods on another class object. The relationship can be bidirectional where both objects participate in the communication.It can also be unidirectional, where only one object knows the existence of the other.
- Aggregation: A specific form of Association, where the participating objects form a Whole/Part relationship. The classes exist independent of one another.
- Composition: This association is a stronger form of Aggregation. The ‘Whole’ controls the lifetime of the ‘Part’ and the ‘Part’ cannot exist independent of the ‘Whole’. The ‘Whole’ destroys the ‘part’ along with it.
- Inheritance: In this relationship, the child class inherits the base/parent class data and behavior. This type of relationship is called implementation inheritance and classified as an “is-a” relationship.
- Realization: This type of relationship is known as interface inheritance. An interface(supplier) is a contract of all behavior that its client(class) must implement. The client must realize all the methods of its supplier.
- Dependency: In this kind of relationship the client class would require the supplier class for its implementation or specification.
The class diagram relationship notation are as shown in the following figure:
In an association relationship, multiplicity is a notation to show how many objects of one class are related to a single instance of another class. The association can show multiplicity on either end of the relationship.
|*||Many (zero or more)|
|0..1||zero or one|
|1..*||One or more|
|m..n||Specified numerically for the range.|
UML CLASS DIAGRAM:
In the Conceptual stage or requirements analysis phase of the project, the business analyst(BA) captures the domain entities and their relationships in a UML Class Diagram. Whereas, in the Solution Design Stage, the solution team(Architect, Designers, Developers) create UML Class diagrams to show the actual software classes and objects. The requirements captured by the Business Analyst drives the solution design stage.
#1. CONCEPTUAL STAGE:
In the conceptual stage of analyzing stakeholder requirements, the domain entities are at an abstract level and would typically refer to nouns that are governed by business rules.
The BA shows the domain entities in the form of a class diagram and documents them in BRD and/or SRS. THE BA can also use this business domain model for a software database system(ER-diagram).
During the initial stage of business analysis, the class diagram may show the identified names of domain entities and their relationship as associations. The entities may not contain a concrete state and associated behavior.
A first-cut domain model (represented as a Class Diagram) for a company project may contain domain entities and their associations/relationships with other entities as shown in the following figure.
In the requirements analysis, the BA phase refines the business domain model iteratively and incrementally.New information feeds from stakeholders feeds in to the iterative phase leading to changes of the business domain models and business rules.
The BA analyzes and documents the requirements during this phase. During this phase, the BA may identify new entities and remove or refine existing entities as per the business requirements and the domain entities may now contain some state and behavior.
After several iterations, the same domain model(Class Diagram) would have more participating entities, with the attributes & operations specified in some of the entities. With the business rules better understood the relationships between entities become more specific. A possible refined domain model after these iterations is as shown below:
#2. SOLUTION DESIGN STAGE:
The Architects and developers of the software system translate these requirements into a solution design model. The domain entities and associated rules form the basis for the design of the software solution.
The architects design the system taking into account the Industry best practices, design patterns, and design principles. They classify the system into various modules and come up with logical system design models(UML class diagrams) depicting the structure and interaction of the classes for the solution. The high-level design document(HLD) contains the class diagram and these classes are actual entities in a software system.
They along with the developers and programmers of the development team, iteratively and incrementally design the final working solution. They take into account all the functional and non-functional requirements(quality factors) to arrive at the final detailed design of the system. The LLD documents these detailed solutions and show the static class structure as a UML class diagram. They are similar to the business domain models, the diagram below shows a solution class diagram of a shopping cart with a payment strategy.
The outcome of this process is a detailed solution class diagram of the various modules in the software system. Each of the class diagrams would contain enough information of the data members and functions that it can be translated into working OOP code.
Several Free and Commerical UML tools provide the feature for converting UML class diagrams into software code. They provide the conversion in any of the several OOP languages. Also, some of these tools have the feature to convert(reverse engineer) the existing codebase of a software system to UML class diagrams.
The UML class diagram is widely used in the Software Industry to reflect the static structure of the entities and design choices (design patterns and principles adopted) of a software system. Business Analysts use it to document the business domain entities and their associations in the form of a UML class diagram. The domain entities along with the business rules form the basis for architecture and design of software systems.
Software Architects and Designers use industry best practices like SOLID design principles and design patterns to translate software requirements(domain entities, activity diagrams, Use-Cases, quality requirements, and others) into software systems. The solution class diagrams capture the static structure of the classes and their interaction with the system. The program’s code is a direct reflection of these detailed solution class diagrams.
Several UML tools (both free and commercial) are available for modeling a system using a UML Class diagram and some provide the functionality of reverse-engineering existing codebase to a class diagram.
The UML class diagram can be used as a design artifact in Agile development methodologies, to efficiently communicate the design of the system under development to the scrum team and relevant stakeholders.
Please do let me know of your views in the comment section. Also if you like my article please do share it on social.