1

KALINGA UNIVERSITY
FACULTY OF COMPUTER SCIENCE & IT

Course- B Tech Computer Science Semester – 5th

Subject- Object Oriented System Design
Subject Code – BTCS505

Unit- II
Modeling
Modeling means creating a diagram for a system that includes identifying the elements that are
important to your particular module. The structural modeling gives a structural view of a system that
highlights the structure of the objects including their classifiers, relationships, attributes and
operations. These elements form the vocabulary of the system you are modeling. For example, if you
are going to buy a car, things like wheels, frame size, color, lights, and engine are some things that
will be worthful to you in understanding about the car; these things are properties of the car. In UML,
all of these things are modelled as classes. Cars have external and internal structure, only important
properties of car are visible and the rest are hidden. This feature is called abstraction. A class is an
abstraction of the things that are a part of your vocabulary. For creating a structural model, you have to
collect key data contained in the problem domains.

The core elements of the structural modeling are class, interface, component, node and constraints and
they are described with their notations in Table 2.1.

Table 2.1: Core elements of the structural modeling

Construct Description Syntax
Class Class is a ‘blueprint’ for creating objects. It contains a group of
objects that share the same properties, operations, and
relationships. It contains three sections as name, attributes and
operations.
Interface It is a collection of named operations that describe the behaviour
of an element. You can neither define any attributes nor any
implementation of the operations in the interface.

Component A component diagram is used to split the actual system into

various modular parts. Each component has one clear aim within
the whole system.
Node It is a run-time physical object that denotes a computational
resource such as server, router.
Constraint It is a condition for a UML element.
 2

Basic Structural Modelling

Classes
A class describes a group of objects which have common attributes or properties, operations or
behavior, relationships and semantics. Classes are an essential structure of any object-oriented system.
When you develop any system, you need classes to collect the system's vocabulary. These classes may
relate to the problem domain as well as implementation. Classes can be used to represent anything
from hardware, software to purely conceptual things. A class describes only important attributes to an
application and ignores the rest ; it is known as an abstraction, an important feature of object-oriented
concepts.

Figure 2.2: Class syntax

A class is graphically designed as a rectangle with three sections that comprises its name, attributes
and operations as shown in the figure-2.2. For example, Car class contains attributes (maker name,
wheel size, gears, frame size and color) and operations (repair, move) as shown in figure-2.3.

Figure 2.3: Car class with attributes and operations

You can say that a class contains infinite set of individual objects with the same data structure
(attributes) and behavior (operations). Each object is termed as an instance of its class. So, each
instance ( known as object) of the class has its own value for each attribute but shares the attribute
names and operations with other class instances.
Following are some points for creating a class:
 3

 Each class must have a unique name. A class name is a textual string that comprises any
numbers of letters, numeric and punctuation marks. For example, Car, Book, Teacher, Account
or Person etc.
 A class may or may not have attributes. An attribute is defined by a name that contains a
series of values. For example: Person class have attributes like name, age, address. In the
similar way, Car class may have attributes like frame size, wheel size, gears, color and make as
shown in figure-2.3. You can also mention attributes ‘types’ such as String or integer etc. , as
shown in figure-2.4.
 A class may or may not have operations. An operation describes the behavior of the class. An
operation has a name like a class name. Usually, the operation name is written as a short text
string that represents some behaviour of its enclosing class. For example, Car class may have
operations like move, repair as shown in figure-2.4. You can identify an operation by declaring
its signature. Graphically, operations are given in a section just below the class attributes.
 You can also define the visibility of class members (attributes and operations) by using plus
sign (+) for public, negative sign (-) for private, hash sign (#) for protected and tilde (~) for the
package. You can see in figure-2.4 where all attributes and operations are mentioned as public.

Figure 2.4 : Class attributes and visibility

Relationships
Relationships define how classes communicate with each other. There are three basic types of
relationships in UML- Dependencies, Generalization and Associations for connecting or
communicating classes to each other. Graphically, a relationship is shown as a path with different
types of lines used to differentiate the categories of relationships between classes.
Dependency describes the relationships among classes in which one class is dependent on another
class. It means that if you make changes in one class, it will affect the other class. For example, class
Vehicle uses the properties and operations of another class (say Bodyshop) but not necessarily the
reverse. You can show dependency as a dashed directed line, directed to the class being dependent
upon the class. As you can see in figure-2.5, vehicle class is dependent on ‘Bodyshop’ class.
Generalization is a “a-kind-of” relationship. It creates relationships between superclass(base class)
and subclass, enabling inheritance of attributes and operations. It defines a base( parent) class with
some properties functions. A new class will be derived from this base class and it is called child or sub
 4

class of the base class. The child class can use the properties and operations of the superclass. As you
can see in figure-2.5, vehicle class is super class or base or parent class and Car, Bus are child class or
sub class. The generalization is depicted as a solid line with a hollow arrow pointing to the superclass.

Figure 2.5: Different relationships: Dependency, Generalization and Association

Association is “a-part-of” relationships between classes. It refers to relationships between classes in
which objects of one class are connected to other class objects for communicating data as you can see
in figure-2.6. When you connect just two classes is called a binary association. Associations can
also have more than two classes, which will be known as n-ary associations. One more form of
association is called aggregation that specifies a whole-part relationship between the aggregate
(whole) and the component part. For example, paragraph is part of word document. Each association
can have a name, role, multiplicity and aggregation.
You can use a name for an association that describes the relationship's nature. You can also define
role names and multiplicity for an association. Multiplicity states how many instances of one class
may communicate to a single instance of other class. You can display a multiplicity of exactly one (1),
zero or one (0..1), many (0..*), or one or more (1..*).

Figure 2.6: An association between classes

For example, IGNOU University have many schools. In figure-2.6, there are two classes Schools and
University. Both the classes are related to each other, and their relationship is defined by association.
This association has a name as Works-for, and role names are employee and employer. The employee
of schools worked for employer i.e. University. Under the university, there are many schools, so
 5

multiplicity is defined as one or many.

Common Mechanisms
During designing your application, you might need to describe information through representations.
This section explains to you some important terms or notations that might be useful in designing UML
diagrams. These notations like notes, tagged values, stereotypes, constraints are demonstrated by
using the following figure-2.7:

Figure 2.7: Information describing notations

Notes are used to define comments, explanations for documentation purposes only. It cannot have any
effect on the semantics of the model. A note may simply comprise normal text or graphical symbols.
Graphically, a note is depicted as a rectangle box with a dog-eared corner along with the comment.
You can see the note as an embedded URL notation in figure-2.7.
Tagged value is used to create extension or new information of properties of UML element.
Graphically, you can draw a tagged value as a string enclosed in {brackets}.
A stereotype is used to create new building blocks. Using stereotypes, we can use the basic elements
but with special properties, semantics and notation. Graphically, you can represent stereotypes as text
name inside guillemets(<< >>) and place them above the name of another element. You can see
stereotype notation as a <<lastdate>> above the class course element in figure-2.7.
Constraint is defined as a condition for a UML element that will be cheeked at the run-time of
applications. Graphically, you can draw as a string enclosed in {brackets} and can be put in a note.
You can see constraint as a condition notation for course class in figure-2.7.
When you use these notations in your UML diagram, keep in mind such points as always use short
notes, use notes only when the facts cannot be conversed using UML, don not use too many
graphical stereotypes, tagged values and constraints; use only common and simple supplements.
 6

UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects residing in
the system and the relationships between them. A class consists of its objects, and also it may inherit
from other classes. A class diagram is used to visualize, describe, document various different aspects
of the system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that helps in
software development. Since it is a collection of classes, interfaces, associations, collaborations, and
constraints, it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only diagram
that is widely used for construction, and it can be mapped with object-oriented languages. It is one of
the most popular UML diagrams. Following are the purpose of class diagrams given below:
1. It analyses and designs a static view of an application.
2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application is structured
before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be programmed.
5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:
o Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations, and
semantics. Some of the following rules that should be taken into account while representing a
class are given below:

a. Capitalize the initial letter of the class name.

b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
Middle Section: The middle section constitutes the attributes, which describe the quality of the
class. The attributes have the following characteristics:
 7

a. The attributes are written along with its visibility factors, which are public (+), private (-),
protected (#), and package (~).
b. The accessibility of an attribute class is illustrated by the visibility factors.
c. A meaningful name should be assigned to the attribute, which will explain its usage
inside the class.
Lower Section: The lower section contain methods or operations. The methods are represented
in the form of a list, where each method is written in a single line. It demonstrates how a class
interacts with data.

Relationships
In UML, relationships are of three types:
o Dependency: A dependency is a semantic relationship between two or more classes where a
change in one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

o Generalization: A generalization is a relationship between a parent class (superclass) and a

child class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized
form of Bank Account.

v
o Association: It describes a static or physical connection between two or more objects. It
depicts how many objects are there in the relationship.
For example, a department is associated with the college.

o Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range

is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

 8

o Aggregation: An aggregation is a subset of association, which represents has a relationship. It

is more specific then association. It defines a part-whole or part-of relationship. In this kind of
relationship, the child class can exist independently of its parent class.

The company encompasses a number of employees, and even if one employee resigns, the
company still exists.

o Composition: The composition is a subset of aggregation. It portrays the dependency between

the parent and its child, which means if one part is deleted, then the other part also gets
discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the contacts
will be lost.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It
represents an instance of a class diagram. The objects help in portraying a static view of an object-
oriented system at a specific instant.
 9

Both the object and class diagram are similar to some extent; the only difference is that the class
diagram provides an abstract view of a system. It helps in visualizing a particular functionality of a
system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides an
abstract view which comprises of classes and their relationships, whereas the object diagram
represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The main purpose is to
depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.
o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.

Example of Object Diagram

How to draw an Object Diagram

1. All the objects present in the system should be examined before start drawing the object
diagram.
2. Before creating the object diagram, the relation between the objects must be acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
 10

5. The objects are to be examined to understand its functionality.

Applications of Object diagrams

The following are the application areas where the object diagrams can be used.
1. To build a prototype of a system.
2. To model complex data structures.
3. To perceive the system from a practical perspective.
4. Reverse engineering.

Class vs. Object diagram

Serial No. Class Diagram Object Diagram

1. It depicts the static view of a It portrays the real-time behavior of a system.

system.

2. Dynamic changes are not included Dynamic changes are captured in the object
in the class diagram. diagram.

3. The data values and attributes of an It incorporates data values and attributes of an
instance are not involved here. entity.

4. The object behavior is manipulated Objects are the instances of a class.

in the class diagram.

UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both the
sequence and the collaboration diagrams represent the same information but differently. Instead of
showing the flow of messages, it depicts the architecture of the object residing in the system as it is
based on object-oriented programming. An object consists of several features. Multiple objects present
in the system are connected to each other. The collaboration diagram, which is also known as a
communication diagram, is used to portray the object's architecture in the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:
1. Objects: The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
2. In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is specified.
 11

o To differentiate one object from another object, it is necessary to name them.

3. Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction.
Each actor has its respective role and name. In this, one actor initiates the use case.
4. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to another
object, such that the message flows are attached to links.
5. Messages: It is a communication between objects which carries information and includes a
sequence number, so that the activity may take place. It is represented by a labeled arrow,
which is placed near a link. The messages are sent from the sender to the receiver, and the
direction must be navigable in that particular direction. The receiver must understand the
message.

When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict the relationship between the object. Both the
sequence and collaboration diagrams represent the same information, but the way of portraying it quite
different. The collaboration diagrams are best suited for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration diagram is
implemented:
1. To model collaboration among the objects or roles that carry the functionalities of use cases
and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects and the
roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a collaboration of
several objects and interactions.
5. To support the identification of objects participating in the use case.
 12

6. In the collaboration diagram, each message constitutes a sequence number, such that the top-
level message is marked as one and so on. The messages sent during the same call are denoted
with the same decimal prefix, but with different suffixes of 1, 2, etc. as per their occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for performing the
functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence diagram for
summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.
2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how lifelines are
connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the difference is
that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be directly
converted to the collaboration diagram.
 13

9. There may be a chance of losing some amount of information while implementing a

collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every single
that has occurred inside the object of a system.

Sequence Diagram
The sequence diagram represents the flow of messages in the system and is also termed as an event
diagram. It helps in envisioning several dynamic scenarios. It portrays the communication between
any two lifelines as a time-ordered sequence of events, such that these lifelines took part at the run
time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented by
a vertical dotted line that extends across the bottom of the page. It incorporates the iterations as well as
branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top
of the diagram.

Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope of
the system. It represents the role, which involves human users and external hardware or subjects. An
actor may or may not represent a physical entity, but it purely depicts the role of an entity. Several
distinct roles can be played by an actor or vice versa.
 14

Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation
is performed by an element, such that the top and the bottom of the rectangle is associated with the
initiation and the completion time, each respectively.

Messages
The messages depict the interaction between the objects and are represented by arrows. They are in the
sequential order on the lifeline. The core of the sequence diagram is formed by messages and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an interaction,
which represents that the target lifeline has invoked an operation.

o
 15

o Return Message: It defines a particular communication between the lifelines of interaction

that represent the flow of information from the receiver of the corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an interaction

that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive message.
In other words, it can be said that the recursive message is a special case of the self message as
it represents the recursive calls.

o
 16

o Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.
 17

Sequence Fragments

1. Sequence fragments have been introduced by UML 2.0, which makes it quite easy for the
creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of interaction inside a
sequence diagram.
3. The type of fragment is shown by a fragment operator.

Types of fragments
Following are the types of fragments enlisted below;

Operator Fragment Type

alt Alternative multiple fragments: The only fragment for which the condition is true, will
execute.

opt Optional: If the supplied condition is true, only then the fragments will execute. It is
similar to alt with only one trace.

par Parallel: Parallel executes fragments.

loop Loop: Fragments are run multiple times, and the basis of interaction is shown by the
guard.

region Critical region: Only one thread can execute a fragment at once.

neg Negative: A worthless communication is shown by the fragment.

ref Reference: An interaction portrayed in another diagram. In this, a frame is drawn so as to

cover the lifelines involved in the communication. The parameter and return value can be
explained.

sd Sequence Diagram: It is used to surround the whole sequence diagram.

 18

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.
Any online customer can search for a book catalog, view a description of a particular book, add a book
to its shopping cart, and do checkout.

Benefits of a Sequence Diagram

1. It explores the real-time application.
2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
3. Since each sequence needs distinct notations for its representation, it may make the diagram
more complex.
4. The type of sequence is decided by the type of message.
 19

Differences Between Sequence and Collaboration diagram:

Sequence Diagrams Collaboration Diagrams

The sequence diagram represents the UML, The collaboration diagram also comes under the
which is used to visualize the sequence of calls UML representation which is used to visualize
in a system that is used to perform a specific the organization of the objects and their
functionality. interaction.

The sequence diagram are used to represent the The collaboration diagram are used to represent
sequence of messages that are flowing from one the structural organization of the system and the
object to another. messages that are sent and received.

The sequence diagram is used when time The collaboration diagram is used when object
sequence is main focus. organization is main focus.

The collaboration diagrams are better suited for

The sequence diagrams are better suited of
depicting simpler interactions of the smaller
analysis activities.
number of objects.

Interaction Diagrams
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object interactions
and also depicts the flow between various use case elements of a system. In simple words, it shows
how objects interact with each other and how the data flows within them. It consists of
communication, interaction overview, sequence, and timing diagrams.
o Sequence Diagram: It shows the interactions between the objects in terms of messages
exchanged over time. It delineates in what order and how the object functions are in a system.
o Communication Diagram: It shows the interchange of sequence messages between the
objects. It focuses on objects and their relations. It describes the static and dynamic behavior of
a system.
o Timing Diagram: It is a special kind of sequence diagram used to depict the object's behavior
over a specific period of time. It governs the change in state and object behavior by showing
the time and duration constraints.
o Interaction Overview diagram: It is a mixture of activity and sequence diagram that depicts a
sequence of actions to simplify the complex interactions into simple interactions.

Behavioral Model is specially designed to make us understand behavior and factors that influence
behavior of a System. Behavior of a system is explained and represented with the help of a diagram.
This diagram is known as State Transition Diagram. It is a collection of states and events. It usually
describes overall states that a system can have and events which are responsible for a change in state
of a system.
 20

So, on some occurrence of a particular event, an action is taken and what action needs to be taken is
represented by State Transition Diagram.
Example :
Consider an Elevator. This elevator is for n number of floors and has n number of buttons one for
each floor.
Elevator’s working can be explained as follows :
1. Elevator buttons are type of set of buttons which is there on elevator. For reaching a particular
floor you want to visit, “elevator buttons” for that particular floor is pressed. Pressing, will cause
illumination and elevator will start moving towards that particular floor for which you pressed
“elevator buttons”. As soon as elevator reaches that particular floor,
illumination gets canceled.
2. Floor buttons are another type of set of buttons on elevator. If a person is on a particular floor
and he wants to go on another floor, then elevator button for that floor is pressed. Then, process
will be same as given above. Pressing, will cause illumination and elevator to start moving, and
when it reaches on desired floor, illumination gets canceled.
3. When there is no request for elevator, it remains closed on current floor.
State Transition Diagram for an elevator system is shown below –

Advantages :
 Behavior and working of a system can easily be understood without any effort.
 Results are more accurate by using this model.
 This model requires less cost for development as cost of resources can be minimal.
 It focuses on behavior of a system rather than theories.

Disadvantages :
 This model does not have any theory, so trainee is not able to fully understand basic principle
and major concept of modeling.
 This modeling cannot be fully automated.
 Sometimes, it’s not easy to understand overall result.
 Does not achieve maximum productivity due to some technical issues or any errors.
 21

Activity Diagram
In UML, the activity diagram is used to demonstrate the flow of control within the system rather than
the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis
on the condition of flow and the order in which it occurs. The flow can be sequential, branched, or
concurrent, and to deal with such kinds of flows, the activity diagram has come up with a fork, join,
etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions

or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities
The categorization of behavior into one or more actions is termed as an activity. In other words, it can
be said that an activity is a network of nodes that are connected by edges. The edges depict the flow of
execution. It may contain action nodes, control nodes, or object nodes.

The control flow of activity is represented by control nodes and object nodes that illustrates the objects
used within an activity. The activities are initiated at the initial node and are terminated at the final
node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be either
vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary to
incorporate swimlane in the activity diagram. But it is used to add more transparency to the activity
diagram.
 22

Forks
Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one
inward edge and several outward edges. It is the same as that of various decision parameters.
Whenever a data is received at an inward edge, it gets copied and split crossways various outward
edges. It split a single inward flow into multiple parallel flows.

Join Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the inward
edges as it synchronizes the flow of input across one single output (outward) edge.

Pins
It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that precisely
represents one input to or output from the action.

Timing Diagram
In UML, the timing diagrams are a part of Interaction diagrams that do not incorporate similar
notations as that of sequence and collaboration diagram. It consists of a graph or waveform that
depicts the state of a lifeline at a specific point of time. It illustrates how conditions are altered both
inside and between lifelines alongside linear time axis.
 23

The timing diagram describes how an object underwent a change from one form to another. A
waveform portrays the flow among the software programs at several instances of time.

Following are some important key points of a timing diagram:

1. It emphasizes at that particular time when the message has been sent among objects.
2. It explains the time processing of an object in detail.
3. It is employed with distributed and embedded systems.
4. It also explains how an object undergoes changes in its form throughout its lifeline.
5. As the lifelines are named on the left side of an edge, the timing diagrams are read from left to
right.
6. It depicts a graphical representation of states of a lifeline per unit time.
7. In UML, the timing diagram has come up with several notations to simplify the transition state
among two lifelines per unit time.

Interaction Diagram
the interaction diagram portrays the interactions between distinct entities present in the model. It
amalgamates both the activity and sequence diagrams. The communication is nothing but units of the
behavior of a classifier that provides context for interactions.

A set of messages that are interchanged between the entities to achieve certain specified tasks in the
system is termed as interaction. It may incorporate any feature of the classifier of which it has access.
In the interaction diagram, the critical component is the messages and the lifeline.

In UML, the interaction overview diagram initiates the interaction between the objects utilizing
message passing. While drawing an interaction diagram, the entire focus is to represent the
relationship among different objects which are available within the system boundary and the message
exchanged by them to communicate with each other.

The message exchanged among objects is either to pass some information or to request some
information. And based on the information, the interaction diagram is categorized into the sequence
diagram, collaboration diagram, and timing diagram.

Package Diagram
Package diagram, a kind of structural diagram, shows the arrangement and organization of model
elements in middle to large scale project. Package diagram can show both structure and
dependencies between sub-systems or modules, showing different views of a system, for example, as
multi-layered (aka multi-tiered) application - multi-layered application model.

Purpose of Package Diagrams

Package diagrams are used to structure high level system elements. Packages are used for organizing
large system which contains diagrams, documents and other key deliverables.
 Package Diagram can be used to simplify complex class diagrams, it can group classes into
packages.
 A package is a collection of logically related UML elements.
 Packages are depicted as file folders and can be used on any of the UML diagrams.
 24

Basic Concepts of Package Diagram

Package diagram follows hierarchal structure of nested packages. Atomic module for nested package
are usually class diagrams. There are few constraints while using package diagrams, they are as
follows.
 Package name should not be the same for a system, however classes inside different
packages could have the same name.
 Packages can include whole diagrams, name of components alone or no components at all.
 Fully qualified name of a package has the following syntax.

Architectural Modeling
Architectural model represents the overall framework of the system. It contains both structural and
behavioral elements of the system. Architectural model can be defined as the blueprint of the entire
system. Package diagram comes under architectural modeling.
Components
 A component is a physical and replaceable part of a system that conforms to and provide the
realization of a set of interfaces
 It is used to model physical things like executable's, libraries, tables, files and
documents Graphically represented as a rectangle with tabs
 Names
 Components and Classes
 Components and Interfaces
 Binary Replace ability
 Kinds of Components
 Common Modeling Techniques

Names:
Name of every component should be unique, in order to distinguish it from other components
It has simple and path names

Components and Classes:

Classes represent logical abstractions where as components represent physical things representing
physical packaging
Classes have attributes and operations where as components have only operations which are reachable
through their interfaces

Components and Interfaces:

The relationship between component and interfaces can be shown by connecting the component that
realizes interface either by an elided or full realization relationship
In both ways, the component to the interface is connected by dependency relationship

Binary Replace ability:

 25

➤A component is
 Physical, it lives in the world of bits not in concepts
 Replaceable, it is possible to replace a component with another that conforms to the same interfaces
 Part of a system, it rarely stands alone
➤A component conforms to and provides the realization of a set of interfaces

Kinds of Components:
Deployment Components: These components form an executable system like Dynamic Libraries
(DLLs) and Executables (EXEs)
Work Product Components: These components contains source code files and data files from which
deployment components are created
Execution Components: These components are created as a consequence of an executing system, like
COM+ object which is instantiated from a DLL

Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such as
executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system, which is
replaceable and executable. The implementation details of a component are hidden, and it necessitates
an interface to execute a function. It is like a black box whose behavior is explained by the provided
and required interfaces.

Deployment Diagram
The deployment diagram visualizes the physical hardware on which the software will be deployed. It
portrays the static deployment view of a system. It involves the nodes and their relationships.
It ascertains how software is deployed on the hardware. It maps the software architecture created in
design to the physical system architecture, where the software will be executed as a node. Since it
involves many nodes, the relationship is shown by utilizing communication paths.

Modelling

A model is an abstraction of something for the purpose of understanding it before building it.
Because a model omits nonessential details, it is easier to manipulate than the original entity.
Abstraction is a fundamental human capability that permits us to deal with complexity.
Engineers, artists, and craftsmen have built models for thousands of years to try out designs
before executing them. Development of hardware and software systems is no exception. To
build complex systems, the developer must abstract different views of the system, build models
using precise notations, verify that the models satisfy the requirements of the system, and
gradually add detail to transform the models into an implementation.

Designers build many kinds of models for various purposes before constructing things.
Examples include architectural models to show customers, airplane scale models for wind-
tunnel tests, pencil sketches for composition of oil paintings, blueprints of machine parts,
storyboards of advertisements, and outlines of books. Models serve several purposes.
 26

a. Testing a physical entity before building it: The medieval masons did not know modern
physics, but they built scale models of the Gothic cathedrals to test the forces on the
structure. Engineers test scale models of airplanes, cars, and boats in wind tunnels and water
tanks to improve their dynamics. Recent advances in computation permit the simulation of
many physical structures without the need to build physical models. Not only is simulation
cheaper, but it provides information that is too fleeting or inaccessible to be measured from a
physical model. Both physical models and computer models are usually cheaper than
building a complete system and enable early correction of flaws.
b. Communication with customers. Architects and product designers build models to show
their customers. Mock-ups are demonstration products that imitate some or all of the
external behavior of a system.
Modelling

A model is an abstraction of something for the purpose of understanding it before building it.
Because a model omits nonessential details, it is easier to manipulate than the original entity.
Abstraction is a fundamental human capability that permits us to deal with complexity.
Engineers, artists, and craftsmen have built models for thousands of years to try out designs
before executing them. Development of hardware and software systems is no exception. To
build complex systems, the developer must abstract different views of the system, build models
using precise notations, verify that the models satisfy the requirements of the system, and
gradually add detail to transform the models into an implementation.

Designers build many kinds of models for various purposes before constructing things.
Examples include architectural models to show customers, airplane scale models for wind-
tunnel tests, pencil sketches for composition of oil paintings, blueprints of machine parts,
storyboards of advertisements, and outlines of books. Models serve several purposes.

a. Testing a physical entity before building it: The medieval masons did not know modern
physics, but they built scale models of the Gothic cathedrals to test the forces on the
structure. Engineers test scale models of airplanes, cars, and boats in wind tunnels and water
tanks to improve their dynamics. Recent advances in computation permit the simulation of
many physical structures without the need to build physical models. Not only is simulation
cheaper, but it provides information that is too fleeting or inaccessible to be measured from a
physical model. Both physical models and computer models are usually cheaper than
building a complete system and enable early correction of flaws.
b. Communication with customers. Architects and product designers build models to show
their customers. Mock-ups are demonstration products that imitate some or all of the
external behavior of a system.