modeling uml class diagrams and sequence diagrams

Modeling UML Class Diagrams and Sequence diagrams

Structural and Behavioral Aspects

Developing a software system in object oriented approach (or any other approach, in general) is very much dependent on understanding the problem. From the point of view of a developer, it is essential to have insights on the structural and behavioral aspects of a problem in order to design a solution for the same. Class and sequence diagrams in UML, respectively, can help us with these aspects.

Class diagram

It is a graphical representation for describing a system in context of its static construction [1]. A class diagram contains the system classes with its data members, operations, and relationships between classes.


A set of objects containing similar data members and member functions is described by a class. In UML syntax, class is identified by solid outline rectangle with three horizontal compartments which contain

  • Class name
  • : A class is uniquely identified in a system by its name, which is a textual string [2]. The name is written inside the first (top) compartment in class rectangle.

  • Attributes: These are properties shared by all instances of a class. They are listed inside the second compartment in class rectangle.
  • Operations: These are actions that can be performed by/upon the instances of a class or the class itself. These are listed inside the last (bottom) compartment in class rectangle.


To build a structural model for an educational organization, “Course” can be treated as a class, which contains the attributes “courseName” and “courseID” along with the operations “addCourse()” and “removeCourse()” allowed to be performed over any object of that class.

It may be noted usually significant members and operations are depicted in a class diagram. For example, the Course class may have a member, say “Description”, which does not affect the structural aspects as such, and therefore, omitted in Figure 1. In fact, when only the relationships among different classes matter, these attributes and operations may be skipped altogether.

StateFigure 1: A class with attributes and operations


Existing relationships in a system describe legitimate connections among the classes in that system. Such relationships can be of different types and are briefly discussed below:

  • Association: It is an instance level relationship [i] that allows exchanging messages among the objects of the both ends of an association. A solid straight line connecting two class boxes represent an association relationship. We can give name to an association. Also, we can indicate roles and multiplicity of the adjacent classes at the end points of the straight line. Association can be uni-directional or bi-directional.


    In the structure model for a system of an organization, an employee (instance of “Employee” class) is always assigned to a particular department (instance of “Department” class) and the association can be shown by a line connecting the respective classes.

    StateFigure 2: Association between two classes

  • Aggregation: It is a special form of association which describes a part-whole [i] relationship between a pair of classes. It means, in a relationship, when a class holds some instances of related class, then that relationship can be designed as an aggregation.


    For a supermarket in a city, each branch runs some of the departments that they have. So, the relation among the classes “Branch” and “Department” can be designed as an aggregation. In UML, it can be indicated as shown in the Figure below.

    StateFigure 3: An example of aggregation

  • Composition [i]: It is a strong from of aggregation which describes that whole completely owns its part. Life cycle of the part depends on the whole.


    Let us consider a shopping mall that has several branches in different locations in a city. The existence of these branches completely depends on the shopping mall, since if the mall does not exist, none of its branches would exist in the city. This relation can be described as composition and can be shown as illustrated below.

    StateFigure 4: Composition of classes

  • Generalization/Specialization: It describes how one class is derived from another class. Derived classes inherit the properties of its parent class.

    Example >

    Geometric_Shapes in Figure 5 describes how many sides a particular shape has. Triangle, Quadrilateral, and Pentagon are three classes that inherit the property of the Geometric_Shapes class. So the relationship of these classes with Geometric_Shapes is generalization. Now Equilateral_Triangle, Isosceles_Triangle, and Scalene_Triangle — these three classes inherit the properties of the Triangle class as each one of them has three sides. So, these are specialization of the Triangle class.

    StateFigure 5: Hierarchical relationship among classes

  • Multiplicity: It describes how many instances of a given class is related to the number of instances of another class in an association relationship.

    Notation for different types of multiplicity:

    StateFigure 6: Different types of multiplicities


    A vehicle can have two or more wheels

    StateFigure 7: Multiplicity relation between a vehicle and is wheels

Sequence diagram

It represents the behavioral aspects of a system [1]. A sequence diagram shows the interactions among different objects in a system [1] by means of message passing from one object to another with respect to time [2].

Elements in sequence diagram

A sequence diagram consists of the objects of a system and their life-line bar and the messages passed among them.


Objects appear at the top portion of sequence diagram [1]. An object is shown in a rectangular box. Name of the object precedes a colon “:” and the class name from which the object is instantiated. The whole string is underlined and appears inside the concerned rectangle box. Also, we may use only class name or only instance name.

Life-line bar

A downward vertical line from object-box indicates the life-line of the corresponding object. A rectangular bar on life-line indicates that the concerned object is active at that point of time [1].


>A message is shown as an arrow from the life-line of sender object to the life-line of receiver object and labeled with the message name. Their sequence of ordering indicate the chronological order of the message passing among the different objects [1]. There can be different types of messages:

  • Synchronous messages: When a receiver starts processing such a message after receiving it, the sender needs to wait until the processing is over [iii]. A straight arrow with closes and filled arrow-head from sender life-line bar to the receiver end indicate a synchronous message [iii].
  • Asynchronous messages: In case of asynchronous messages, a sender does not need to wait for the receiver to process the message [iv]. A function call that creates thread can be represented as an asynchronous message in a sequence diagram [iv]. A straight arrow with open arrow-head from the sender’s life-line bar to receiver end indicate an asynchronous message [iii].
  • Return message: When we need to return the value of a functin call to the object from which it was called, return messagees are used. A dashed arrow with open arrow-head from the sender’s life-line bar to receiver end indicate a return message.
  • Response message: An object can send a message to itself [iv]. We use this type of message when we need to show the interaction between the same object.

StateFigure 8: Different types of messages


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s