Uml Notes Rajender Nath Sir PDF

Writer: Ms.
Swati Bansal
Vetter: Prof. Rajender Nath

Lesson 1
Introduction to UML
Structure
1.1 Introduction
1.2 Objectives
1.3 History of UML
1.4 Principles of Modeling
1.5 Overview of UML Views
1.6 Building blocks of UML
1.7 Things of UML
1.7.1 Structural Things
1.7.1.1 Classes
1.7.1.2 Interface
1.7.1.3 Collaboration
1.7.1.4 Use Cases
1.7.1.5 Active Class
1.7.1.6 Components
1
1.7.1.7 Nodes
1.7.2 Behavioral Things
1.7.2.1 Interaction
1.7.2.2 State Machine
1.7.3 Grouping Things
1.7.3.1 Package
1.7.4 Annotational Things
1.7.4.1 Note
1.8 Relationships in UML
1.8.1 Dependency
1.8.2 Association
1.8.3 Generalization
1.8.4 Realization
1.9 Extensibility features
1.9.1 Adornments
1.9.2 Stereotypes
1.9.3 Tagged Values
1.9.4 Constraints
1.10 Summary
1.11 Suggested Readings/Reference Materials
1.12 Self-Assessment Questions
2
1.1 Introduction
UML stands for Unified Modeling Language. It is a standard language for writing software
blueprints used to specify, visualize, construct & document the artifacts of an object-oriented
software intensive system under development. UML is not a programming language but tools
can be used to generate code in various languages using UML diagrams. UML has a direct
relation with object oriented analysis and design. It is described as the successor of object
oriented analysis and design. The basic concepts like abstraction, encapsulation, inheritance,
polymorphism all can be represented in UML. UML notations are the most important element
in modeling. Efficient and appropriate use of notations is very important for making a
complete and meaningful model.
UML is a common language for business analysts, software architects and developers used to
describe, specify, design, and document existing or new business processes, structure and
behavior of artifacts of software systems. It is applied to diverse application domains (e.g.,
banking, finance, internet, aerospace, healthcare, etc). It is used with all major object and
component software development methods and for various implementation platforms (e.g.,
J2EE, .NET).
1.2 Objective
After reading this chapter we will be able to learn what UML is and its history. This chapter
tells about basic building blocks of UML i.e. things, relationships and extensibility features.
Things are the basic elements of UML and relationship tie these things together. Extensibility
3
notations are used to enhance the power of UML. This chapter also includes different views
in UML.
1.3 History of UML
The UML was created and developed by Grady Booch, Ivar Jacobson and James Rumbaugh
at Rational Software during 1994–95. UML is a merged technique which is merged from the
concepts of Booch Methods, Object Modeling Techniques & Object-Oriented Software
Engineering (OOSE). UML combines the best practices from Data Modeling concepts such
as Entity Relationship diagrams, Data Flow, Work Flow diagrams, Object Modeling &
Component Modeling. The UML consist a number of graphical elements that combine to
form diagrams. The purpose of the diagrams is to present multiple views of a system, and this
set of multiple views is called a “Model” In 1997 it was adopted as a standard by the Object
Management Group (OMG), and has been managed by this organization ever since. In 2000
the Unified Modeling Language was also accepted by the International Organization for
Standardization (ISO) as an approved ISO standard. Since then it has been periodically
revised to cover the latest revision of UML.
Versions of UML
• UML 1.0 - 1996
• UML 1.1 - 1997
• UML 1.2 - 1999
• UML 1.3 - 2000
4
• UML 1.4 - 2001
• UML 1.5 - 2003
• UML 2.0 - 2005
• UML 2.1.1 - 2007
• UML 2.1.2 - 2007
• UML 2.2 - 2009
• UML 2.3 - 2010
• UML 2.4.1 – 2011
• UML 2.5 - 2012
1.4 Principles of Modeling
A model is a simplification of reality. Models facilitate communication between the users,
the developers, and other shareholders. A model is an abstraction of something for the
purpose of understanding it before building it. Because, real systems that we want to study
are generally very complex. In order to understand the real system, we have to simplify the
system. So a model is an abstraction that hides the non-essential characteristics of a system
and highlights those characteristics, which are pertinent to understand it. Efraim Turban
describes a model as a simplified representation of reality. A model provides a means for
conceptualization and communication of ideas in a precise and unambiguous form. The
characteristics of simplification and representation are difficult to achieve in the real world,
5
since they frequently contradict each other. Thus modeling enables us to cope with the
complexity of a system.
A model may provide
• Blueprints of a system.
• Organization of a system.
• Dynamics of a system.
We need models because a model helps us
• to visualize a system as it is or we want it to be.
• to specify the structure or behavior of the system.
• in providing a technique that guides us in constructing a system.
• in providing documenting the decisions we have made.
Modeling: Modeling consists of the gradual construction of a cognitively useful – though
simplified and idealized – image of described phenomena. Most modeling techniques used
for analysis and design involve graphic languages. These graphic languages are made up of
sets of symbols. As you know one small line is worth thousand words. So, the symbols are
used according to certain rules of methodology for communicating the complex relationships
of information more clearly than descriptive text.
Modeling is used frequently, during many of the phases of the software life cycle such as
analysis, design and implementation. Modeling like any other object-oriented development,
6
is an iterative process. As the model progresses from analysis to implementation, more detail
is added to it.
Basic principles of modeling are:
• The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped.
• Every model may be expressed at different levels of precision.
• The best models are connected to reality.
• Single model is not sufficient for a system. Every nontrivial system is best approached
through a small set of nearly independent models.
1.5 Overview of UML Views
The “4+1” is view model designed by Philippe Kruchten is for describing the architecture of
software-intensive systems, based on the use of multiple, concurrent views. The views are
used to describe the system from the viewpoint of different stakeholders, such as end-users,
developers and project managers. The four views of the model are logical, development,
process and physical view as shown in Figure 1.1. In addition selected use cases or scenarios
are utilized to illustrate the architecture serving as the 'plus one' view. Hence the model
contains 4+1 views:
7
• Logical view/ Design View: The logical view is concerned with the functionality that
the system provides to end-users. UML Diagrams used to represent the logical view
include Class diagram, Communication diagram, and Sequence diagram.
• Development view/ Implementation view: The development view illustrates a
system from a programmer's perspective and is concerned with software management.
It uses the UML Component diagram to describe system components. UML Diagrams
used to represent the development view include the Package diagram.
• Process view: The process view deals with the dynamic aspects of the system,
explains the system processes and how they communicate, and focuses on the runtime
behavior of the system. The process view addresses concurrency, distribution,
integrators, performance, and scalability, etc. UML Diagrams to represent process
view include the Activity diagram.
• Physical view/ Deployment view: The Deployment View of a system encompasses
the nodes that from the systems hard-ware topology. The “Static“ aspects of this view
are captured using Deployment diagrams whereas the “Dynamic“ aspects of this view
using Interactive, State Chart and Activity diagrams.
• Scenarios/Use Case View: The description of architecture is illustrated using a small
set of use cases, or scenarios which become a fifth view. The scenarios describe
sequences of interactions between objects, and between processes. They are used to
8
identify architectural elements and to illustrate and validate the architecture design.
They also serve as a starting point for tests of an architecture prototype
Implementation
Design View View
Use Case
\
View
Process View Deployment
View
Figure 1.1 Different Views in UML
1.6 Basic Building Blocks of UML
The Vocabulary of UML encompasses three kinds of building blocks. They are
• Things- Things are the elements of system and form the vocabulary of a system.
• Relationships- Relationships tie the things together. Relationship shows how the
elements are associated with each other and this association describes the
functionality of the system.
• Diagrams- Diagrams group the thing together. Diagrams are very important part of
UML building block as they represent the system.
9
1.7 Things of UML
Things are the abstractions of a particular model and they form the vocabulary of the system.
There are four kinds of Things in UML as given below
• Structural Things- define static part of model.
• Behavioral Things- define dynamic part of model.
• Grouping Things- group the elements of model.
• Annotational Things- mechanism to capture remarks, descriptions, and comments of
UML model elements.
1.7.1 Structural Things
Structural things represent the static aspect of the system. The static aspects mean the aspects
that do not change with time. These static aspects represent those parts of the system which
form the main structure and hence stable. These are considered as nouns of UML models.
Following are the list of structural things:
• Classes
• Interface
• Collaboration
• Use case
• Active classes
10
• Components
• Nodes
Now, each of these will be discussed in detail one by one.
1.7.1.1 Classes
A Class is a description of a set of objects that share the same attributes, operations,
relationships & semantics. Class may implement one or more interfaces. Graphically, a class
is rendered as a “Rectangle” with four parts as shown in Figure 1.2
• The top section is used to name the class.
• The second section 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
<<name of class>>
<<attributes >>
<<operations>>
<<additional components>>
Figure 1.2 Class
11
Example of class is shown in Figure 1.3, having Student as class with name, rollno,
section as attributes and read( ), add( ), edit( ) and display( ) as operations. The
additional component may contain the responsibility of the class. Note that class name
begins with capital letter while attribute name and operation name begin with lower
case letter.
Student Name
name: string
rollno: integer
section: string
read( )
add()
edit()
display()
Responsibilities
--manage students in the class
Attributes
Operations
12
Extra components
Figure 1.3 Example of Class
1.7.1.2 Interface
An Interface is a collection of operations that specify “what to do “. It is used to describe
functionality without implementation. Interface is just like template where we define different
functions without implementation. When a class implements the interface it also implements
the functionality as per requirement. Graphically, an interface is rendered as a “Circle” with
its name below it as shown inn Figure 1.4.
Interface name
Figure 1.4 Interface
Example of interface is shown in Figure 1.5 where we have an interface named Student
Application.
13
Student Application
Figure 1.5 Example of interface
1.7.1.3 Collaboration
Collaboration defines an interaction between the elements. It is a classifier in which roles and
responsibilities cooperate to define the internal structure of classifiers. Graphically,
collaboration is rendered as an “Ellipse with Dashed Lines “with a name written inside it as
shown in Figure 1.6.
Name of collaboration
Figure 1.6 Collaboration
Example of collaboration is shown in Figure 1.7 having ‘manage student’ as collaboration.
Manage student
Figure 1.7 Example of collaboration
14
1.7.1.4 Use Case
Use Case is a represents set of actions that a system performs with a particular actor for a
specific goal. Use case is used to capture high level functionality of the system. Use case is
graphically rendered as an “Ellipse with Solid Line” with name inside it as shown in Figure
1.8.
Use case Name
Figure 1.8 Use case
Example of Use case is shown in Figure 1.9(a) and Figure 1.9(b) with the help of banking
system having ‘withdraw money’ and ‘enquire balance’ as use cases.
Withdraw money Enquire balance
Figure 1.9(a) Figure 1.9(b)
1.7.1.5 Active Class
An Active Class is a class where objects own one or more processes or threads to initiate a
control activity. It is used to represent concurrency in the system. Graphically, an active class
is rendered like a class but with Thick Lines “as shown in Figure 1.10.
15
Name
Attributes
Operations
Figure 1.10 Active Class
Example of Active class is shown in Figure 1.11 having mainmenu as a active class.
mainmenu name
+submenunam : string
attributes
+ no_submenu : int
+ additem( ) operations
Figure 1.11 Example of Active Class
1.7.1.6 Component
Component describes physical and replaceable part of a system which provides the
realization of Interfaces. It is used to represent any part of the system for which UML
diagrams can be made. Graphically, a component is rendered as a “Rectangle with Tabs “as
Component Name
Figure 1.12 Component
16
Examples of Component are shown in Figure 1.13(a) and Figure 1.13(b) where Order system
and calculator are two components.
order system calculator
Figure 1.13(a) Figure 1.13(b)
1.7.1.7 Node
Node is a physical element that exists at runtime & represents a computational resource like
memory. Graphically, a node is rendered as a “Cube “including the name as shown in Figure
1.14, and example is shown in Figure 1.15.
Node Name
Figure 1.14 Node
server Name of node
Figure 1.15 Example of node
1.7.2 Behavioral Things
17
Behavioral things represent the dynamic part of the system. They are the ‘verbs’ of the UML
model. Following are the list of behavioral things:
• Interaction
• State Machine
1.7.2.1 Interaction
An Interaction is a behavior that comprises a set of messages exchanged among a set of
objects. Graphically, an interaction message is rendered as a “Directed Arrow Line” including
the name of the operation as shown in Figure 1.16.
Operation name
Figure 1.16 Interaction
1.7.2.2 State Machine
State machine describes different states of components in its life cycle. The state can be
active, idle or any situation depending upon the situation. Graphically, a state is rendered as a
“Rounded Rectangle “with its name and also its state as shown in Figure 1.17.
State name
18
Figure 1.17 State
Example of state is shown in Figure 1.18(a), Figure 1.18(b) and Figure 1.18(c) showing
different states of ATM machine.
idle accepting selecting

PIN menu
Figure 1.18(a) Figure 1.18(b) Figure 1.18(c)
1.7.3 Grouping Things
Grouping things can be defined as a mechanism to group the elements of UML together.
There is only one element available for grouping.
• Package
1.7.3.1 Package
Package is a general purpose mechanism for wrapping the components of system into groups.
Graphically, a package is rendered as a “Tabbed Folder” as shown in Figure 1.19.
Package Name
19
Figure 1.19 Package
Example of package is shown in Figure 1.20 having Account as a package name and it wraps
classes Bank Account, Saving Account and Checking Account.
Account
Bank Account
Owner: string
Balance: int
Deposit( )
Saving Account Checking Account

annuaInterestrate: insufficientFund: int
percentage
withdrawl( ) processCheck( )
Figure 1.20 Example of Package
1.7.4 Annotational Things
Annotational things can be defined as a mechanism to capture remarks, description and
comments of UML model elements. There is one element available for annotational thing.
• Note
20
1.7.4.1 Note
A Note is a special kind of graphical symbol used to provide necessary information of the
system i.e. it can specify comments or constraints. Graphically, a note is rendered as a
“Rectangle with a dog-eared corner “as shown in Figure 1.21.
Note
Figure 1.21 Note
1.8 Relationships in UML
Relationship shows how the elements are associated with each other and this association
describes the functionality of the system. A model is not complete unless the relationship
between the elements is not specified properly. The relationship gives proper meaning to the
UML model. Following are the relationships available in UML:
• Dependency
• Association
• Generalization
• Realization
21
1.8.1 Dependency
Dependency is a relationship between two elements in which change in one element also
affects other element. Dependency is one of the important aspects in UML. It describes the
dependent elements and the direction of dependency. Dependency is represented by a dotted
arrow as shown in Figure 1.22. The arrow head represents the independent element and the
other end represents the dependent element.
Dependent Independent
Figure 1.22 Dependency
Dependency can be between classes as shown in Figure 1.23 by an example which has two
classes Client and Supplier, where Client class is dependent on Supplier class
Client Supplier
************* *************
************* **************
Figure 1.23 Example showing dependency between classes
One more example of dependency is shown in Figure 1.24 having course schedule and
course as two classes, where course schedule depends upon course.
course schedule course
*********** **********
22
*********** **********
Figure 1.24 Example showing dependency between classes
1.8.2 Association
Association is a Structural relationship that describes a set of links that connects elements of
UML. It also describes how many elements are taking part in the relationship. Aggregation is
a special kind of association representing a structural relationship between a whole and its
parts. Graphically, an association is represented by as a “Solid Line” with or without arrows
on both sides as shown in Figure 1.25. The multiplicity is also mentioned at the ends (1, *
etc) to show how many objects are associated.
Name of association
Employee Organization
Figure 1.25 Association
Example of association is shown by two classes Person and Magazine which are associated
with each other having ‘subscribes’ as the association name is shown in Figure 1.26.
Person 0..* subscribes 0..* Magazine
*********** **********
*********** **********
Figure 1.26 Example of Association
23
1.8.3 Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It describes the inheritance relationship. It is a parent and child
relationship. It is represented by a solid line with a hollow arrow head as shown in Figure
1.27.
Child Parent
Figure 1.27 Generalization
Example of Generalization is shown in Figure 1.28 where Vehicle is a superclass and
two_wheelers and three_wheelers are its subclasses.
Vehicle
***********
***********
two_wheelers three_wheelers
*********** ************
*********** ************
24
Figure 1.28 Example of generalization
1.8.4 Realization
Realization can be defined as a relationship in which two elements are connected. One
element describes some responsibility which is not implemented and other one implements it.
This relationship exists in case of interfaces. It is represented by a dashed line with a hollow
arrow head as shown in Figure 1.29.
Figure 1.29 Realization
Example of Realization is shown in Figure 1.30
tube
<<interface>>
Shape
pyramid
Draw ( )
Move ( )
Scale ( )
Rotate ( ) circle
Figure 1.30 Example of realization
25
1.9 Extensibility Notations
All the languages (programming or modeling) have some mechanism to extend its
capabilities like syntax, semantics etc. UML is also having the mechanism to provide
extensibility features. They are used to enhance the power of language. They represent some
extra behavior which is not covered by the standard notations. UML has following
extensibility notations:
• Adornments
• Stereotypes
• Tagged Values
• Constraints
1.9.1 Adornment
Adorn means to enhance. Adornments are the textual or graphical items that are added to an
element’s basic notation and are used to visualize details of the elements.
Example:
(a) Adornment mechanism indicates whether an attribute in a class is public, private or
protected respectively represented by +, - , # as shown in Figure 1.31.
26
(b) Basic notation for as association is a line but this can be adorned with details like role
name and multiplicity at both ends.
In UML, for adornment general rule is to start with basic notation for each element and then
add adornments only as they are necessary to convey specific information that is important
for model.
Most adornments are rendered by placing text near the element or by adding graphical
symbol to basic notation.
Name Student
+ Name: string
public
adornments { protected
private
# Roll: integer
- Section: string
Display()
Add()
Edit()
Attributes
Operation
Figure 1.31 Example of Adornment
1.9.2 Stereotypes
27
A stereotype is an extension of the vocabulary of the UML, allowing creating new kinds of
building blocks similar to existing ones but specific to particular problem. New building
blocks are domain specific and are represented with name in guillements (<< >>) or as a
different icon.
Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes
may extend the semantics, but not the structure of pre-existing types and classes. Certain
stereotypes are predefined in the UML, others may be user defined.
There are three types of Stereotypes
• Named Stereotype
• Named Stereotype with icon
• Stereotyped element as icon
• Named Stereotype (represented with name in guillements)
<<meta class>>
Model element
• Named Stereotype with icon (represented with both name and icon)
<<exception>>
Underflow !
• Stereotyped element as icon
28
Login form
1.9.3 Tagged Values
Many kinds of elements have detailed properties that do not have a visual notation. In
addition, users can define new element properties using the tagged value mechanism. A
tagged value is an extension of the properties of a UML element, allowing us to create new
information in that element’s specification. Commonly used to specify information relevant
to code generation, configuration management etc. A tagged value is a keyword-value pair
that may be attached to any kind of model element. The keyword is called a tag.
Example of Tagged values:
• {Version = 1.3}
• {location = c:\users\abc.txt}
1.9.4 Constraints
Constraints are used to create rules for the model. Rules impact the semantic of the model
and specify the conditions that must be met. Constraints can be apply to any element in the
model, any attribute of a class, any relationship etc. Constraints may be written as free-form
text. If we want to specify semantics more precisely, then UML’s Object Constraint
Language (OCL) can be used.
Constraints using OCL can be specifies as {constraint}
Example: {selling volume in 5 months}
29
1.10 Summary
Hence we can summaries that visualizing, specifying, constructing, and documenting object-
oriented systems are main purpose of the Unified Modeling Language.
• UML is a Language: A Language provides a vocabulary & the rules for
communication that focus on physical & conceptual representation of a system, UML
tells you how to create & read well-formed models, but they don’t tell you what
models you should create and when to create
• UML for Specification: UML address the specification of all the important analysis,
design & implementation decisions that must be made in developing and deploying a
software intensive system.
• UML for Visualizing: UML is such a graphical language that some things can be
modeled textually and some are best modeled graphically.
• UML for Construction: UML is not only a visual programming language but its
models can be directly connected to a variety of programming languages
• UML for Documentation: UML addresses the documentation of a system architecture
and its details, requirements, activities of project planning & release management.
Basic elements of UML are
• Things: They are the abstractions of a particular model. Things are divided into four
categories i.e. structural things, behavioral things, grouping things and annotaional
things.
30
• Relationship: They tie the things together. Generalization, dependency, associations
and realization are relationships in UML.
• Diagrams: They combine things and relationships and represent the system.
• Extensibility notations: They are extra features added to the UML to enhance its
power.
1. Object-Oriented Modeling and Design with UML, M. Blaha, J. Rumbaugh, Pearson
Education-2007
2. Object-Oriented Analysis & Design with the Unified Process, Satzinger, Jackson,
Burd, Thomson-2007
3. Object Oriented Analysis & Design, Grady Booch, Addison Wesley-1994
4. Timothy C. Lethbridge, Robert Laganiere, Object Oriented Software Engineering,
TMH, 2004
1. Define UML. Explain its history?
2. What is Model and what is its importance?
3. What are the principles of modeling?
4. Which view is plus one view in architecture of UML? Explain all the views.
5. Define different structural things in UML.
31
6. What is the difference between Realization and Dependency relationship?
7. Explain generalization relationship with the help of two examples.
8. What are packages and notes? Give some examples of package and note.
9. What are adornments in UML? When and where adornments can be included in UML
diagrams?
10. What are packages and notes? Give some examples of package and note.
11. What do you mean by stereotypes and what are its different types?
32
Writer: Ms. Swati Bansal
Lesson 2
Class Modeling using UML
Structure
2.1 Introduction
2.2 Objective
2.3 Objects
2.4 Class
2.5 Link
2.6 Association
2.7 Generalization
2.8 Inheritance
2.8.1 Single Inheritance
2.8.2 Multiple Inheritance
2.8.3 Multilevel Inheritance
2.8.4 Hierarchical Inheritance
2.8.5 Multipath Inheritance
2.8.6 Hybrid Inheritance
1
2.9 Association ends
2.10 N-ary association
2.11 Aggregation vs Composition
2.12 Abstract Classes
2.13 Metadata
2.14 Reification
2.15 Constraints
2.16 Derived Data
2.17 Conclusion
2
2.1 Introduction
In this chapter, we will present the advanced features of object modeling. In the last chapter,
we discussed model, modeling, things in UML and their relationship. There can be some
attributes, which cannot be associated with either of the two classes related by an association.
Such attributes are called as link attributes. A binary association can have two roles, which
may be written at the ends of the association.
Other relationships between classes are aggregation and inheritance. Aggregation specifies
one object may be composed of other objects. It is a part-whole relationship. Inheritance is a
way to form new classes using classes that have already been defined. Inheritance is intended
to help reuse existing code with little or no modification
2.2 Objective
This chapter will cover several topics which are helpful in drawing Class diagrams. They are
mostly important for complex applications. Objects and classes are basic elements of UML
and they must be properly understood for class modeling. Two or more classes are associated
with association. Binary association connects two classes, ternary association connects three
classes and so on and we can have n-ary association. Aggregation and composition are two
important forms of association with some constraints. In this chapter we will also discuss
Abstract class and metadata. An abstract class has no direct instances and metadata is data
that describes other data
3
2.3 Object
An object is a concept, abstraction, or thing with crisp boundaries and meaning for the
problem at hand. An object has the following four main characteristics:
• Unique identification
• Set of attributes
• Set of states
• Set of operations (behavior)
Unique identification, we mean every object has a unique name by which it is identified in
the system. Set of attributes, we mean every object has a set of properties in which we are
interested in. Set of states we mean values of attributes of an object constitute the state of the
object. Every object will have a number of states but at a given time it can be in one of those
states. Set of operations we mean externally visible actions an object can perform. When an
operation is performed, the state of the object may change.
In other words, an object is an instance of an object class. Figure 2.1 (rounded box)
represents an object instance in OMT. Object instance is a particular object from an object
class. The box may/may not be divided in particular regions. Object instances can be used in
instance diagrams, which are useful for documenting test cases and discussing examples.
(ClassName)
Figure
object 1.5
name
4
Figure 2.1 Object Symbol
Now we give three examples of objects of class Book which are shown in Figure 2.2 (a), (b)
& (c) respectively.
(Book) (Book) (Book)

physics chemistry mathematics
Here we give three examples of objects of class Person which are shown in Figure 2.3 (a), (b)
& (c) respectively.
(Person) (Person) (Person)

mayank kartik kavita
Next we give three examples of objects of class Window which are shown in Figure 2.4 (a),
(b) & (c) respectively.
(Window) (Window) (Window)

excel word access
5
Let us introduce the concept of derived object. It is defined as a function of one or more
objects. It is completely determined by the other objects. Derived object is redundant but can
be included in the object model.
2.4 Class
A class describes a collection of similar objects. It is a template where certain basic
characteristics of a set of objects are defined. A class defines the basic attributes and the
operations of the objects of that type. Defining a class does not define any object, but it only
creates a template. For objects to be actually created, instances of the class are to be created
as per the requirement of the case.
Classes are built on the basis of abstraction, where a set of similar objects is observed and
their common characteristics are listed. Of all these, the characteristics of concern to the
system under observation are taken and the class definition is made. The attributes of no
concern to the system are left out. This is known as abstraction. So, the abstraction is the
process of hiding superfluous details and highlighting pertinent details in respect to the
system under development.
It should be noted that the abstraction of an object varies according to its application. For
instance, while defining a pen class for a stationery shop, the attributes of concern might be
the pen color, ink color, pen type etc., whereas a pen class for a manufacturing firm would be
containing the other dimensions of the pen like its diameter, its shape and size etc.
6
Each application-domain concept from the real world that is important to the application
should be modeled as an object class. Classes are arranged into hierarchies sharing common
structure and behavior and are associated with other classes. This gives rise to the concept of
inheritance.
Through inheritance, a new type of class can be defined using a similar existing class with a
few new features. For instance, a class vehicle can be defined with the basic functionality of
any vehicle and a new class called car can be derived out of it with a few modifications. This
would save the developers time and effort as the classes already existing are reused without
much change.
In OMT, classes are represented by a rectangular box which may be divided into three parts
as shown in Figure 2.5. The top part contains the name of the class written in bold, middle
part contains a list of attributes and bottom part contains a list of operations.
ClassName
Attribute-name1:data-type1=default-val1
Attribute-name2:data-type2=default-val2
…
Operation-name1(arguments1):result-type1
Operation-name2(arguments2):result-type2
...
7
Figure 2.5 Class Symbol
An attribute is a data value held by objects in a class. Each attribute has a value for each
object instance. This value should be a pure data value, not an object. Attributes are listed in
the second part of the class box. Attributes may or may not be shown; it depends on the level
of detail desired. Each attribute name may be followed by the optional details such as type
and default value. An object model should generally distinguish independent base attributes
from dependent derived attributes. A derived attribute is that which is derived from other
attributes. For example, age is a derived attribute, as it can be derived from date-of-birth and
current-date attributes.
An operation is a function or transformation that may be applied to or by objects in a class.
Operations are listed in the third part of the class box. Operations may or may not be shown;
it depends on the level of detail desired. Each operation may be followed by optional details
such as argument list and result type. The name and type of each argument may be given. An
empty argument list in parentheses shows explicitly that there are no arguments. All objects
in a class share the same operations. Each operation has a target object as an implicit
argument. An operation may have arguments in addition to its target object, which
parameterize the operation. The behavior of the operation depends on the class of its target.
An operation may be polymorphic in nature. A polymorphic operation means that the same
operation takes on different forms in different/same classes. Overloading of operators,
overloading of functions and overriding of functions provided by object-oriented
programming languages are all examples of polymorphic operations. A method is the
8
implementation of an operation for a class. The method depends only on the class of the
target object.
Now, we present a number of examples of classes to clarify what we have discussed above.
Figure 2.6 shows the class Book. Attributes of Book are title, author, publisher along with
their data types. Operations on Book are open(), close(), read().
Book
title: string
author:string
publisher:string
open()
close()
read()
Figure 2.6 Book Class
Person
name:string
address:string
phone:integer
changeName()
changeAddress()
changePhone()
Figure 2.7 Person Class
9
Figure 2.7 shows the class Person with name, address & phone along with their data types as
attributes and changeName(), changeAddress() & changePhone() as operations.
Figure 2.8 shows the class Window with xMin, yMin, xMax, yMax along with their data
types as attributes and draw(), cut(), erase() & move() as operations.
Window
xMin:integer
yMin:integer
xMax:integer
yMax:integer
draw()
cut()
erase()
move()
Figure 2.8Window Class
2.5 Link
A link is a physical or conceptual connection between object instances. In OMT, link is
represented by a line labeled with its name as shown in Figure 2.9.
(Class Name) Link-Name (Class Name)

Object Name Object Name
10
Figure 2.9 Link
For example Mayank flies Jaguar. So ‘flies’ is a link between object instance Mayank of class
Person and object instance Jaguar of class Airplane as shown in Figure 2.10. Kartik reads
Physics. Here reads is a link between object instance Kartik of class Person and object
instance Physics of class Book as shown in Figure 2.11.
(Person) (Airplane)
Mayank flies Jaguar
Figure 2.10 Link Example
(Person) 3 reads (Book)

Kartik Physsics
Figure 2.11 Link Example
2.6 Association
11
An association describes a group of links with common structure and common semantics
between two or more classes. Association is represented by a line labeled with the association
name in italics as shown in Figure 2.12.
Class Name Class Name

Association-Name
******* ********
Figure 2.12 Association
Association names are optional. If the association is given a name, it should be written above
the line. Association names are italicized. In case of a binary association, the name reads in a
particular direction (i.e. left to right), but the binary association can be traversed in either
direction. For example, a pilot flies an airplane or an airplane is flown by a pilot. All the links
in an association connect objects from the same classes. Associations are bi-directional in
nature.
Multiplicity: It specifies how many instances of one class may relate to a single instance of an
associated class. Multiplicity constrains the number of related objects.
There are special line terminators to indicate certain common multiplicity values. A solid ball
is the symbol for "many", meaning zero, one or more. A hollow ball indicates "optional",
meaning zero or one. The multiplicity is indicated with special symbols at the ends of
association lines. In the most general case, multiplicity can be specified with a number or set
12
of intervals. If no multiplicity symbol is specified that means a one-to-one association. The
rules of multiplicity are summarized below:
• Line without any ball indicates one-to-one association.
• Hollow ball indicates zero or one.
• Solid ball indicates zero, one or more.
• Numbers written on solid ball such as 1,2,6 indicates 1 or 2 or 6.
• Numbers written on solid ball such as 1+ indicates 1 or more, 2+ indicates 2 or more
etc.
An association can be unary, binary, ternary or n-ary. Unary association is between the same
class as shown in Figure 2.13.
Association-name
Class-Name
*********
Figure 2.13 Unary Association
Example of unary association is 'Person teaches Person as shown in Figure 2.14. Other
examples of unary association can be Person marries a Person, Person manages Person etc.
teaches
Person
*********
13
Figure 2.14 Example of Unary Association
A binary association is an association between two classes as shown in Figure 2.15. It is
represented by a line labelled with an association name. Ends of association can have
multiplicity, role names etc. association is traversed left to right and top to bottom in the
diagram.
Class Name Class Name

Association-Name
******* ********
Figure 2.15 Binary Association
Example of a binary association is “Person sits on a Chair”. One person can sit at one chair.
So multiplicity of this association is one-to-one as shown in Figure 2.16.
Person sits-on Chair
********* *********
Figure 2.16 Binary Association Example
14
Example of a binary association is “Supplier supplies Parts”. One supplier can supply many
parts or one part can be supplied by many suppliers. So multiplicity of this association is
many-to-many as shown in Figure 2.17.
Supplier supplies Parts
********* *********
Figure 2.17 Many-to-many Association
Another example of binary association is “Person possesses a Passport”. Either a person can
have one passport or no passport but one passport can be with one person. So multiplicity of
this association is one-to-optional as shown in Figure 2.18.
Person Passport
possesses
********* *********
Figure 2.18 One-to-optional Binary Association
Another example of binary association is “Company employs Person”. One company can
employ zero, one or more persons but one person can be employed in one company only
(assume). So multiplicity of this association is one-to-many as shown in Figure 2.19.
Company Person
employs
********* *********
15
Figure 2.19 One to Many Association
2.7 Generalization
Generalization is the relation between a class and one or more refined versions of it.
Generalization organizes classes by their similarities and differences, structuring the
description of objects. The class being refined is called the super class and each refined
version is called a subclass. Attributes and operation common to a group of sub classes are
attached to the super class and shared by each subclass. Each subclass is said to inherit the
features of its superclass. Generalization is sometime called " is a" relationship because each
instance of subclass is an instance of superclass as well.
Superclass
***************
Subclass1 Subclass 2 Subclass 3 Subclass n

.
************* ************ ************ … ************
** **** ****
16
Generalization is transitive across an arbitrary number of levels. The term ancestor and
descendent refer to generalization of classes across the multiple levels. An instance of a
subclass is simultaneously an instance of its ancestor classes. Each subclass not only inherits
all the features of its ancestors but adds its own specific attributes and operations as well.
The notation for generalization is a triangle connecting a super class to its subclasses. The
superclass is connected by a line to the apex of the triangle. The subclasses are connected by
lines to a horizontal bar attached to the base of the triangle as shown in Figure 2.20
Example of generalization is shown in Figure 2.21 where Equipment class is superclass and
Pump class, HeatExchanger class and Tank class are subclasses of Equipment class, as Pump,
HeatExchanger and Tank all are Equipments and share the common features of Equipment.
Equipment
name
manufacturer
weight
Pump HeatExchanger Tank
dischargePressure surfaceArea volume

flowRate tubediameter pressure
suctionPressure tubelength
shellPressure
Figure 2.21 Generalization Example
17
Generalization set name is an enumerated attribute that indicates which aspect of an object
is being abstracted by a particular generalization. It is written next to the generalization line
as shown in Figure 2.22. It is optional.
Superclass
*****************
Generalization set name
Subclass 1 Subclass 2 Subclass 3
**************** **************** *****************
Figure 2.22 Generalization with generalization set name
Figure
Color
centerPosition
penThickness
pentype
move
select
rotate
dimensionality
zeroDimensional oneDimensional twoDimensional
orientation orientation
filltype
scale
scale
fill
18
Point
Line Arc Polygon Circle
******
***** ***** ***** *****
******
****** ***** ****** ******
Figure 2.23 Example of generalization with generalization set name
Example of generalization having generalization set name is shown in Figure 2.23 where
Figure class is superclass and ZeroDimensional, OneDimensional and TwoDimensional are
subclasses having ‘dimensionality’ as generalization set name.
Uses of generalization
Generalization is a useful constructor for both modeling and implementation Generalization
facilitates modeling by structuring classes and capturing what is similar and what is different
about classes.
2.8 Inheritance
Base Class/Sub Class/

Parent Class
AttributeName1
AttributeName2
��.
OperationName1()
OperationName2()
�....
Derived Class/Sub
Class/Child Class
AttributeName1
19
AttributeName2
��.
OperationName1()
OperationName2()
�....
Figure 2.24 Inheritance
The inheritance concept was invented in 1967 for Simula. Inheritance is a way to form new
classes using classes that have already been defined. Inheritance is intended to help reuse
existing code with little or no modification. The new classes, known as derived classes (or
child classes or sub classes), inherit attributes and behavior of the pre-existing classes, which
are referred to as base classes (or parent classes or super classes) as shown in Figure 2.24.
The inheritance relationship of sub- and super classes gives rise to a hierarchy.
Employee
empID
name
��.
getEmpID()
getName()
�....
Manager
department
phone
��.
20
getDept()
getPhone()
�....
Figure 2.25 Example of Inheritance
Inheritance is a “is-a” relationship between two classes. For example, Student is a Person;
Chair is Furniture; Parrot is a Bird etc. in all these examples, first class (i.e. Student, Chair,
Parrot) inherits properties from the second class (i.e. Person, Furniture, Bird).
Example of an inheritance: Manager is an Employee. Manager class inherits features from
Employee class as shown in Figure 2.25.
Types of Inheritance
There are many ways a derived class inherits properties from the base class. Following are
the types of inheritance:
• Single Inheritance
• Multiple Inheritance
21
• Multilevel Inheritance
• Hierarchical Inheritance
• Multipath Inheritance
• Hybrid Inheritance
2.8.1 Single Inheritance
Person
name
address
………..
getName()
getAddress()
….....
Student
rollNo
course
………..
getRollNo()
getCourse()
….....
Figure 2.26 Example of Single Inheritance
22
When a (derived) class inherits properties (data and operations) from a single base class, it is
called as single inheritance. For example, Student class inherits properties from Person class
as shown in Figure 2.26.
2.8.2 Multiple Inheritance
When a (derived) class inherits properties (data and operations) from more than one base
class, it is called as multiple inheritance. For example, BoatHouse class inherits properties
from both Boat class and House class as shown in Figure 2.27.
Boat House
BoatHouse
Figure 2.27 Example of Multiple Inheritance
2.8.3 Multilevel Inheritance
Shape
Rectangle
23
Square
Figure 2.28 Example of Multilevel Inheritance
When a (derived) class inherits properties (data and operations) from another derived class, it
is called as multilevel inheritance. For example, Rectangle class inherits properties from
Shape class and Square inherits properties from Rectangle class as shown in Figure 2.28.
2.8.4 Hierarchical Inheritance
When more than one (derived) class inherits properties (data and operations) from a single
base class, it is called as hierarchical inheritance. For example, Chair class, Table class and
Bed class all inherit properties from Furniture class as shown in Figure 2.29.
Furniture
Chair Table Bed
Figure 2.29 Example of Hierarchical Inheritance
2.8.5 Multipath Inheritance
24
When more than one inheritance paths are available between two classes in the inheritance
hierarchy, it is called as multipath inheritance. For example, Carnivorous and Herbivorous
class inherit properties from Animal class. Omnivorous class inherits properties from
Carnivorous and Herbivorous classes. So, there are two alternative paths available from
Animal class to Omnivorous class as shown in Figure 2.30.
Animal
Carnivorous Herbivorous
Omnivorous
Figure 2.30 Example of Multipath Inheritance
2.8.6 Hybrid Inheritance
Mixture of single, multiple, hierarchical and multilevel inheritance forms hybrid inheritance
as shown in Figure 2.31
C Ook
C++ Java
25
C#
Figure 2.31 Example of Hybrid Inheritance
2.9 Association ends
An association end is an end of an association. A binary association has two ends; a ternary
association has three ends and so on. Association ends have following properties:
• Association end names: An association end may have a name. They often appear as
noun in problem description. They are written at end of association end as shown in
figure 2.32 by example where Person and Company are associated with worksfor
association. A person is an employee with respect to a company; a company is an
employer with respect to a person. Association end names disambiguate multiple
references to a class and facilitate navigation. Meaningful names often arise and it is
useful to place the names within the proper context.
employee employer
Person e Company
worksFo
Figure 2.32 Association with Association end name
26
• Multiplicity: Multiplicity can be specified for each association end. It specifies the
number of instances of one class that may relate to a single instance of an associated
class. They are written below the association ends. The most common multiplicities
are
“1” – exactly one
”0..1” – at most one
“*” – many,zero or more
Example showing multiplicity is shown in Figure 2.33 where Person and Company
are associated with worksfor association and multiplicity is many to zero-one.
Person Company
* worksFo 0..1
r
Figure 2.33 Association ends with multiplicity
• Ordering: The objects for a “many” association end are usually just a set. Sometimes
the objects have an explicit order. For example Figure 2.34 shows a workstation
screen containing a number of overlapping windows. Each window on a screen occurs
at most once. The windows have an explicit order. Ordering is shown by writing
“{ordered}” next to the appropriate association end.
{ordered}
Screen Window
1 visibleOn *
27
Figure 2.34 Ordering the objects for an association end
• Qualification: Qualifier attribute disambiguate the objects for a “many” association
end. Figure 2.35 shows the example of qualifier where a bank services multiple
accounts. An account belongs to a single bank. Within the context of a bank, the
account number specifies a unique account. Bank and Account are classes and
accountNumber is the qualifier.
1 0..1
Bank accountNumber Account
Figure 2.35 Qualified Association
• Navigability: An association may be traversed in either direction. However, an
implementation may support only one direction. The UML shows navigability with an
arrowhead on the association end attached to the target class.
• Visibility: Similar to attributes and operations, association ends may be public,
protected or private.
2.10 N-ary association
Associations among three or more classes are known as n-ary association. N-ary association
must be avoided and must be decomposed into binary association with appropriate attributes
28
and qualifiers. The UML notation for n-ary association is a diamond with a diamond with
lines connecting to related classes. If the association has a name, it is written in italics next to
the diamond.
Example of n-ary (ternary) association is shown in Figure 2.36 having three classes Person,
Project and Language. Persons use programming language on projects. This n-ary is an
atomic unit and cannot be subdivided into binary associations without losing information.
Project Language
Programme
r
Person
Figure 2.36 Ternary Association
Another example of ternary association is shown in Figure 2.37 having three classes
Professor, semester and listed Course. A professor teaches a listed course during a semester.
professor
semester listedCourse
Figure 2.37 Example of ternary association
29
2.11 Aggregation vs Composition
UML has 2 forms of part – whole relationships: a general form called aggregation and a
more restricted form called composition.
Aggregation is a ”part/whole” or “part-of” relationship in which objects representing the
‘components’ of something are associated with an object representing ‘assembly’,. It is a
strong form of association in which an aggregate object is made of constituent parts.
Constituents are parts of the aggregate. In UML aggregation is drawn like association, except
a small hollow diamond indicating the assembly end of the relationship.
Example of aggregation is shown in Figure 2.38 where a micro-computer consists of monitor,
system box, mouse and keyboard.
Microcomputer
Monitor System Box Mouse Keyboard
Figure 2.38 Example of Aggregation
Aggregation is a tightly coupled form of association with some extra semantics.
• Aggregation is transitive
30
Example: If A is part of B, B is part of C, and then A is part of C.
• Aggregation is antisymmetric.
Example: If A is part of B, then B is not a part of A.
Composition is a form of aggregation with two additional constraints. A constituent part can
belong to at most one assembly and deletion of assembly object triggers the deletion of all
constituent objects via composition. In UML composition is shown by small solid diamond
next to assembly class.
Example of Composition is shown in Figure 2.39 in which a company consists of divisions; a
division consists of departments, hence a company is indirectly consist of departments.
Company Division Department
Figure 2.39 Example of Composition
2.12 Abstract Classes
An abstract class is a class that has no direct instances but whose descendant classes have
direct instances. Abstract classes are used to define methods that can be inherited by
subclasses. In an inheritance tree, abstract class can’t be a leaf. In UML notation an abstract
class name is listed in an italic font, or may place the keyword {abstract} below or above the
name as shown in Figure 2.40 and Figure 2.41.
Abstract class name in italics
31
Classname
***********
Subclass Subclass
************** *************
Figure 2.40 Abstract class {abstract class name in italics}
Classname
{abstract}
*************
Subclass Subclass
************** **************
Figure 2.41 Abstract class {Abstract class name with keyword}
An abstract class can define the signature for an operation without supplying a corresponding
method. This is called an abstract operation. An abstract operation defines the signature of an
operation for which each concrete class must provide its own implementation.
Employee
yearToDateEarings
32
computePay
FullTimeEmployee Employee
weeklyRate hourlyRate
computePay computePay
Figure 2.42 Example of Abstract class
Example of abstract class and abstract operation is shown in Figure 2.42 having Employee
class as an abstract class. All employees must be either full-time or part-time.
FullTimeEmployee and PartTimeEmployee are concrete classes because they can be directly
instantiated. ComputePay is an abstract operation of class Employee, its signature but its
implementation is not defined. Each subclass must supply a method for its operation.
A concrete class is a class that is instantiable, that is, it can have direct instances. A concrete
class may have abstract subclasses, which in turn must have concrete subclasses. In an
inheritance tree, only concrete class can be leaf classes.
2.13 Metadata
Metadata is data that describes other data. Many real world applications have metadata, such
as catalogs, blueprints and dictionaries. Models are inherently metadata, since they describe
33
the things being modeled. Computer language implementation also uses metadata heavily.
Class definition is also metadata.
Figure 2.43 shows an example of metadata and data. A car model has a model name, year,
base price and a manufacturer. And a physical car has a serial number, color, options and a
owner. A car model is a metadata relative to a physical car which is data.
CarModel PhysicalCar
describes
modelName serialNumber
year color
basePrice options
manufacturer owner
Company Person
Figure 2.43 Example of metadata
2.14 Reification
Reification is the promotion of something that is not an object into an object. It is a helpful
technique for meta applications because it lets to shift the level of abstraction. It is useful to
34
promote attributes, methods, constraints and control information into objects which helps to
describe and promote them as data.
Examples:
• Consider a database manager. A developer could write code for each application so
that it can read and write from files. Instead for many applications it is better to reify
the notion of data services and use a database manager. A database manager has
abstract functionality that provides general purpose solution to access data reliably
and quickly for many users.
• Consider a state-transition diagram. We can use a state-transition diagram to specify
control and then implement it by writing the corresponding code. Instead we can
prepare a metamodel and store a state-transition model as data. A general purpose
interpreter reads the contents of metamodel and executes the intent.
• One more example is shown in Figure 2.44 where an attribute is promoted. This
example promotes the substanceName attribute to a class to capture the many to many
relationship between Substance and SubstanceName.
Substance
substanceName
Reification:
Promote attribute to a
class
35
Substance Substance Name
substanceName
Figure 2.44 Reification
2.15 Constraints
A constraint is a Boolean condition involving model elements such as objects, classes,
attributes, links, generalization sets and associations.
The UML has 2 notations for the constraints:
1) Delimit a constraint with braces as shown in Figure 2.45 where there is a constraint on
length and width.
2) Place it in a ‘Dog-Eared’ comment box as shown in Figure 2.46
Window
Length
Width
{0.8<length/width<1.5}
Figure 2.45 Notation of Constraint
Window
{0.8<length/wi
Length dth<1.5}
Width
36
Figure 2.46 Another notation of constraint
Constraints are expressed in declarative manners which express its intent without its
implementation. Constraints provide criterion for measuring the quality of class model. It
requires several iterations to get the structures of a model right from the prospective of
constraints. Only the important constraint must be enforced within the model structure.
• Constraints on Objects
Constraints on Objects can be shown with following examples:
1) No employs salary can exceed the salary of the employees Boss, this constraint is

boss
Employee
salary
{salary≤ boss.salary}
Figure 2.47 Example of Consraint
2) The age of students in the classroom should be greater than 17, this constraint is
shown in Figure 2.48
3)
Student
Age
name
37
{age>17}
Figure 2.48 Example of constraint
• Constraints on Links
Constraints on Objects can be shown with following examples:
1) Multiplicity is a constraint on links which restrict the no of objects related to a given
object.
2) Qualification is also a constraint by resolving the ‘many’ objects at an association
end.
3) An ordinary association presumes no particular order on the objects but the constraint
{ordered} indicates that the elements of association end have an explicit order that
must be preserved.
2.16 Derived Data
A derived data is a function of one or more elements, which in turn may be derived. A
derived element is redundant, because the other elements completely determine it. Classes,
associations and attributes may be derived.
Generally, it is not a good practice to include derived data because it clusters a model.
Derived elements are only included if they are important application concepts or substantially
ease implementation.
38
Notation for a derived data is a slash in front of the element name. Constraint that determines
the derivation must also be included.
Example of derived attribute is shown in Figure 2.49 where age attribute is derived from
birthdate and current date (age=current date- birthdate).
Person CurrentDate
Birthdate/age
Figure 2.49 Example of derived attribute
2.17 Summary
Several topics are covered in this chapter; there is a summary about all important things
• An object is a concept, abstraction, or thing with identity that has meaning for an
application. A class describes a group of objects with the same attributes
• A link is a physical or conceptual connection among objects and is an instance of an
association. An association is a description of group of links with common structure
and semantics.
• Generalization is a relationship between classes and one or more variants of classes. It
organizes classes by their similarities and differences.
• Aggregation and composition are two forms of association with some constraints.
39
• Aggregation is a strong form of association in which an aggregate object is made of
constituent parts. Association has the properties of transitivity and antisymmetry.
• Composition is a form of aggregation with two additional constraints.
• An abstract class has no direct instance and a concrete class has direct instance.
• Metadata is the data that describes other data. Classes are metadata, since they
describes objects.
2.18 Readings/Reference Materials
Education-2007
Burd, Thomson-2007
TMH, 2004
1. Explain the concept of class and object with the help of example.
2. Explain association. Give two examples of binary association and ternary association.
3. What is inheritance? What are different uses of an inheritance? Explain
4. What is aggregation? How is it different from composition?
40
5. What do you mean by association end? What are its different properties?
6. Explain the concept of abstract class.
7. How constraints can be applied to objects and links? Explain with the help of
example.
8. What is generalization set name and how it is declared?
9. Explain Reification.
41
Writer: Ms Swati Bansal
Vetter: Dr Rajender Nath
Lesson 3
UML Diagrams
Structure
3.1 Introduction
3.2 Objective
3.3 UML diagrams
3.3.1 Structural diagrams
3.3.1.1 Class diagram
3.3.1.2 Object diagram
3.3.1.3 Component diagram
3.3.1.4 Deployment diagram
3.3.2 Behavioral diagrams
3.3.2.1 Activity diagram
3.3.2.2 State diagram
3.3.2.3 Use case diagram
3.3.2.4 Sequence diagram
3.3.2.5 Collaboration diagram
3.4 Summary
1
3.5 Suggested Reading/Reference Materials
3.6 Self- Assessment Questions
2
3.1 Introduction
A UML diagram is a partial graphical representation (view) of a model of a system under
design, implementation, or already in existence. UML diagram contains of graphical
elements (symbols) such as nodes connected with edges (also known as paths or flows)
The UML model of the system may also contain other documentation such as use cases,
which are written as template texts.
The kind of the diagram is defined by the primary graphical symbols shown on the
diagram. For example, a diagram where the primary symbols in the contents area are
classes is class diagram. A diagram which shows use cases and actors is use case
diagram. A sequence diagram shows sequence of message exchanges between lifelines.
UML specification does not preclude mixing of different kinds of diagrams, e.g. to
combine structural and behavioral elements to show a state machine nested inside a use
case. Consequently, the boundaries between the various kinds of diagrams are not strictly
enforced. At the same time, some UML tools do restrict set of available graphical
elements, which could be used when working on specific type of diagram.
3.2 Objective
In this chapter we will discuss different types of UML diagrams. UML diagrams are
divided into two categories i.e. structural and behavioral. Structural diagram includes
class diagram, object diagram, component diagram and deployment diagram. Behavioral
3
diagram includes activity diagram, state diagram, use case diagram, sequence diagram
and collaboration diagram. This lesson will cover all these diagrams with examples.
3.3 UML Diagrams
There are nine UML diagrams as shown in Figure 3.1, which are broadly divided into two
categories:
a) Structural diagrams
b) Behavioral diagrams
Class Object
Diagram Diagram
Component Activity
Diagram Diagram
UML
State DIAGRAMS Sequence
Diagram Diagram
Deployment Collaboration
Diagram Diagram
Use-Case
Diagram
Figure 3.1 UML Diagrams
4
3.3.1 Structural Diagrams
Structural diagram shows static elements of the system. The elements in a structure
diagram represent the meaningful concepts of a system, and may include abstract, real
world and implementation concepts. Structure diagrams do not utilize time related
concepts. However, they may show relationships to the behaviors of the classifiers. The
static parts in these diagrams are represented by classes, interfaces, objects, components
and nodes.
There are four types of structural diagrams in UML:
• Class diagram: It illustrates logical structure.
• Object diagram: It illustrates objects and links
• Component diagram: It illustrates physical structure of the software.
• Deployment diagram: It shows the mapping of software to hardware
configurations.
3.3.1.1 Class Diagram
A class diagram is the main building block in object-oriented modeling. It shows a set of
classes, interfaces, and collaborations and their relationships. These diagrams are the most
common diagram found in modeling object-oriented systems. Class diagrams address the
static design view of a system. Class diagrams that include active classes address the
static process view of a system. Class diagram is not only used for visualizing, describing
5
and documenting different aspects of a system but also for constructing executable code
of the software application.
The class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. They are the only UML diagrams, which can be
mapped directly with object oriented languages. This is the most widely used diagram at
the time of system construction. Purpose of the class diagram can be summarized as:
• It captures analysis and design of the static view of an application.
• It describes responsibilities of a system.
• It provides base for component and deployment diagrams.
• It can be used for forward and reverse engineering.
Elements of Class Diagrams:
• Class: In class diagram a class is represented with rectangular box having three parts
as shown in Figure 3.2:
• The upper part holds the name of the class
• The middle part contains the attributes of the class
• The bottom part gives the methods or operations of the class
Visibility: Notations that must be placed before the member’s name are
+ : public (visible to all members that can access the contents of class)
# : protected (visible to the elements that have a generalization relationship to
the class)
6
- : private (only visible inside the class).
MemberClass Name of the class

- code : string Attribute
private
- name : string
- address : string
+ printmemberinfo( )
public operations
Figure 3.2 Class Symbol with Visibility
Relationship between Classes:
There are four types of relationships between classes:
• Association
• Dependency
• Generalization
• Realization
These relationships have already discussed in Lesson 1(Section 1.8), here we are giving
overview of these relationships.
• Association: Association represents the static relationship shared among the
objects of two or more classes. It is represented by a solid line as shown in Figure
3.3.
Association can also contain some adornments like name of association, multiplicity.
7
(a) Name of Association: It specifies name of relationship between classes and is
written over solid line.
(b) Multiplicity: Multiplicity is a definition of cardinality - i.e. number of elements
by providing an inclusive interval of non-negative integers to specify the allowable
number of instances of described element. Multiplicity interval has some lower
bound and (possibly infinite) upper bound: It is mentioned at corners.
Example :
0..1 zero or one instance
1..1 exactly one instance
0..* zero or more instances
1..* one or more instances
m..n At least m but not more than n instances
Company Name of association Employee
- name: string - name: string

- empnum: number
- empid: number -salary: number
+getname () +getname ()
+getempnum( )
+getemployeeid( ) +getsalary( )
1 employs 1..*
multiplicity
8
Figure 3.3 Association between classes
(c) Aggregation: It is a variant of association relationship. It is an association that
represents a part-whole or part-of relationship. It is a stronger form of association. In
this one end is whole thing and second end is part of it. An aggregation may not
involve more than two classes. An aggregation can be named and have the same
adornments that an association can. It is graphically represented as a hollow diamond
shape on the containing class end as shown in Figure 3.4.
Room 4..* Wall

#type #number
Figure 3.4 Aggregation
• Dependency: Dependency is a relationship between two elements in which
change in one element also affects other element. Dependency is one of the
important aspects in UML. It describes the dependent elements and the direction
of dependency. Dependency is represented by a dotted arrow as shown in Figure
3.5. The arrow head represents the independent element and the other end
represents the dependent element.
Dependent Independent
Figure 3.5 Dependency
• Generalization: Generalization can be defined as a relationship which connects
a specialized element with a generalized element. It describes the inheritance
relationship. It is a parent and child relationship. It is represented by a solid line
with a hollow arrow head as shown in Figure 3.6.
Child Parent
9
• Realization: Realization can be defined as a relationship in which two elements
are connected. One element describes some responsibility which is not
implemented and other one implements it. This relationship exists in case of
interfaces. It is represented by a dashed line with a hollow arrow head as shown
in Figure 3.7.
Figure 3.7 Realization
One simple example of class diagram is shown in Figure 3.8. It shows class diagram
of order system having classes - customer, order, special order and normal order.
Customer Order
Name: string 1 n Date: date

Location: string Number: string
Sendorder( ) Confirm( )
Receiveorder( ) Close( )
SpecialOrder NormalOrder
Date: date Date: date
Number: string Number: string
Confirm( ) Confirm( )
Close( ) Close( )
Dispatch( ) Dispatch( )
Receive( )
Figure 3.8 Class diagram of Order Processing System
10
3.3.1.2 Object Diagram
Object diagram is defined as a graph of instances, including objects and data values. A
static object diagram is an instance of a class diagram. It shows a snapshot of the detailed
state of a system at a point in time.
The purpose of object diagrams is similar to class diagrams. The difference is that a class
diagram represents an abstract model consisting of classes and their relationships whereas
an object diagram represents an instance at a particular moment which is concrete in
nature. It means the object diagram is more close to the actual system behavior.
To capture a particular system, numbers of class diagrams are limited. But if we consider
object diagrams then we can have unlimited number of instances which are unique in
nature. So only those instances are considered which are having impact on the system.
From the above discussion it is clear that a single object diagram cannot capture all the
necessary instances or rather cannot specify all objects of a system. So the solution is:
• First, analyze the system and decide which instances are having important data and
association.
• Second, consider only those instances which cover the functionality.
• Third, make some optimization as the numbers of instances are unlimited.
Elements of Object Diagram:
11
• Objects: An object is a concept, abstraction, or thing with crisp boundaries and
meaning for the problem at hand. Object has already discussed in Chapter 2 (Section
2.3). An object is represented in the same manner as class but with name of object
underlined.
Relationship in Object Diagram:
• Link: Link is an instance of an association. It is a tuple with one value for the each
end of the association, where each value is an instance of the type of the end. Link is
rendered using the same notation as for an association. Solid line connects
instances.
Before drawing an object diagrams the following things can be kept in mind:
• Object diagrams consist of objects.
• The link in object diagram is used to connect objects.
• Objects and links are the two elements used to construct an object diagram.
Example of Object diagram is shown in Figure 3.9 having object diagram of order
management system. Here the customer object (C) is associated with three order objects
(O1, O2 and O3). These order objects are associated with special order and normal order
objects (S1, S2 and N1).
12
C: Customer
O3: Order
O1: Order O2: Order
Number: 54
Number= 12 Number= 31
S1: Special Order S2: Special Order N1: Normal Order

Number= 20 Number= 30 Number= 60
Figure 3.9 Example of Object Diagram
3.3.1.3 Component Diagram
Component diagrams are used to model the components of software. Components are the
elements like executables, libraries, files, and documents etc. which reside in a node. So,
component diagrams are used to visualize the organization and relationship among the
components in a system. These diagrams are also used to make executable systems. These
diagrams are used to hide the specification details and focus on the relationship between
the components. They model the structure of software releases and show how
components integrate with current system design. They model the source code and
13
relationship between files. They have the ability to identify software components what
supports development strategies.
Component diagrams are used during the implementation phase of an application.
Initially the system is designed using different UML diagrams and then when components
are ready then component diagrams are used to get an idea of implementation. These
diagrams are very important because without them application cannot be implemented
efficiently. A well prepared component diagram is also important for other aspects like
application performance, maintenance etc.
Element of Component Diagram:
• Component: Component describes physical and replaceable part of a system which
provides the realization of interfaces. It is used to represent any part of the system for
which UML diagrams can be made. Graphically, a component is rendered as a
“Rectangle with Tabs “as shown in Figure 3.10.
Component Name
Figure 3.10 Component
Relationship in Component Diagram:
• Component Realization: It is specialized realization dependency used to define
classifiers that realize the contract offered by a component in terms of its provided
14
interfaces and required interfaces. A component realization is notated in the same way as
the realization dependency, i.e., as a general dashed line from implementing classifiers to
realized component with hollow triangle as an arrowhead.
Steps to draw component diagram are as follow:
(a) Identify the following components:
• Files used in the system.
• Libraries and other components needed for application.
• Relationship among the components.
(b) Use a meaningful name to identify the components for which the diagram is drawn.
(c) Prepare a layout using tools before producing it.
(d) Don’t forget to use notes for clarifying the important points.
Example of component diagram is shown in Figure 3.11. This is component diagram of
order management system. Here, the components are files (order.java, specialorder.java,
normalorder.java and customer.java). This diagram shows the files in the application and
their relationship. Component diagram can also contain dlls, folders, libraries etc.
Components have component name in angle brackets.
15
<<order.java>>
<<customer.java>> <<specialorder.java>>
<<normalorder.java>>
Figure 3.11 Example of Component diagram
3.3.1.4 Deployment Diagram
Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed. They are used to describe the static
deployment view of software. These diagrams consist of nodes and their relationship.
Nodes are nothing but physical hardware used to deploy the application. Component
diagrams are closely related to deployment diagrams as component diagram shows the
components of software and deployment diagram shows how these components are
deployed in hardware.
Deployment diagrams are useful for system engineers. An efficient deployment diagram
is very important because it controls the performance, scalability, portability and
maintainability of the system.
16
Usage of deployment diagrams can be described as:
• To model the hardware topology of a system.
• To model embedded system.
• To model hardware details for a client/server system.
• To model hardware details of a distributed application.
• Forward and software engineering.
Element of Deployment Diagram:
• Node: Node represents the physical part of the system. It is represented by cube
with its name written inside it.
Relationships in Deployment Diagram:
• Dependency: Nodes can be involved in dependency relationship with other nodes.
It is represented as dashed line with an open arrow head directed from client node
to supplier node.
• Association : It is same relationship as discussed in 3.3.1.1 (Class diagram
relationships)
Example of deployment diagram is shown in Figure 3.12. This figure shows the
deployment diagram of order management system. Here nodes are monitor, modem,
caching server and server. The application is assumed to be web based application which
17
is in a clustered environment using server 1, server 2 and server 3. The user is connecting
to the application using the internet. The control is flowing from the caching server to the
clustered environment.
Internet
Modem
CPU
user
Caching
server
Server1 Server2 Server3
Figure 3.12 Example of deployment diagram
3.3.2 Behavioral Diagrams
Behavioral diagrams show the dynamic behavior of the objects in a system, which can be
described as a series of changes to the system over time.
There are five types of behavioral diagrams in UML:
• Activity diagram: It illustrates the dynamic nature of a system by modeling the
flow of control from activity to activity.
18
• State diagram: It describes the behavior of a system.
• Use Case diagram: It captures the dynamic aspect of the system.
• Sequence diagram: It is an interaction diagram that emphasis time ordering of
messages.
• Collaboration diagram: It is an interaction diagram that emphasizes the
structural organization of the object
3.3.2.1 Activity Diagram
Activity diagrams are the object-oriented equivalents of flow charts and data flow
diagrams from structured development. They illustrate the dynamic nature of a system by
modeling the flow of control from activity to activity. They are used to explore the logic
of a complex operation, ac complex business rule, a single use case, a business process
etc.
Elements of Activity Diagram:
• Activity: It is used a represent a set of action. It is represented by a rounded rectangle
as shown in Figure 3.13
Activity
name
Figure 3.13 Notation of an Activity
19
• Control Flow: It shows the sequence of execution. It is represented by a line with
arrow head as shown in Figure 3.14
Figure 3.14 Notation of Control Flow
• Object Flow: It shows the flow of an object from one activity to another activity. It is
represented by a dotted line with arrow head as shown in Figure 3.15.
Figure 3.15 Notation of Object Flow
• An Initial Node: It shows the beginning of set of actions. It is represented by a filled
circle as shown in Figure 3.16.
Figure 3.16 Notation of an Initial Node
• Final Node: It is used to stop all control flows and object flows. It is denoted by a
hollow circle containing filled circle as shown in Figure 3.17.
Figure 3.17 Notation of Final Node
• Decision Node: It is used to represent a test condition to ensure that the control flow
or object flow only goes down one path. It is represented by a diamond box as shown
in Figure 3.18.
20
[opt. 1] [opt. 2]
Figure 3.18 Notation of Decision Node
• Merge Node: It is used to bring back different decision paths that were created using
a decision node as shown in Figure 3.19.
Figure 3.19 Notation of Merge Node
• Fork Node: It is used to split behavior into set of parallel or concurrent flows of
activities. It is represented by a solid line as shown in Figure 3.20.
Figure 3.20 Notation of Fork Node
21
• Join Node: It is used to bring back together a set of parallel or concurrent flows of
activities. It is represented by a solid line as shown in Figure 3.21.
Figure 3.21 Notation of Join Node
Example of an activity diagram is shown in Figure 3.22. It represents the activity diagram
of Enrollment in University.
[incorrect]
Fill out Obtain help to fill

enrollment forms out forms
[trivial
[correct]
problem]
Enroll in
University Attend University
overview
presentation
Make initial
Enroll in
tuition
Seminar
payment
Figure 3.22 Example of Activity Diagram
22
3.3.2.2 State Diagram
State diagrams are used to describe the behavior of a system. State diagrams describe all
of the possible states of an object as events occur. Each diagram usually represents
objects of a single class and tracks the different states of its objects through the system.
Elements of State Diagram:
• State: A state is a condition during the life of an object during which it satisfies some
condition, performs some activity, or waits for some external event. A state
corresponds to the interval between two events received by an object and describes
the "value" of the object for that time period. A state is an abstraction of an object's
attribute values and links, where sets of value are grouped together into a state
according to properties that affect the general behavior of the object. For instance,
stack is empty or stack is full are different states of the object stack. As state
corresponds to interval between two events received by an object, so it has duration.
The state is designated by a round cornered rectangle as shown in Figure 3.23. State
should be labeled with its name.
State Name
Figure 3.23 State Symbol
23
A substate is a state that is nested in another state. A state that has substates is called a
composite state. A state that has no substates is called a simple state. Substates may
be nested to any level.
• Event: An event is the specification of a significant occurrence. For a state machine,
an event is the occurrence of a stimulus that can trigger a state transition. In other
words, we can say an event is something that happens at a point in time. An event
does not have duration. An individual stimulus from one object to another is an event.
Press a button on mouse, airplane departs from an airport are examples of events.
• Transition: A transition is a relationship between two states indicating that an object
in the first state will perform certain actions and enter the second state(when a
specified set of events and conditions are satisfied). Transition can be self-transition.
It is a transition whose source and target states are the same. Transition is depicted by
an arrow and is labeled with event name as shown in Figure 3.24.
Event Name
Figure 3.24 Event Transition
If a transition is to a composite state, the nested state machine must have an initial
state. If a transition is to a substate, the substate is entered after any entry action for
the enclosing composite state is executed followed by any entry action for the
substate. A transition from the composite state may occur from any of the substates
and takes precedence over any of the transitions for the current substate.
24
• Action: An action is an executable, atomic (with reference to the state machine)
computation. Actions may include operations, the creation or destruction of other
objects, or the sending of signals to other objects (events). An action is an
instantaneous operation. An action represents an operation whose duration is
insignificant compared to the resolution of the state diagram. For instance, disconnect
phone line might be an action in response to an on-hook event for the phone line. An
action is associated with an event.
• Activity: Activity is an operation that takes time to complete. An activity is
associated with a state. ActivityIdle

includes continuous operations such as displaying a
picture on a television screen as well as sequential operations that terminate by
themselves after an interval of time such as closing a valve or performing a
computation. A state may control a continuous activity

Dial Tone such as ringing a telephone
Time-out
bell that persists until an event terminates it causing the transition of the state.
Activity starts on entry to the state and stops on exit. A state may also control a
Recorded
sequential activity such as a robot moving a part that progresses until it completes or
Dialing Message
until it is interrupted by an event that terminates prematurely.
Busy-tone
Example of state diagram is shown in Figure 3.25.

Connecting
Fast Busy
Tone
Ringing
pickup on-hook
Connected
25
Disconnected
timeout
timeout
digit(n) invalid
valid number message done
busy
busy
Called phone answers
Called phone hangs up
Figure 3.25 Example of State Diagram
3.3.2.3 Use Case Diagram
26
To model a system the most important aspect is to capture the dynamic behavior i.e. the
behavior when the system is running. Use case diagram is used to capture the dynamic
aspect of the system. Use case diagrams are used to visualize, specify, construct and
document the behavior of the system during requirement capture and analysis. They
provide a way for developers, domain-experts and end-users to communicate.
Elements of Use Case Diagram:
• Use Case: Use case specifies desired behavior. A use case is a description of a set of
sequences of actions; a system performs to yield an observable result of value to an
actor. Each sequence represents an interaction of actors with the system. It is
represented as an ellipse with name written inside it as shown in Figure 3.22.
name
Figure 3.26 Use case notation
• Actors: An actor represents a set of roles that users of use case play when interacting
with these use cases. An actor can be human or automated systems. Actors are entities
which require help from the system to perform their task or are needed to execute the
system’s functions. They are not the part of systems. They define the environment in
which the system lives. From the perspective of a given actor, a use case does
something that is of value to the actor, such as calculate a result etc. An actor is
represented as a symbol as shown in Figure 3.27
27
Figure 3.27 Actor notation
Example showing Use case and actors is shown in Figure 3.28 having Student and
faculty as Actors and registration, updating grades and output generating are use
cases.
registration
Updating
student grades faculty
Output
generating
Figure 3.28 Example of Use case and actors in Use case diagram
• System Boundary Boxes (optional). We can draw a rectangle around the use cases,
called the system boundary box, to indicate the scope of your system. Anything
within the box represents functionality that is in scope and anything outside the box is
not
Relationships in Use Case Diagram:
28
(a) Relationship between an actor and use case
(b) Relationship between use cases
(a) Relationship Between An Actor And Use Case
• Association: Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with
an interaction described by a use case. Associations are modeled as lines
connecting use cases and actors to one another, with an optional arrowhead on one
end of the line. The arrowhead is often used to indicating the direction of the
initial invocation of the relationship or to indicate the primary actor within the use
case.
(b) Relationship Between Use Cases
Relationship between use cases shows how use cases are related to each other. There
are three relationships that can exist between use cases.
• Generalization
• Include
• Extends
• Generalization: It shows the parent child relationship between the use cases. Use
cases that are specialized versions of other use cases are considered as child. It is
29
represented as hollow triangle towards the generalized use case. Figure 3.29
shows the example of generalization relationship between use cases.
Registratio
n
Non- Graduate
graduate registration
registration
Figure 3.29 Generalization relationship
• Include: One use case always involves the steps of another. These types of
use cases are related with <<include>> relationship. It involves two use cases: base
use case and included use case as shown in Figure 3.30.
<<include>>
base included
Figure 3.30 Include relationship
The base use case explicitly incorporates the behavior of another use case at a
location specified in the base. The included use case never stands alone. It only
occurs as a part of some larger base use case that includes it. This relationship
enables to avoid describing the same flow of events several times by putting the
common behavior in base use case.
30
Example of include relationship is shown in Figure 3.31 where ‘updating grades’
and ‘output generating’ are both base use case and ‘verifying student id’ is
included use case.
Updating
grades <<include>>
Verifying
student id
Output
generating <<include>>
Figure 3.31 Example of Include relationship
• Extend: The “Extend” relationship is used to add incremental behavior to a use case.
It represents the frequent situations in which some initial capacity is defined and later
features are added modularly. It is represented by a dotted line labeled <<extend>>
beginning at extension use case and ending with an arrows pointing to the base use
case as shown in Figure 3.32.
<<extend>>
Extension use Base use case
case
Figure 3.32 Extend relationship
Example of extend relationship is shown in Figure 3.33 where use case submit
timesheet is base use case and sign-off in timesheet is extension use case.
31
<<extend>>
Sign-off on Submit
timesheet timesheet
Figure 3.33 Example of extend relationship
Example of a use case diagram is shown by Hospital management system in Figure 3.34.
Hospital management
Cancel
patient appointment
Make appointment scheduler

<<include>>
Check patient record
<<include>>
doctor
Request medication
<<extends>> Defer payment
Pay bill
Extension point
More treatment clerk
Bill insurance
Figure 3.34 Example of use case diagram
3.3.2.4 Sequence Diagram
32
A sequence diagram is an interaction diagram that emphasis time ordering of messages. It
shows the objects participating in the interaction by their life lines and the messages that
they exchange/ arrange in time sequence. It shows the explicit sequence of messages and
is better for real time specification and for complex scenarios. Sequence diagram along
with class diagram and physical data model are the most important design level models
for modern business application development.
Sequence Diagram has Two Dimensions:
• Horizontal Axis: It represents different objects.
• Vertical Axis: It represents time i.e. it shows the sequence of messages.
Elements of Sequence Diagram:
• Actor: Represents an external person or entity that interacts with the system.
• Object: represents an object in the system or one of its components.
• Unit: represents a sub system, component, unit or other logical entity in the system.
• Separators: Represents an interface or boundary between sub systems, components
or units.
• Group: Groups relate header elements into sub systems or components.
Relationships in Sequence Diagram:
• Message: Message defines one specific kind of communication between lifelines of
an interaction. Message specifies not only the kind of communication but also the
sender and receiver.
33
Construction of Sequence Diagram:
(a) Identify the workflow that we model as separate sequence diagram.
(b) Explore the objects for the individual sequence diagram.
(c) Include messages and conditions in the order of control flow for your
individual sequence diagram.
Example of sequence diagram is shown in Figure 3.35, showing sequence diagram of
library management system.
Catalog Library item Net server
Library user
Look up
Display
Issue
Issue License
Compress
Accept License
Deliver
Figure 3.35 Example of Sequence Diagram
3.3.2.5 Collaboration Diagram
34
A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the object that sends and receives messages. A collaboration diagram has
two features that distinguish it from sequence diagram
(a) PATH: it shows how one object is linked to another object
(b) Sequence Number: it indicates the time order of messages.
A collaboration diagram resembles a flowchart that shows the roles functionality and
behavior of individual objects as well as the overall operation of the system in real time.
Objects are shown as rectangle with naming labels inside. Relationship between the
objects is shown as arrow connecting the relevant rectangles. Messages between objects
connect the relevant rectangles along with the labels that define the message sequencing.
Collaboration diagram are best suited for simple interaction among relatively small
number of objects. As the number of objects and messages grows, a collaboration
diagram can become difficult to read.
Elements of Collaboration Diagram:
• Class Roles: Class roles describe how objects behave. Notation is same as the
notation of object but with no attributes i.e. a rectangle with name underlined and
colon sign.
Relationship in Collaboration Diagram:
• Association roles: Association roles shows which class role are attached to
other class role. It is represented by a solid line.
35
• Messages: Message is a way of communication between class roles. It is
represented by a line with arrow head and having numbering, to show proper sequence
of operations.
Construction of collaboration diagram is as follows:
(a) Firstly, identify the objects that participate in interaction and adorn them as the
vertices in the graph.
(b) Secondly, establish the connection between the objects using links.
(c) Finally, adorn these links with the messages that object send and receive messages.
Example of collaboration diagram is shown in Figure 3.36, showing example of Database
to Browser.
: Database
3. SQL Command 4. Result Set

36
: Server Side Script
2. Search Request 5. Dynamic HTML Page
, : Web Server
1. Search Request 6. Dynamic HTML Page
: Browser
Figure 3.36 Example of Collaboration Diagram
3.4 Summary
• Any complex system is best understood by making some kind of diagrams or
pictures. These diagrams have a better impact on our understanding. So if we look
around then we realize that the diagrams are not a new concept but it is used
widely in different form in different industries.
• UML diagrams are prepared to understand a system in better and simple way. A
single diagram is not enough to cover all aspects of the system. So UML defines
various kinds of diagrams to cover most of the aspects of a system. Diagrams are
generally made in an incremental and iterative way.
37
• The structural diagrams represent the static aspect of the system. Behavioral
diagrams basically capture the dynamic aspect of a system
• A class diagram is the main building block in object-oriented modeling. It shows a
set of classes, interfaces, and collaborations and their relationships.
• Object diagram was defined as "a graph of instances, including objects and data
values. A static object diagram is an instance of a class diagram; it shows a
snapshot of the detailed state of a system at a point in time.
• Component diagrams are used to model the components of software. Components
are the elements like executables, libraries, files, and documents etc.
• Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.
• Activity diagrams are the object-oriented equivalents of flow charts and data flow
diagrams from structured development.
• State diagrams are used to describe the behavior of a system. State diagrams
describe all of the possible states of an object as events occur.
• Use case diagrams are used to visualize, specify, construct and document the
behavior of the system during requirement capture and analysis.
• A sequence diagram is an interaction diagram that emphasis time ordering of
messages. It shows the objects participating in the interaction by their life lines
and the messages that they exchange/ arrange in time sequence.
• A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the object that sends and receives messages.
3.5 Suggested Reading/Reference Materials

38
Education-2007
Burd, Thomson-2007
TMH, 2004
3.6 Self- Assessment Questions
1. What are UML diagrams? What are its different types? Explain the need of UML
diagrams.
2. What is the difference between structural diagrams and behavioral diagrams?
3. What is class diagram? Can we represent private, public and protected in class
diagram?
4. Give one example of class diagram with generalization relationship.
5. Model the relationship between a car and its owners in class diagram. A car can
have several owners over time, but only one or none owner at a time. Also mention
cardinalities, role names, attributes and their types.
6. What is object diagram and how it is related to class diagram? Explain by giving
example.
7. Which diagrams are used to represent physical aspects of the system? Give one
example also.
39
8. Explain ‘Extend’ and ‘Include’ relationship in use case diagram.
9. Draw sequence diagram for reservation for a seat in train.
10. What are the differences between sequence diagram and collaboration diagram?
Compare the two types of diagrams.
11. What is the purpose of a deployment diagram?
40
Lesson 4
State Modeling in UML
Structure
4.1 Introduction
4.2 Objectives
4.3 Presentation of Contents
4.3.1 State
4.3.2 Event
4.3.3 Transition
4.3.4 Condition
4.3.5 Action
4.3.6 Activity
4.3.7 State Diagram
4.3.7.1 When to use state diagram
4.3.7.2 How to use state diagram
4.3.8 Nested states
4.3.9 Signal generalization
4.3.10 Concurrency
4.3.10.1 Aggregate concurrency
4.3.10.2 Concurrency within an object
1
4.3.11 Relationship between class and state model
4.4 Summary
2
4.1 Introduction
The complete OOM revolves around the objects identified in the system. When observed
closely, every object exhibits some characteristics and behavior. The objects recognize and
respond to certain events. For example, considering a Window on the screen as an object, the
size of the window gets changed when resize button of the window is clicked. Here the
clicking of the button is an event to which the window responds by changing its state from
the old size to the new size. While developing systems based on this approach, the analyst
makes use of certain models to analyze and depict these objects.
The state model represents a state/transition view on the model. Main concepts are states,
transitions between states, and events to trigger transitions. Actions can be modeled as
occurring within states. Generalization and aggregation (concurrency) are predefined
relationships.
State model describes those aspects of the system that changes with the time. It is used to
specify and implement control aspects of the system. It depicts states, transitions, events and
actions. An event is an external stimulus from one object to another, which occurs at a
particular point in time. An event is a one-way transmission of information from one object to
another.
The state model is represented graphically by state diagrams. A state corresponds to the
interval between two events received by an object and describes the "value" of the object for
that time period. A state is an abstraction of an object's attribute values and links, where sets
of values are grouped together into a state according to properties that affect the general
behavior of the object. Each state diagram shows the state and event sequences permitted in a
3
system for one object class. State diagrams also refer to other models: actions correspond to
functions in the functional model; events correspond to operations on objects in the object
model. The state diagram should adhere to OMT's notation and exploit the capabilities of
OMT, such as transition guards, actions and activities, nesting (state and event
generalization), and concurrency. With the evolution of UML, new version arises and the
name of state diagram changes from state diagram to state machine. In this chapter, at some
places term ‘state machine’ is used, which means the same as ‘state diagram’.
4.2 Objectives
In this chapter we will learn what is state model and concepts related to state modeling such
as event, state, state transition, action and activity. We will also learn what nested state,
concurrency is and how class and state diagram are related to each other.
4.3.1 State
A state is a condition during the life of an object during which it satisfies some condition,
performs some activity, or waits for some external event. A state corresponds to the interval
between two events received by an object and describes the "value" of the object for that time
period. A state is an abstraction of an object's attribute values and links, where sets of values
are grouped together into a state according to properties that affect the general behavior of the
object. For instance, stack is empty or stack is full are different states of the object stack. A
state corresponds to interval between two events received by an object, so it has duration. The
4
state is designated by a round cornered rectangle as shown in Figure 4.1. State should be
labeled with its name.
State Name
Figure 4.1 State Symbol
A substate is a state that is nested in another state. A state that has substates is called a
composite state. A state that has no substates is called a simple state. Substates may be nested
to any level.
4.3.2 Event
An event is the specification of a significant occurrence. For a state machine, an event is the
occurrence of a stimulus that can trigger a state transition. In other words, we can say an
event is something that happens at a point in time. An event does not have duration i.e. it is
spontaneous. An individual stimulus from one object to another is an event. A button on a
mouse is pressed, a key on a keyboard is pressed, a digit is dialed, an airplane departs from an
airport, an e-mail is sent, password is entered etc. are all examples of events.
4.3.3 Transition
A transition is a relationship between two states indicating that an object in the first state
changes to another state when a specified set of events and conditions are satisfied. It
performs certain actions and enters
5
the second state. Transition is depicted by an arrow and is labeled with event name as shown
in Figure 4.2.
Event Name
Figure 4.2 Event Transition
Transition can be self-transition i.e. a transition whose source and target states are the same.
If a transition is to a composite state, the nested state machine must have an initial state. If a
transition is to a substate, the substate is entered after any entry action for the enclosing
composite state is executed followed by any entry action for the substate.
4.3.4 Condition
A condition is Boolean function of object values, such as “the temperature is below freezing”.
A condition is valid over an interval of time. For example “the temperature is below freezing
from November 15, 1990 to March 4, 1991. A state can also be defined in terms condition.
Condition can be used as guards on transition. A guard condition is a Boolean expression that
must be true in order for a transition to occur. A guard transition fires when its event occurs
but only if the guard condition is true. For example, “when you go out for school in the
morning (event), if it’s raining (condition), then carry umbrella (next state). A guard
condition is checked only once, at the time the event occurs, and the transition fires, if the
condition is true. If the condition becomes true later, the transition does not then fire. A guard
condition is represented as a Boolean expression in square braces on transition as shown in
Figure 4.3.
6
Event [condition]
Figure 4.3 Condition
4.3.5 Action
An action is an executable, atomic (with reference to the state machine) computation. Actions
may include operations, the creation or destruction of other objects, or the sending of signals
to other objects (events). An action is an instantaneous operation. An action represents an
operation whose duration is insignificant compared to the resolution of the state diagram. For
instance, disconnect phone line might be an action in response to an on-hook event for the
phone line. An action is associated with an event.
4.3.6 Activity
Activity is an operation that takes time to complete. Since, an activity has duration so it is
associated with a state. Activity includes continuous operations such as displaying a picture
on a television screen as well as sequential operations that terminate themselves after an
interval of time such as closing a valve or performing a computation. A state may control a
continuous activity such as ringing a telephone bell that persists until an event terminates it
causing the transition of the state. Activity starts on entry to the state and stops on exit. A
state may also control a sequential activity such as a robot moving a part that progresses until
it completes or until it is interrupted by an event that terminates prematurely.
4.3.7 State Diagram in UML
7
State diagrams are used to describe the dynamic behavior of a system. State diagrams
describe all of the possible states of an object as events occur. Each diagram usually
represents objects of a single class and tracks the different states of its objects through the
system.
It relates events and states. A change of state caused by an event is called a transition.
Transition is drawn as an arrow from the receiving state to the target state as discussed in the
previous section. A state diagram is graph whose nodes are states and whose directed arcs are
transitions labeled by event names. State diagram specifies the state sequence caused by an
event sequence. Following are the main purposes of using State diagrams:
• To model dynamic aspect of a system.
• To model life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model states of an object.
4.3.7.1 When to use state diagrams
Use state diagrams to model the behavior of an object through many use cases of the system.
Only use state diagrams for classes where it is necessary to understand the behavior of the
object through the entire system. Not all classes require a state diagram and state diagrams
are not useful for describing the collaboration of all objects in a use case. State diagrams are
combined with other diagrams such as interaction diagram and activity diagrams.
8
4.3.7.2 How to draw state diagrams
State diagrams have very few elements. The basic elements are rounded boxes representing
the state of the object and arrows indicting the transition to the next state. The activity section
of the state symbol depicts what activities the object is doing while it is in that state as shown
Figure 4.4 below.
State Name
do /activity
Event Name/Action [Guard]
State Name
do /activity
Figure 4.4 Activity & Transition
List of elements of State Diagram is as follows:
• Initial and Final States
• Transitions
• State Actions
• Self-Transitions
9
• Compound States
• Entry Point
• Exit Point
• Choice Pseudo-State
• Junction Pseudo-State
• Terminal Pseudo-State
• History States
• Concurrent Regions
Each of these elements is discussed here one by one.
Initial and Final States: All state diagrams begin with an initial state of the object. It is
represented by solid as shown in Figure 4.5. This is the state of the object when it is created.
After the initial state the object begins changing its states. Conditions based on the activities
can determine what the next state the object transitions to. For example, in a car gear system,
the initial state is neutral. In a telephone, the initial state is idle.
Initial state
state1 condition state2

do / activity
condition
state3
10
Figure 4.5 Initial State
The initial state is denoted by a solid ball and may be labeled with a name also. The final
state is denoted by bull’s eye and may also be labeled with a name as shown in Figure 4.6.
create destroy
Alive
initial final
Figure 4.6 Initial and Final States
Transitions: Transitions from one state to the next are denoted by lines
with arrowheads. A transition may have a trigger, a guard and an effect,
as shown in Figure 4.7 below.
Trigger[Guard]/Effect
Source state Target state
Figure 4.7 Trigger, Guard and Effect
Trigger is the cause of the transition, which could be a signal, an event, a change in some
condition, or the passage of time. Guard is a condition, which must be true in order for the
trigger to cause the transition. Effect is an action, which is invoked directly on the object that
owns the state machine as a result of the transition.
11
State Actions: In the transition example above, an effect was associated with the transition. If the
target state had many transitions arriving at it, and each transition had the same effect associated with
it, it would be better to associate the effect with the target state rather than the transitions. This can be
done by defining an entry action for the state. The diagram in Figure 4.8 below shows a state with an
entry action and an exit action. It is also possible to define actions that occur on events, or
actions that always occur. It is possible to define any number of actions of each type.
Receiving
+ On Entry / pickup
+ On Exit / disconnect
Figure 4.8 Entry and Exit Actions
Self-Transitions: A state can have a transition that returns to itself, as shown
in the Figure 4.9. This is the most useful when an effect is associated with the transition.
After 2 second / poll input
Waiting
Figure 4.9 Self-Transitions:
Compound States: A substate is a state that is nested in another state. A state that has
substates is called a composite state. A state that has no substates is called a simple state.
Substates may be nested to any level.
A state diagram may include sub-machine diagrams, as in Figure 4.10 below. The alternative way to
show the same information is as shown in Figure 4.11. The notation in the above version
indicates that the details of the Check PIN sub-machine are shown in a separate diagram.
12
Check PIN
Enter
PIN
PIN
Invalid
Valid PIN
[PIN OK]
[Pin ok]
Search network Power off

Power
Network found off
Ready Power Off

off
Figure 4.10 Compound States
Check PIN
∞
[Pin ok]
Search network Power off

Power
Network found off
13
Ready Power Off
off
Figure 4.11 Compound States
Entry Point: Sometimes we won’t want to enter a sub-machine at the
normal initial state. For example, in the sub-machine shown in Figure
4.12, it would be normal to begin in the “Initializing” state, but if for some
reason it wasn’t necessary to perform the initialization, it would be
possible to begin in the “Ready” state by transitioning to the named entry
point.
initializing
ready
Skip initializing
Figure 4.12 Entry Point
Exit Point: In a similar manner to entry points, it is possible to have named
alternative exit points. The Figure 4.13 gives an example where the state executed after
the main processing state depends on which route is used to transition out of the state.
14
Figure 4.13 Exit Point
Choice Pseudo-State: A choice pseudo-state is shown as a diamond with one
transition arrives and two or more transitions leaving. The Figure 4.14 shows
that whichever state is arrived at, after the choice pseudo-state, is dependent on the message format
selected during execution of the previous state.
15
Figure 4.14 Choice Pseudo-State
Junction Pseudo-State: Junction pseudo-states as shown in Figure 4.15 are used to chain together
multiple transitions. A single junction can have one or more incoming, and one or more outgoing, transitions; a guard can be applied
to each transition. Junctions are semantic-free. A junction, who splits an incoming transition into multiple outgoing transitions
realizes a static conditional branch, as opposed to a choice pseudo-state which realizes a state conditional branch.
Figure 4.15 Junction Pseudo-State
Terminate Pseudo-State: Entering a terminate pseudo-state indicates that the
lifeline of the state machine has ended. A terminate pseudo-state is
denoted as a cross as shown in Figure 4.16.
16
Figure 4.16 Terminate Pseudo-State
History States: A history state is used to remember the previous state of a
state machine when it was interrupted. The diagram shown in Figure 4.17
illustrates the use of history states. The example is a state machine
belonging to a washing machine.
In this state machine, when a washing machine is running, it will progress from "Washing"
through "Rinsing" to "Spinning". If there is a power cut, the washing machine will stop
running and will go to the "Power Off" state. Then when the power is restored, the Running
state is entered at the "History State" symbol meaning that it should resume where it last left-
off.
17
Figure 4.17 History State
Concurrent Regions: A state may be divided into regions containing sub-
states that exist and execute concurrently. Figure 4.18 shows that within the state
“Applying Brakes”, the front and rear brakes will be operating simultaneously and independently. Notice
the use of fork and join pseudo-states, rather than choice and merge pseudo-states. These symbols are
used to synchronize the concurrent threads.
A state machine diagram models the behavior of a single object, specifying the sequence of
events that an object goes through during its lifetime in response to events.
As an example, the following state machine in Figure 4.19 shows the
states that a door goes through during its lifetime.
18
Figure 4.18 Concurrent Regions
Figure 4.19 State Diagram for an Automated Door
The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to the
events Open, Close, Lock and Unlock. Notice that not all events are valid in all states; for
example, if a door is opened, you cannot lock it until you close it. Also notice that a state
19
transition can have a guard condition attached: if the door is Opened, it can only respond to
the Close event if the condition door Way-> isEmpty is fulfilled.
Let us take another example of the state diagram for an Order object as shown in Figure 4.20.
When the object enters the Checking state it performs the activity “check items.” After the
activity is completed the object transitions to the next state based on the conditions [all items
available] or [an item is not available]. If an item is not available the order is canceled. If all
items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity “initiate delivery” is performed. After this activity is complete
the object transitions again to the Delivered state.
Figure 4.20 State Diagram for an Order Object
State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to a certain state. Instead of showing all of the transitions from each state to
20
the redundant state a super-state can be used to show that all of the states inside of the super-
state can transition to the redundant state. This helps make the state diagram easier to read.
Figure 4.21 shows a super-state. Both the Checking and Dispatching states can transition into
the Canceled state, so a transition is shown from a super-state named Active to the state
Cancel. By contrast, the state Dispatching can only transition to the Delivered state, so we
show an arrow only from the Dispatching state to the Delivered state.
Figure 4.21 Super-state
When drawing a state machine diagram the thing we want to do is to identify the creation
state and whether any final states exist. After we have done this, ask you what other states or
stages in the life of an object does it pass through? We can often find states by looking at the
boundary values of your attributes.
21
Once we have identified as many states as we can, start looking for transitions. For each state,
ask yourself how the object can get out of it, if possible. This will give us a transition.
Because all transitions lead from one state to another, ask yourself what new state the
transition leads us to (don’t forget about recursive transitions that lead to the same state). We
should also look at the methods we identified in our class diagram. Some of them will
correspond to a transition in our state diagram.
Another illustrative example of state diagram is shown in Figure 4.22 below.
Figure 4.22 Bank Account Updation
22
It shows the bank transaction and verification of bank account. Activities are shown in the
state such as do: update account, do: verify card number and do: verify password. Diagram
also shows initial and final states.
Idle
pickup on-hook
Dial Tone Time-out

timeout
timeout Recorded
Dialing Message
Busy-tone
digit(n) invalid
Connecting
Fast Busy
Tone valid number message done
busy
Ringing
busy
Called phone answers

Connected
Called phone hangs up

Disconnected
23
Figure 4.23 State diagram to make a phone call on land line phone
Now, we consider one more example of state diagram for phone line is shown Figure 4.23. A
phone can have many states such as idle, dial tone, dialing, connecting ringing etc. various
states and events are shown in figure below.
4.3.8 Nested states
States can be structured more deeply than just replacing a state with submachine. States are
nested to show their commonality and share behavior.
Figure 4.24 shows a state diagram for an automobile automatic transmission having nested
states. The transmission can be in reverse, neutral or forward; if it is in forward, it can be in
first, second or third gear. States First, Second and Third are nested states of state forward.
Push R
Neutral Reverse
Push N
Forward
Stop upshift upshift

First Second Third
downshift downshift
Figure 4.24 Nested states
4.3.9 Signal generalization
24
Signals can be organized into a generalization hierarchy with inheritance of signal attributes.
A signal hierarchy permits different levels of abstraction to be used in a model. For example,
some states might handle all input characters the same; other states might treat control
characters differently from printing characters; still others might have different activities on
individual characters.
Figure 4.25 shows signal hierarchy with an example of workstation. Signals Mouse Button
and Keyboard Character are two kinds of User Inputs. Both signals inherit attribute device
from signal User Inputs. Mouse Button Down and Mouse Button Up inherit location from
Mouse Button. Keyboard Characters can be divided into Control and Graphics Characters.
Ultimately actual signals can be viewed as a leaf on a generalization tree of signals. In a state
diagram, a received signal triggers transitions that are defined for any ancestor signal type.
<<signal>>
User Input
device
<<signal>>
Mouse Button <<signal>>
location Keyboard character
character
<<signal>> <<signal>> <<signal>> <<signal>>

Mouse Button Down Mouse Button Up Control Graphics
<<signal>> <<signal>> <<signal>>

Space Alphanumeric puntuation
25
Figure 4.25 Signal Generalization
4.3.10 Concurrency
Concurrency is a property of systems in which several computations are executing
simultaneously, and potentially interacting with each other. In state model objects can act and
change their states independently. However, objects need not be completely independent and
may be subject to share constraints that cause some correspondence among their state
changes
4.3.10.1 Aggregate Concurrency
A state model describes a set of concurrent objects, each with its own state and state diagram.
The objects are inherently concurrent and can change state independently. A complete system
cannot be represented by a single state diagram; it is product of all the states of all the objects
in it. A state diagram is an assembly of a collection of state diagrams, one for each
component. Aggregate state corresponds to combined states of all the component diagrams.
Aggregate is the “and-relationship”. Interaction between the state diagrams is allowed by
guarded conditions.
Figure 4.26 shows the state of Car as an aggregation of component states: Ignition,
Transmission, Accelerator and Brake. Each component state also has substates. Each
component undergoes transition in parallel with all the others.
26
Figure 4.26 Aggregate concurrency
4.3.10.2 Concurrency within an object
Concurrency within the state of an object arises when the objects can be partitioned into
subsets of attributes or links. Each of the partitioned subset has its own subdiagram. The sub
diagrams need not be independent; the same event can cause transitions in more than one
subdiagram. Concurrency within a single composite state of an object is shown by
partitioning the composite states into subdiagrams with dotted lines. The name of the overall
composite state can be written in the separate region of the box, separated by a solid line from
27
the concurrent subdiagrams. Figure 4.27 shows the example of concurrency within an object.
In this example installation is divided into two hardware test and software test.
installation
hardware test
test ports test devices
software test
test modules test application
Figure 4.27 Concurrency within an object
4.3.11 Relationship between class and state model
The state model specifies allowable sequences of changes to objects from the class model. A
state diagram describes all or part of the behavior of the objects of a given class. States are
equivalence classes of values and links for an object.
State structure is related to and constraint by class structure. A nested state refines the values
and links that an object can have. Both generalizations of classes and nesting of state partition
the set of possible object value. A single object can have different states over time but it
cannot have different classes.
28
A composite state is the aggregation of more than one concurrent substate. There are three
sources of concurrency within the class model. The first is aggregation of objects, the second
is aggregation within an object and third source is concurrent behavior of an object.
The state model of a class is inherited by its subclasses. The subclasses inherit both the states
of ancestor and the transition. The subclasses can have their own state diagrams. The signal
hierarchy is independent of the class hierarchy for the class exchanging signals. Signals can
be defined across different classes of objects. Signals are more fundamental than states and
parallel to classes. States are defined by the interaction of objects and events. Transition can
often be implemented as operations on objects. Signals are more expressive than operations,
however, because the effect of a signal depends not only on the class of an object but also on
its state.
4.4 Summary
• The state model represents a state/transition view on the model. Main concepts are
states, transitions between states, and events to trigger transitions. Actions can be
modeled as occurring within states.
• The state model is represented graphically by state diagrams (state machine) as well
as scenarios and event trace diagrams.
29
• A state corresponds to the interval between two events received by an object and
describes the "value" of the object for that time period. A state can be simple or
compound.
• An event is an external stimulus from one object to another, which occurs at a
particular point in time. An event is a one-way transmission of information from one
object to another.
• A transition is a relationship between two states indicating that an object in the first
state will, when a specified set of events and conditions are satisfied, perform certain
actions and enter the second state. Transition can be self-transition. It is a transition
whose source and target states are the same.
• An action is an executable, atomic (with reference to the state machine) computation.
Actions may include operations, the creation or destruction of other objects, or the
sending of signals to other objects (events). An action is an instantaneous operation.
• An activity is associated with a state. Activity includes continuous operations such as
displaying a picture on a television screen as well as sequential operations that
terminate by themselves after an interval of time such as closing a valve or
performing a computation.
• Each state diagram shows the state and event sequences permitted in a system for one
object class. State diagrams also refer to other models: actions correspond to functions
30
in the functional model; events correspond to operations on objects in the object
model.
• States are nested to show their commonality and share behavior.
• In state model objects can act and change their states independently. However, objects
need not be completely independent.
• The state diagram should adhere to OMT's notation and exploit the capabilities of
OMT, such as transition guards, actions and activities, nesting (state and event
generalization), and concurrency.
Education-2007
Burd, Thomson-2007
TMH, 2004
1. What is state model? How is it represented?
2. Define the following concepts with examples and their notations:
31
State, Event, Transition, Action, and Activity
3. What is a state diagram? Draw a state diagram for an answering machine.
4. Distinguish between the following:
a. State and Event
b. Simple and Compound States
c. Action and Activity
d. Initial and Final states
e. Entry and Exit Point
5. Moving a bag of corn, a goose, and a fox across the river in a boat. Only one thing
may be carried in the boat at a time. If the goose is left alone with the corn, the corn
will be eaten. If the goose is left alone with the fox, the goose will be eaten. Prepare
two scenarios one in which something gets eaten and one in which everything is
safely moved across the river.
6. Prepare a state diagram for selecting and dragging items with the diagram editor.
7. Explain choice pseudo states, junction pseudo states and history states with suitable
examples.
8. What are concurrent regions? How are they depicted in the state diagrams? Explain
with an example.
9. Define nested state with example.
10. What is concurrency? How it can be shown in state model.
11. What is relationship between class model and state model?
32
Writer: Swati Bansal
Lesson 5
Interaction Modeling
Structure
5.1 Introduction
5.2 Objectives
5.3.1 Use Case Model
5.3.1.1 Actors
5.3.1.2 Use Cases
5.3.1.3 Include relationship
5.3.1.4 Extend relationship
5.3.1.5 Use Case Diagrams
5.3.2 Sequence Model
5.3.2.1 Scenarios
5.3.2.2 Sequence Diagrams
5.3.3 Activity Model
5.3.3.1 Activities
5.3.3.2 Branches
1
5.3.3.3 Concurrent activities
5.3.3.4 Swim Lanes
5.3.3.5 Activity Diagrams
5.4 Summary
2
5.1 Introduction
This chapter is based on interaction modeling. The interaction model is the third leg of the
modeling tripod and describes the interaction within a system. The class model describes the
objects in a system and their relationship, the state model describes the life cycles of the
objects, and the interaction model describes how the objects interact.
Interaction model is modeled at different levels of abstraction. At higher level, use cases
describe how a system interacts with outside actors. Sequence diagram provides more detail
and shows the messages exchanged among a set of objects over time. And finally, activity
model provides further detail and show the flow of control among the steps of a computation.
5.2 Objectives
In this chapter we will discuss Use Case Model, Sequence Model and Activity Model. Use
Case Model includes actors and use cases as main entities having include and extend
relationship between use cases. Sequence Model includes scenarios. Activity Model includes
activity, branches, concurrent activities and swim lanes.
5.3.1 Use Case Model
3
The Use Case Model describes the proposed functionality of the new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the system. A
Use Case is a single unit of meaningful work; for example login to system, register with
system and create order are all Use Cases. Each Use Case has a description which describes
the functionality that will be built in the proposed system. A Use Case may 'include' another
Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases are
typically related to 'actors'. An actor is a human or machine entity that interacts with the
system to perform meaningful work.
5.3.1.1 Actors
An actor is an object or set of objects that communicates directly with the system. Actor is an
external user of system and not the part of system. An actor is connected in a particular way
towards the system. An actor can be person, devices and other systems that interact directly
with the system.
Examples of actors are customer and repair technician in a vending machine. Notation of an
actor in use case diagram is shown in Figure 5.1.
Name of actor
Figure 5.1 Notation of Actor
4
An object can be bound to multiple actors if it has different facets to its behavior. For
example, the objects Ravi, Amit and Atul may be costumer of a vending machine. Atul may
also be a repair technician for the vending machine. An actor has a single well defined
purpose where as objects and classes have many purposes. An actor represents a particular
facet of objet in its interaction with a system. The same actor can represent objects of
different classes that interact similarly towards a system.
Actors help to define a system by identifying the objects within the system and those on its
boundary. An indirectly connected objet is not an actor and should not be included as a part
of system model.
5.3.1.2 Use Cases
Use cases are a means of communicating with users and other stakeholders what the system
is intended to do. A use case is a single unit of meaningful work. It provides a high-level
view of behavior observable to someone or something outside the system. The notation for a
use case is an ellipse as shown in Figure 5.2.
Use case
name
Figure 5.2 Notation of use case
Example in checking system, check paper, give marks are use cases. Each use case involves
one or more actors as well as the system itself. In a telephone system, the use case make a
5
call involves two actors, a caller and a receiver. A use case involves a sequence of messages
among the system and its actors. Example, in the buy a beverage use case, the customer first
inserts a coin and the vending machine display the amount deposited. This can be repeated
several times. Then the customer pushes a button to indicate a selection; the vending machine
dispenses the beverage and issues, if necessary.
A use case brings together the entire behavior relevant o a slice of system functionality. This
includes normal mainline behavior, variation on normal behavior, exception conditions, error
conditions and cancellation of a request.
5.3.1.3 Include relationship
An “Include” relationship is used to indicate that a particular Use Case must include another
use case to perform its function. A Use Case may be included by one or more Use Cases, so it
reduces duplication of functionality. It is represented by a dotted line labeled <<include>>
beginning at base use case and ending with an arrows pointing to the include use case as
shown in Figure 5.3. An included use case is like a subroutine that represents behavior that
would otherwise have to be described repeatedly. The included use case may or may not be
usable on its own.
<<include>>
Base use Included
case use case
Figure 5.3 Notation of include use case
6
Example of include use case is shown in Figure 5.4 where Checkout use case include several
use cases- Scan item, Calculate total and Tax, and Payment.
Scan item
<<include>>
Checkout <<include>>
Calculate
total and tax
<<include>>
Payment
Figure 5.4 Example of include use case
One more example of include use case is shown in Figure 5.5 where Deposit fund and
Withdraw Cash use cases include Customer Authentication use cases.
Deposit
funds <<include>>
Customer
authentication
Withdraw
cash <<include>>
Figure 5.5 Example of include use case
7
A use case can also be inserted within a textual description with the notation include use case
name. An included use case is inserted at a specific location within the behavior sequence of
the larger use case,, just as a subroutine is called from a specific location within another
subroutine.
5.3.1.4 Extend relationship
The “Extend” relationship is used to add incremental behavior to a use case. It represents the
frequent situations in which some initial capacity is defines and later features are added
modularly. It is represented by a dotted line labeled <<extend>> beginning at extension use
case and ending with an arrows pointing to the base use case as shown in Figure 5.6.
<<extend>>
Extension use Base use case
case
Figure 5.6 Notation of Extend relationship
Example of extend relationship is shown in Figure 5.7 where use case submit timesheet is
base use case and sign-off in timesheet is extension use case.
<<extend>>
Sign-off on Submit
timesheet timesheet
8
The extension use case often is a fragment that is; it cannot appear alone as a behavior
sequence. The base use case, however, must be a valid use case in the absence of any
extension. The extend relationship can specify an insert location within the behavior
sequence of the base use case; the location can be a single step in the base sequence or a
range of steps. This feature of inserting location is known as extension point. A condition can
also be attached with extend relationship in a comment note attached to the corresponding
extend relationship as shown in Figure 5.8. The extension behavior occurs only if the
condition is true when control reaches the insert location.
Condition: {user clicked help link}

Extension point: Registration Help
Registration Get Help on

Extension points Registration
Registration Help <<extend>>
Figure 5.8 Example of extend relationship with condition and extension point
One more example of extend relationship is shown in Figure 5.9, where use case attend
engineering college is mandatory for student while go to canteen is optional.
<<extend>>
Attend
Engineering Go to canteen
College
9
5.3.1.5 Use Case Diagrams
Use case diagram provides an overview of the intended functionality of the system. These
diagrams capture the dynamic behavior of the system. Use case diagrams are used to gather
the requirements of a system including internal and external influences. These requirements
are mostly design requirements. A system involves set of use cases and set of actors. Each
use case represents a slice of functionality of the system at some level of detail. Each actor
represents the complete set of objects that the system can serve. A rectangle contains the use
cases for a system with the actors listed on the outside. The name of the system may be
written near a side of the rectangle. A name within an ellipse represents the use case.
Example of a use case diagram is shown by Hospital management system in Figure 5.10.
Guidelines for use case model:
• First determine the system boundary.
• Ensure that actors are focused.
• Each use case must provide values to users.
• Relate use cases and actors.
• Use cases are informal.
10
Hospital management
Cancel
patient appointment
Make appointment scheduler

<<include>>
Check patient record
<<include>>
doctor
Request medication
<<extends>> Defer payment
Pay bill
Extension point
More treatment clerk
Bill insurance
Figure 5.10 Example of use case diagram
5.3.2 Sequence Model
The Sequence model shows the collaboration of objects based on a time sequence. It shows
how the objects interact with others in a particular scenario of a use case.
5.3.2.1 Scenarios
11
A scenario is a sequence of events that occurs during one particular execution of a system.
Each basic execution of the system should be represented as a scenario. The scope of scenario
may vary. It may include all events in the system or it may include only those events
generated by certain objects. A scenario can be written as a list of text statements.
Figure 5.11 shows a scenario to use ATM for withdrawing money. Each event transmits
information from one object to another. For example, the event “the ATM asks the user to
insert a card” transmits a signal from the ATM to the User. The next event is “the user inserts
a cash card”. The next event is “the ATM accepts the card and reads its serial no.” and so on.
Normal ATM scenario

1. The ATM asks the user to insert a card
The user inserts a cash card

2. The ATM accepts the card and reads its serial number.
3. The ATM requests the password
The user enters 1234

4. The ATM verifies the serial number and password with the
consortium
The consortium checks it with bank ABC and notifies the ATM of
acceptance
5. The ATM requests amount
The user enters 15000

6. The ATM processes the request and dispenses the required
amount of money.
Figure 5.11 Scenario to withdraw money from ATM
5.3.2.2 Sequence Diagrams
12
Sequence diagram shows the participants in an interaction and the sequence of messages
among them. A sequence diagram shows the interactions of a system with its actor to perform
all or parts of a use case. Sequence diagrams are used because a text format is convenient for
writing but it does not clearly show sender and receiver of each message.
In sequence diagram each actor as well as the system is represented by a vertical line called a
lifeline and each message by a horizontal arrow from sender to receiver. Time proceeds from
top to bottom, but the spacing is irrelevant; the diagram shows only the sequence of
messages, not their exact timing.
Example of sequence diagram for a stock purchase is shown in Figure 5.12.

: Customer : StockBrokerSystem : SecuritiesExchange
Enter purchase data

{verify funds}
Request confirmation
Confirm purchase
Display order number Place order
Report results of trade
Figure 5.12 Example of sequence diagram
Each use case requires one or more sequence diagrams to describe its behavior. Each
sequence diagram shows a particular behavior sequence of the use case. Conditions can be
13
shown in sequence diagram. Sequence diagram for each exception condition within the use
case should also be prepared.
5.3.3 Activity Model
Activity model is intended to model both computational and organizational processes (i.e.
workflows). Activity model show the overall flow of control. They include activity diagrams.
Activity diagrams may be regarded as a form of flowchart. Typical flowchart techniques lack
constructs for expressing concurrency. However, the join and split symbols in activity
diagrams only resolve this for simple cases.
5.3.3.1 Activity
An activity is the specification of a parameterized sequence of behavior. An activity is shown
as a round-cornered rectangle enclosing all the actions, control flows and other elements that
make up the activity. Example of an activity is shown in Figure 5.13
Verify order
Figure 5.13 Activity
Some activities run forever until an outside event interrupts them, but most activities
eventually complete their work and terminate by themselves. The completion of an activity is
a completion event and usually indicates that the next activity can be started. An unbalanced
arrow from one activity to another in an activity diagram indicates that the first activity must
be completed before the second activity can begin. An activity can be decomposed into finer
14
activities. Example, in Figure 5.20 activity “execute order” can be decomposed into several
activities as shown in Figure 5.14.
[market order]
[selling] [buying] [timeout]

[limit order] [order still active]
Find buyer at Find seller at [price not available]

market price market price
[price available]
[selling]
[buying]
Find buyer at limit Find seller at limit

price or better price or better
Figure 5.14 Activity diagram for execute order
Activities on diagram must be at same level of detail. As in Figure 5.20 activities “execute
order” and “settle trade” both are similar in detail. If any one of the activity is explained in
detail, then other must also be explained in detail. A balance must always be maintained
between the activities.
5.3.3.2 Branches
15
A branch appears, if a decision is to be made and depending on a condition several following
actions/activities are to be initiated. There is more than one successor to an activity; each
arrow may be labeled with a condition in square brackets as shown in Figure 5.15. All
subsequent activities are tested when an activity completes. Notation used for branch is a
diamond symbol. Figure 5.8 shows the example of branch, where material is checked, if
material is complete then house is build and if not complete then order is placed.
Check material
[incomplete]
Order material
[complete]
Build house
Figure 5.15 Example of Branch
Sometimes no condition is satisfied, and then the system will hang unless it is interrupted at
some higher level. To avoid this problem else condition is used; it is satisfied in case no other
condition is satisfied as shown in Figure 5.16.
16
Found drink
[found coke] [found limca] [else]
Take coke Take limca Take water
Figure 5.16 Example of Branch with else condition
If multiple conditions are satisfied, only one successor activity executes, but there is no
guarantee which one it will be. Often, it indicates an error, so the modeler should determine
whether any overlap of conditions can occur and whether it is correct.
5.3.3.3 Concurrent activities
Organizations and computer systems can perform more than one activity at a time. In activity
diagram activities can be executed concurrently and then synchronized again. The pace of
activity can also change over time. One activity can be split into multiple activities by fork
node and then executed concurrently and finally combined into a single activity with merge
node. A fork and merge is shown by a synchronization bar i.e. a heavy line with one or more
input arrows and one or more output arrows. On synchronization, control must be present on
all the incoming activities, and control passes to all the outgoing activities.
17
Figure 5.17 shows the example of concurrent activities. Activity Map house construction is
forked into find site, clear balance and assign architect, then they are merged into build
house.
Map house
construction
Find site Clear balance Assign architect
Build house
Figure 5.17 Concurrent activities
5.3.3.4 Swim Lanes
Swim lane is a visual element used in activity diagram to distinguish the activities among
organizations. In a business model, it is often useful to know which human organization is
responsible for which activity. Swim lanes clarify not only the steps but also who is
responsible for each one and how delays, mistakes or cheatings are most likely to occur
18
Here, partitioning within an activity diagram is done by dividing it into columns and lines.
Each column is called a swim lane by analogy to a swimming pool. Placing an activity within
a particular swim lane indicates that it is performed by a person or persons within the
organization. Lines across swim lane boundaries indicate interaction among different
organizations, which must usually be treated with more care than interactions within an
organization. The horizontal arrangement of swim lanes has no inherent meaning, although
there may be situations in which the order has meaning.
Example of an activity diagram having swim lanes is shown in Figure 5.18. Here, the
customer must request service, pay amount, and collect order, the sales person must take
order and deliver order and the stockroom must fill order.
Customer Sales Stockroom
Request service
Take order
Fill order
Pay
Deliver order
Collect order
Figure 5.18 Activity diagram with swim lanes
19
Another example is shown in Figure 5.19 having example of servicing an airplane. The flight
attendants must clean the trash, the ground crew must add fuel, and catering must load food
and drink before a plane is serviced and ready for its next flight.
Flight attendant Ground Crew Catering
Add fuel Load food

Clean trash
and drinks
Figure 5.19 Activity diagram with swim lanes
5.3.3.5 Activity Diagrams
An activity diagram is used to specify the sequence of activities that make up a complete
process such as algorithm or flowchart. They include activities, branches, concurrent
activities, swim lanes and finally activity diagrams. Activity diagrams are used to show the
workflow from a start point to the finish point detailing the many decision paths that exist in
20
the progression of events contained in the activity. They may be used to detail situations
where parallel processing may occur in the execution of some activities. They are useful for
business modeling where they are used for detailing the processes involved in business
activities.
Verify account
Execute account
[failure]
[success]
Send Debit Update Send

confirmation account online failure
portfolio notice
Settle trade
Close order
Figure 5.20 Activity Diagram
Activity diagram is like a traditional flowchart in that it shows the flow of control from step
to step. Unlike a traditional flowchart, an activity model can show both sequential and
concurrent flow of control. They are often used for modeling human organizations because
21
they involve many objects- persons and organization units- that perform operations
concurrently.
Example of an activity diagram is shown in Figure 5.20. It is an activity diagram for Stock
Trade Processing.
One more example of activity diagram is shown in Figure 5.21. It is an activity diagram of
Order Management System having four activities i.e. Send order by the customer, Receipt of
the order, Confirm order and Dispatch order.
Order request [check if order is normal order]

Customer sends system confirms
an order request the receipt of
the order
[check if order [No]

is special order] [yes]
[yes]
Confirm the
order
[No]
Dispatch the
order
Figure 5.21 Example of Activity Diagram
5.4 Summary
22
• The interaction model shows how objects interact and how messages exchange in the
system.
• An actor is an object or set of objects that communicates directly with the system.
Actor is an external user of system and not the part of system.
• At higher level, use cases partition the functionality of a system into discrete pieces
meaningful to external actors.
• The include relationship incorporates one use case within the behavior sequence of
another use case, like a subroutine call. The extent relationship adds incremental
behavior to a base use case.
• Sequence diagram shows not only the objects in an interaction and the messages
among them but also helpful for showing detail of implementation.
• Activity diagram shows the detail of computation.
• An activity is the specification of a parameterized sequence of behavior.
• A branch appears, if a decision is to be made and depending on a condition several
following actions/activities are to be initiated.
• Concurrent activities are activities which are executed at the same time.
• Swim lanes are used to show the organizations that are responsible for different
activities.
• Use case model, Sequence model and Activity model are necessary for full
understanding for a problem. The three models come together in the implementation
of methods, which involves data, control and interactions.
23
Education-2007
Burd, Thomson-2007
TMH, 2004
1. What is use case model? Why they are needed?
2. Define actor with example.
3. Define extend and include relationship. What is the difference between them?
4. Draw the use case diagram for College system.
5. What is scenario? Write the scenario for following activities
(a) Getting ready to take a trip in your car. Assume an automatic transmission.
Don’t forget your seat belt and emergency brake
(b) An elevator ride to the top floor.
(c) Operation of a car cruise control. Include an encounter with slow moving traffic
that requires you to disengage and then resume control.
(d) Moving a bag of corn, a goose and a fox across a river in a boat. Only one thing
may be carried in a boat at a time. If the goose is left alone with the corn, the
corn will be eaten. If the goose is left alone with the fox, the goose will be eaten.
24
Prepare two scenarios, one in which something gets eaten and one in which
everything is safely transported across the river.
6. Draw the sequence diagram for library system.
7. Define activity and branch for activity diagram.
8. What is swim lanes? Why are they needed?
25
Lesson 6
System Design
Structure
6.1 Introduction
6.2 Objectives
6.3.1 System Design
6.3.1.1 Estimating System Performance
6.3.1.2 Making a Reuse Plan
6.3.1.3 Breaking a system into Subsystems
6.3.1.4 Identifying Concurrency
6.3.1.5 Allocate Subsystems to Hardware
6.3.1.6 Management of Data Storage
6.3.1.7 Handling Global Resources
6.3.1.8 Choosing a Software Control Strategy
6.3.1.9 Handling boundary Conditions
6.3.1.10 Setting trade-off Priorities
6.3.2 Selecting an Architectural Styles
1
6.3.2.1 Batch Transformation
6.3.2.2 Continuous Transformation
6.3.2.3 Interactive Interface
6.3.2.4 Dynamic Simulation
6.3.2.5 Real Time System
6.3.2.6 Transaction Manager
6.4 Summary
2
6.1 Introduction
After analyzing the problem, one must decide how to approach the system design. During
system design developers devise the high-level strategy (system architecture) for solving the
problem and building a solution and make decisions about the organization of the system into
subsystems, the allocation of subsystems to hardware and software and major policy
decisions that form the basis for class design.
6.2 Objectives
In this chapter we will learn what is system design? What is physical and logical design?
What are different types of design decisions made by the designer? What is software
architecture? What are different types of architectural styles?
6.3.1 System Design
Systems design is the process or art of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. It is a process where
developers decide the overall structure and style of the system. System design is the first
stage for solving any problem. The emphasis is given on how the problem is to be solved.
The system design process is generally divided into two sub-phases – logical design and
physical design.
3
The logical design of a system pertains to an abstract representation of the data flows, inputs
and outputs of the system. This is often conducted via modeling, which involves a simplistic
(and sometimes graphical) representation of an actual system. In the context of systems
design, modeling can undertake the following forms, including: Data flow diagram, Entity
Life Histories and Entity-relationship diagrams etc.
The physical design relates to the actual input and output processes of the system. This is laid
down in terms of how data is input into a system, how it is verified/authenticated, how it is
processed, and how it is displayed as output.
Physical design, in this context, does not refer to the tangible physical design of an
information system. To use an analogy, a personal computer's physical design involves input
via a keyboard, processing within the CPU, and output via a monitor, printer, etc. It would
not concern the actual layout of the tangible hardware, which for a PC would be a monitor,
CPU, motherboard, hard drive, modems, video/graphics cards, USB slots, etc.
In the OMT methodology, system design is one of the phases of the software development
life cycle. During this phase, developers decide the overall structure and style of the system.
The system architecture determines the organization of the system into subsystems. During
system design, the following design decisions are to be made.
i. Estimation of system performance
ii. Make a reuse plan.
iii. Breaking a system into subsystems
iv. Identify concurrency
4
v. Allocate subsystems to hardware.
vi. Manage data stores.
vii. Handle global resources.
viii. Choose a global control strategy
ix. Handle boundary conditions
x. Set trade off priorities
xi. Select an architectural style.
Now, each of these design decision will be discussed in detail.
5
6.3.1.1 Estimating System Performance
A rough performance estimate (generally referred as “Back of the envelop”) should be
calculated for a new system. The purpose is not to achieve high accuracy, but merely to
determine if the system is feasible. The calculation should be fast and should also involve
common sense. We can estimate, number of transactions to be processed by the system,
response time needed, storage requirements etc.
6.3.1.2 Making a Reuse Plan
Reuse is often cited as an advantage of OO technology. But reuse does not happen
automatically. There are two different aspects – using existing things and creating reusable
new things. It is much easier to use existing things than to design new things for uncertain use
to come. Reusable things include models, libraries, frameworks and patterns. Reuse of
models is often the post practical form of reuse. The logic in a model can apply to multiple
problems. Now, we discuss library, framework and pattern based reuse.
a) Library based Reuse
It is a collection of prewritten, ready-made software routines that act as templates for
programmers to use in writing object-oriented application programs. Class libraries are
typically used to provide GUI functions like buttons, scroll bars, icons and windows. Class
libraries greatly simplify the work of the programmer who can use the pre-tested code instead
6
of having to write new code. The classes in the library are useful in many contexts. The
collection of classes must be carefully organized, so that users can find them.
For example, the .NET Framework class library is a library of classes, interfaces, and value
types that are included in the Microsoft .NET Framework SDK. This library provides access
to system functionality and is designed to be the foundation on which .NET Framework
applications, components, and controls are built.
A good library satisfies the following qualities:
• Coherence
• Completeness
• Consistency
• Efficiency
• Extensibility
• Genericity
Many problems may arise when classes are reused from many sources. Such problems are
sometime very difficult to solve by specializing a class and adding codes. These problems
effectively limit the reuse of classes from the class libraries. The following types of problems
may be encountered in reusing class libraries.
Argument validation: Arguments can be validated in two ways – collectively or
individually. In collective validation, first user enters all the arguments and then they are
7
checked collectively. The collective validation is appropriate for command interfaces. In
individual validation, the argument is checked as and when it is entered. Combination of the
two approaches should be avoided.
Error handling: Different class libraries may use different error-handling techniques. For
example, a method in one class may return the error code to the calling routine while a
method in another class in another library may deal with the error directly.
Control paradigms: Different class libraries may us different control paradigms. For
example, one library uses procedure-driven control and another uses event-driven control.
Combining these two types of control into one application is difficult and awkward.
Group operations: If we want to delete objects in groups then that library must have group-
delete function. If that function is not available then we can not reuse the classes of that
library. Group operations are often inefficient and incomplete.
Garbage collection: Different libraries may use different techniques to allocate memory and
to collect garbage. In Java, there is automatic garbage collection and while in C++, it is the
responsibility of the application.
Name collisions: classes from different libraries may have same name for public identifiers
causing names collisions. To resolve this problem, most of the class libraries add a
distinguishing prefix to names to reduce the chance of names collision.
8
b) Frameworks based Reuse
In general, a framework is a real or conceptual structure intended to serve as a support or
guide for the building of something that expands the structure into something useful. In
computer science, a framework is skeletal structure of a program that must be elaborated to
build a complete application. It is an abstraction in which common code providing generic
functionality can be selectively overridden or specialized by user code, thus providing
specific functionality. A framework is generally more comprehensive than a protocol and
more prescriptive than a structure.
Frameworks are a special case of software libraries in that they are reusable abstractions of
code wrapped in a well-defined Application Programming Interface (API), yet they contain
some key distinguishing features that separate them from normal libraries. Software
frameworks typically contain considerable housekeeping and utility code in order to facilitate
user applications, but generally focus on specific problem domains.
Following are some of the problem domains where frameworks have been used:
• Artistic drawing, music composition, and mechanical
• Compilers for different programming languages and target machines
• Financial modeling applications
• Earth system modeling applications
• Decision support systems
• Media playback and authoring
9
• Web applications
• Middleware
Examples of frameworks that are currently used or offered by standards bodies or companies
include:
• Resource Description Framework – it is a set of rules from the World Wide Web
Consortium for how to describe any Internet resource such as a Web site and its
content.
• Internet Business Framework – it is a group of programs that form the technological
basis for the mySAP product from SAP, the German company that markets an
enterprise resource management line of products.
• Sender Policy Framework: it is a defined approach and programming for making e-
mail more secure.
• Zachman framework – it is a logical structure intended to provide a comprehensive
representation of an information technology enterprise that is independent of the tools
and methods used in any particular IT business
In an object-oriented environment, a framework consists of abstract and concrete classes.
Instantiation of such a framework consists of composing and subclassing the existing classes.
When developing software based on framework reuse, the new system is built by
customizing and/or extending the generic architecture defined by the framework.
For example, The Microsoft .NET Framework is a software framework for Microsoft
Windows operating systems. It includes a large library, and it supports several programming
10
languages which allows language interoperability (each language can utilize code written in
other languages.) The .NET library is available to all the programming languages that .NET
supports.
Software frameworks have these distinguishing features that separate them from libraries or
normal user applications:
• Inversion of control: In a framework, unlike in libraries the overall program's flow
of control is not dictated by the caller, but by the framework.
• Default behavior - A framework has a default behavior. This default behavior must
actually be some useful behavior and not a series of no-operations.
• Extensibility - A framework can be extended by the user usually by selective
overriding or specialized by user code providing specific functionality.
• Non-modifiable framework code - The framework code, in general, is not allowed
to be modified. Users can extend the framework, but not modify its code.
• There are different types of software frameworks: conceptual, application, domain,
platform, component, service, development, etc.
c) Pattern based Reuse
A pattern is a proven solution to general problem. Various patterns target different phases of
the software development life cycle. There are patterns for analysis, architecture, design and
implementation.
11
Design patterns are general solutions to problems in object-oriented programming. They will
not solve a specific problem, but they provide a sort of architectural outline that may be
reused in order to speed up the development process of a program. Design patterns have
provided the stepping stone for computer science to truly enter the engineering field.
There are many types of design patterns: structural design patterns, computational patterns,
algorithm strategy patterns, implementation strategy patterns and execution patterns.
Structural patterns address concerns related to the high level structure of an application being
developed. Computational patterns address concerns related to the identification of key
computations. Algorithm strategy patterns address concerns related to high-level strategies
that describe how to exploit application characteristic on a computation platform.
Implementation strategy patterns related to the realization of the source code to support (i)
how the program itself is organized and (ii) the common data structures specific to parallel
programming. Execution patterns address concerns related to the support of the execution of
an application, including the strategies
Examples of structural patterns are: Adapter Pattern – it converts the interface of a class into
another interface clients expect. Adapter lets classes work together that couldn't otherwise
because of incompatible interfaces. Bridge Pattern – it decouples an abstraction from its
implementation allowing the two to vary independently.
Examples of creational patterns are: Abstract Factory – it provides an interface for creating
families of related or dependent objects without specifying their concrete classes. Builder
12
Pattern – it separates the construction of a complex object from its representation allowing
the same construction process to create various representations.
A pattern is different from a framework. A pattern is typically a small number of classes and
relationships where as a framework is much broader in scope and covers an entire subsystem
or application.
6.3.1.3 Breaking a system into Subsystems
A subsystem may be defined as a group of classes, associations, operations, events and
constraints that are interrelated and have a well-defined interface. For example file system is
a subsystem of an operating system. The interface of a subsystem defines the form of all
interactions and how the information will flow across subsystem boundaries. A system may
be divided into smaller subsystems and each subsystem may further be divided into smaller
subsystems of its own.
Relationships between subsystems are:
There are two types of relationships between subsystems:
a) Client-Server and b) Peer-to-peer
a) Client–Server relationship: In client-server relationship client calls on the server for
performing certain task and server replies back with the result. The client–server
characteristic describes the relationship of cooperating programs in an application. The server
13
component provides a function or service to one or many clients, which initiate requests for
such services.
For instance, when someone checks their bank account from a computer, the computer acts as
the client and forwards the request to an on-line bank (server). The bank’s program (server)
then serves a response to the user in which the requested information is displayed. The
client/server model has become a predominate function in network computing. Many
applications intended for both personal and business use were designed with this concept in
mind. In most cases, both the client and server are part of a larger program or system. As it
relates to the Internet, a web browser acts as a client that requests specific services to a web
server, a process known as HTTP (Hypertext Transfer Protocol). In similar fashion, a
computer that relies on TCP/IP for a connection enables a user to make client requests to FTP
servers found in other computers connected to the Internet.
b) Peer-to-peer relationship: In peer-to-peer relationship, each subsystem may call on
the others. The communication in this case can be much complex because individual
subsystems may not be aware about each other. Designing such type of systems may lead to
subtle design errors.
Layers and Partitions: The decomposition of systems into subsystems may be organized as
a sequence of horizontal layers or vertical partitions.
14
Layers: A layered system is an ordered set of virtual worlds, each built in terms of the ones
below it and providing the implementation basis for the ones above it. Layered architecture
comes in closed or open.
In a closed architecture, each layer is built only in terms of the immediate lower layer. This
reduces dependencies between layers and allows changes to be made most easily. In an open
architecture, a layer can use the features of any lower layer to any depth. This reduces the
need to redefine operations at each level.
In a layered architecture model, classes within each subsystem layer provide services to the
layer above it. Ideally, this knowledge is one-way: each layer knows about the layer below it,
but the converse is not true. An example of layered system architecture is the ISO Reference
Model for Open Systems Interconnection (OSI) as shown in Figure 6.1.
Application
Presentation
Session
Transport
Network
Data Link
Physical
15
Figure 6.1 Example of Subsystem Layers
(ISO Reference Model for OSI)
Partitions: Partitions vertically divide a system into several independent or weakly
subsystems, each providing one kind of service. One difference between layers and partitions
is that layers vary in their level of abstraction, but partitions merely divide a system into
pieces, all of which have a similar level of abstraction. We can decompose a system into
subsystems by combining layers and partitions. Layers can be partitioned and partitions can
be layered. Most large systems require a mixture of layers and partitions.
In a partitioned architecture model, subsystems collaborate with peer subsystems at the same
level of abstraction. Like layers, each subsystem partition represents a group of classes that
share similar functionality at the same level of abstraction. Classes within each subsystem
partition can communicate with other classes in that partition. Selected subsystem classes
(assuming weak coupling) can communicate with designated classes from subsystem
partitions that are at the same level as the subject subsystem.
Partitioning effects a vertical structuring of peer subsystems. For example, many operating
system (OS) architectures partition OS services into subsystems for file management, process
control, and memory management as shown in Figure 6.2. Since the OS subsystems are at the
same level of abstraction, they can interact with each other in a peer-to-peer manner. For
example, when an executable file is loaded into memory for execution, the file system, the
memory management system, and the process control system all interoperate.
16
System Call Interface
Process Management Memory Management File Management
Hardware Control
Figure 6.2 Example of Subsystem Partitions
(OS Kernel Service)
Identifying subsystems: The following steps can be used to identify subsystems:
• Look at the analysis model as the staring point
• Look for separation of design concerns
• Look for functionally related classes and interfaces
• Look for classes interfaces and subsystems with many dependencies
• Look for large-grained components
• Look for reusable components
17
• Look for interfaces
• Look for software products that need to be wrapped up as a subsystem
• Look for legacy systems which need to be wrapped up as a subsystem
• Look for service subsystems
• Look for software products that need to be wrapped up as a subsystem.
6.3.1.4 Identifying Concurrency
Concurrency (or distribution) is an important issue during design process as it may affect the
design of classes and their interfaces. Concurrency can be very important for improving the
efficiency of a system. In the analysis model, as the real world and in hardware, all objects
are concurrent. In an implementation, not all software objects are concurrent, because one
processor may support many objects. One important goal of the system design is to identify
the objects that must be active concurrently and the objects that have mutually exclusive
activity
For concurrent applications, such as distributed and real-time applications, the following
activities are performed:
• Identify inherent concurrency: - Two objects are inherently concurrent if they can
receive events at the same time without interacting. Inherently concurrent subsystems
need not be implemented as separate hardware units.
18
• Define concurrent Tasks: Many objects in a system are dependent on each other. By
examining the state diagrams of individual objects and exchange of events among
them, many objects can be folded in to a single thread of model. A thread of control is
a path through a set of state diagrams on which only a single object at a time is active.
• Make decisions about subsystem structure and interfaces. Develop the overall
software architecture. Structure the application into subsystems.
• Make decisions about how to structure the distributed application into distributed
subsystems, in which subsystems are designed as configurable components. Design
the distributed software architecture by decomposing the system into distributed
subsystems and defining the message communication interfaces between the
subsystems.
• Make decisions about the characteristics of objects, in particular, whether they are
active or passive. For each subsystem, structure the system into concurrent tasks
(active objects). During task structuring, tasks are structured using the task structuring
criteria, and task interfaces are defined. Make decisions about the characteristics of
messages, in particular, whether they are asynchronous or synchronous (with or
without reply).
• Make decisions about class interfaces. For each subsystem, design the information
hiding classes (passive classes). Design the operations of each class and the
parameters of each operation. Use inheritance to develop class hierarchies. Develop
19
the detailed software design, addressing detailed issues concerning task
synchronization and communication, and the internal design of concurrent tasks.
• For real-time applications, analyze the performance of the design. Apply real-time
scheduling to determine if the concurrent real-time design will meet performance
goals. If not, investigate alternative software architectures.
6.3.1.5 Allocation of Subsystems to Hardware
We must allocate each concurrent subsystem to a hardware unit, either a general-purpose
processor or specialized functional unit. The system designer must do the following:
• Estimate performance needs and the resources needed to satisfy them.
• Choose hardware or software implementation for subsystems
• Allocate software subsystems to processors to satisfy performance needs and
minimize inter processor communication
• Determine the connectivity of the physical units that implement the subsystems.
• Consider the connection between nodes and communication protocols to be used.
• Consider the need for redundant processing.
• Identify any interface implied by deployment.
UML deployment diagram can be used to present the above-mentioned steps. A deployment
diagram shows how the systems will be physically distributed on the hardware.
20
6.3.1.6 Management of Data Storage
System designer must decide from among several alternatives for data storage that can be
used separately or in combination of data structures, files and databases. This involves
identifying the complexity of the data, the size of the data, the type of access to data (single
user or multiple user), access times and portability. Having considered these issues, the
designer must make the decision about whether he data can be held in flat files or in
relational or object databases.
The following points must be considered when selecting an appropriate approach to data
storage:
• Data persistence: Does data need to be persistent? If so then files, serialization or
databases must be considered.
• Purchase cost: If our system requires a database system then it is likely that this will
increase the cost of the system. It may also involve licensing agreements.
• Life cycle cost: This reflects costs such as purchase, development, deployment, operating
and maintenance costs.
• Amount of data: The more data the designer has the more carefully he needs to think
about how it should be stored and accessed.
• Performance: In main memory, the storage provides the faster data access while files are
likely to provide the poorest performance.
21
• Extensibility: How easy it will be to extend our application in the future for a given the
method of data storage.
• Concurrent access: Whether the designer needs concurrent access or not.
• Crash recovery: How will we recover our data if the system crashes.
• Distribution: Will the data need to be distributed among a number of sites? If yes, then
make the decision accordingly.
Different kinds of data stores provide trade-offs among cost, access time, capacity and
reliability.
Files provide cheap, simple and permanent storage and are easy to work with. However, file
on one system may not be useful when transported to another system because of varying file
implementations over different hardware types. Files may be used in random access mode or
sequential access mode. Sequential file format is mostly a standard format and is easy to
handle. Whereas, the commands and storage formats for random access files and index files
vary in their formats.
The kind of data that belongs to files can be characterized as follows:
• Data with high volumes and low information density (such as archival files or
historical data)
• Modest quantities of data with simple structure.
• Data that are accessed sequentially.
22
• Data that can be fully read into the memory.
Another alternative to store data is to use database management systems (DBMSs). There are
various kinds of DBMSs like relational, object oriented, network and hierarchical etc.
Databases make applications easier to port to different hardware and operating system
platforms. One disadvantage of DBMSs is their complex interface. The kind of data that
belongs to a database can be characterized as follows:
• Data to be stored exists in large quantity.
• Data that is to be kept in store for a very longer period of time.
• Data that must be secured against unauthorized and malicious access.
• Data that must be accessed by multiple application programs.
• Data that require updates at fine levels of detail by multiple users
6.3.1.7 Handling Global Resources
The system designer must identify global resources and determine mechanisms for
controlling access to them. There are several kinds of global resources:
• Physical system: Example includes processors, tape drives and communication
channels.
• Space: Example includes keyboard, buttons on a mouse, display screen
• Logical names: Example includes object IDs, filenames, and class names.
23
• Access to shared data: Example includes Databases
Physical resource such as processors, tape drives etc. can control their own access by
establishing a protocol for obtaining access. For a logical resource like Object ID or a
database, there arises a need to provide access in a shared environment without any conflicts.
One strategy to avoid conflict may be to employ a guardian object which controls access to
all other resources. Any request to access a resource has to pass through a guardian object
only. Another strategy may be to partition a resource logically and assign subsets to different
guardian objects for independent control. In a critical real time application passing the entire
access requests or resources through a guardian object may be not be desirable and it may
become necessary to provide direct access to resources. In this case, to avoid conflicts, a lock
can be placed on the subsets of resources. A lock is a logical object associated with a shared
resource which gives the right of accessing the resource to the lock holder. Guardian object
can still exist to allocate the lock. However, direct access to resources must not be
implemented unless it is absolutely desirable.
6.3.1.8 Choosing a Software Control Strategy
It is best to choose a single control style for the whole system. There are two kinds of control
flows in a software system: External control and internal control. External control concerns
the flow of externally visible events among the objects in the system. There are three kinds of
external events: procedural-driven sequential, event-driven sequential and concurrent.
24
Procedural-driven Control: In a procedure-driven system, the control lies within the
program code. Procedures request external input and then wait for it, when input arrives,
control resumes within the procedure that made the call.
The major advantage of procedure-driven control is that it is easy to implement with
conventional languages, the disadvantage is that it requires the concurrency inherent in
objects to be mapped into a sequential flow of control.
Event-driven Control: In the sequential model, the control resides within a dispatcher or
monitor that the language, subsystem or operating system provides. In event-driven, the
developers attach application procedures to events and the dispatcher calls the procedures
when the corresponding events occur. Usually event driven systems are used for external
control in preference to procedure driven systems, because the mapping from events to
program constructs is simpler and more powerful. Event driven systems are more modular
and can handle error conditions better than procedure-driven systems.
For example, the GUI consists of many built in objects (like text boxes, tool icons menus
etc). The user interacts with these GUI objects either through mouse clicks or through
pressing keys on keyboard. These user interactions with GUI objects are called events and
these event notifications are given to the program (whom the user is interacting with) by
Windows operating system. Now the programmer's task is to write the code that executes on
the occurrence of these events automatically, and this type of control is called event-driven
control.
25
Concurrent system Control: Here control resides concurrently in several independent
objects, each as a separate task. A task can wait for input, but other tasks continue execution.
The operating system keeps track of the raised events while a task is being performed so that
events are not lost. Scheduling conflicts among tasks are also resolved by the operating
system.
Internal control refers to the flow of control within a process. It exists only in the
implementation and therefore is neither inherently concurrent nor sequential.
6.3.1.9 Handling boundary Conditions
Although most of the system design concerns steady-state behavior system designer must
consider boundary conditions as well and address issues like initialization, termination and
failure (the unplanned termination of the system).
• Initialization: It refers to initialization of constant data, parameters, global variables,
tasks, guardian objects, and classes as per their hierarchy. Initialization of a system
containing concurrent tasks must be done in a manner so that tasks can be started without
prolonged delays. There is quite possibility that one object has been initialized at an early
stage and the other object on which it is dependent is not initialized even after
considerable time. This may lead to halting of system tasks.
26
• Termination: Termination requires that objects must release the reserved resources.
In case of concurrent system, a task must intimate other tasks about its termination.
• Failure: Failure is the unplanned termination of the system, which can occur due to
system fault or due to user errors or due to exhaustion of system resources, or from
external breakdown or bugs from external system. The good design must not affect
remaining environment in case of any failure and must provide mechanism for recording
details of system activities and error logs.
6.3.1.10 Setting trade-off Priorities
The system designer must set priorities that will be used to guide trade-offs for the rest of the
design. For example system can be made faster using extra memory. Design trade-offs
involve not only the software itself but also the process of developing it. System designer
must determine the relative importance of the various criteria as a guide to making design
trade-offs. Design trade-offs affect entire character of the system. Setting trade-offs priorities
is at best vague. Priorities are generally specified as a statement of design philosophy.
6.3.2 Selecting an Architectural Style
27
Software architecture, according to ANSI/IEEE Standard 1471-2000, is defined as the
“fundamental organization of a system, embodied in its components, their relationships to
each other and the environment, and the principles governing its design and evolution.”
The architecture of a system describes its gross structure. This structure illuminates the top-
level design decisions, including things such as how the system is composed of interacting
parts, what are the main pathways of interaction, and what are the key properties of the parts.
Additionally, an architectural description includes sufficient information to allow high-level
analysis and critical appraisal.
Several prototypical architectural styles are common in existing systems. Each of these is
well suited to a certain kind of system. Some of the styles are discussed below in brief.
6.3.2.1 Batch Transformation
A data transformation executed once on an entire input set. It performs sequential
computations. The application receives the inputs and the goal is to compute an answer; there
is no ongoing interaction with the outside world. The steps involved in batch transformation
are as follows.
• Break the overall transformation into stages, with each stage performing one part of the
transformation.
28
• Prepare class models for the input, output and between each pair of successive stages.
Each state knows only about the models on either side of it.
• Expand each stage in turn until the operations are straightforward to implement.
• Restructure the final pipeline for optimization.
Compilers are examples of batch transformation systems. A simplified view of the
architecture of the compiler is depicted in Figure below.
There are six phases in a typical compiler:
• Lexical Analysis
• Syntax Analysis
• Error Recovery
• Scope Analysis
• Type Analysis
• Code Generation
The process of lexical analysis is called lexical analyzer, scanner, or tokenizer. Its purpose is
to break a sequence of characters into subsequences called tokens. The syntax analysis phase,
called parser, reads tokens and validates them in accordance with a grammar. Vocabulary,
i.e., a set of predefined tokens, is composed of word symbols (reserved words), names
(identifiers), numerals (constants), and special symbols (operators). During compilation, a
compiler will find errors such as lexical, syntax, semantic, and logical errors.
29
In this system input is to the first phase and output is from the last phase. Input will be the
source program and output will be the object program.
6.3.2.2 Continuous Transformation
A data transformation performed continuously as inputs change. It is a system in which the
outputs actively depend on changing inputs. It updates outputs frequently. One way to
implement continuous transformation is with a pipeline of functions. Through the pipeline
any change in input is propagated. Examples of continuous transformation applications are
windowing systems, signal processing, process monitoring systems, incremental compilers
etc.
The steps in designing a pipeline for a continuous transformation are as follows:
• Break the overall transformation into stages performing one part of the transformation.
• Define input, output and intermediate models between each pair of successive stages, as
for the batch transformation.
• Differentiate each operation to obtain incremental changes to each stage. That is,
propagate the incremental effects of each change to an input through the pipeline as a
series of incremental updates.
• Add additional intermediate objects for optimization.
30
The main difference between batch transformation and continuous transformation is that in
former computation is done once while in later continuous transformation updates outputs
frequently.
For example, in a graphics application, first it maps geometric figures in user-defined
coordinates to window coordinates. Then it clips the figures to fit the window bounds. Lastly,
it offsets each figure by its window position to yield its screen position.
6.3.2.3 Interactive Interface
It is a system dominated by interactions between the system and external agents called actors.
An actor can be a person, a device or another system/subsystem. The actors are not the part of
the system rather they are supposed to lie on the boundary of the system. The main concerns
of interactive interface are the communication protocols between the system and the actors,
the flop of control within the system, performance, error handling etc.
The steps in designing an interactive interface are as follows.
• Isolate interface classes from the application classes.
• Use predefined classes to interact with the actors, if possible.
• Use the state model as the structure of the program.
• Isolate physical events from logical events. Often a logical event corresponds to multiple
physical events.
31
• Fully specify the application functions that are invoked by the interface.
6.3.2.4 Dynamic Simulation
Dynamic simulation is the use of a computer program to model the time varying behavior of
a system. It models real-world objects. In this objects and operations directly come from the
application and hence it is easy to implement. Controls can be implemented in two ways in
dynamic simulation systems – external control and internal control. In former, objects
simulate a state machine and in later objects can exchange messages among themselves.
Examples of dynamic simulation are video games, spacecraft trajectory computation system,
molecular motion mode etc.
The steps in designing a dynamic simulation are as follows:
• Identify active real word objects from the class model. These objects have attributes that
are periodically updated.
• Identify a discrete event, which corresponds to discrete interactions with the object.
• Identify continuous dependencies. Real world attributes may be dependent on other real-
world attribute.
• Generally a simulation driven by a timing loop at a fine time scale. Discrete events
between objects can often be exchanged as part of the timing loop.
6.3.2.5 Real time system
32
A system dominated by strict timing constrains. It is an interactive system with tight time
constraints on actions. Real-Time systems span several domains of computer science. They
are defense and space systems, networked multimedia systems, embedded automative
electronics etc. In a real-time system, the correctness of the system behavior depends not only
the logical results of the computations, but also on the physical instant at which these results
are produced. A real-time system changes its state as a function of physical time, e.g., a
chemical reaction continues to change its state even after its controlling computer system has
stopped.
Based on this a real-time system can be decomposed into a set of subsystems i.e., the
controlled object, the real-time computer system and the human operator. A real-time
computer system must react to stimuli from the controlled object (or the operator) within time
intervals dictated by its environment. The instant at which a result is produced is called a
deadline. If the result has utility even after the deadline has passed, the deadline is classified
as soft, otherwise it is firm. If a catastrophe could result if a firm deadline is missed, the
deadline is hard. Commands and Control systems, Air traffic control systems are examples
for hard real-time systems. On-line transaction systems, airline reservation systems are soft
real-time systems.
6.3.2.6 Transaction Manager
It is a system concerned with storing and retrieving data, often including concurrent accesses
from different physical locations. Most of the transaction managers deal with multiple users
who read and write data at the same time. So they need to secure the data against the
33
unauthorized access and accidental loss. They are generally built on the top of DBMS.
Examples of such systems are inventory control, sales and purchase order processing, airline
reservation systems etc.
The steps involved in the design of such systems are:
• Map the class model to database structures.
• Determine the units of concurrency that is the resources that inherently or by specification
cannot be shared.
• Determine the unit of transaction that is the set of resources that must be accessed
together during a transaction.
• Design concurrency control for transactions. This feature is provided by most database
systems.
6.4 Summary
• Systems design is the process or art of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. The system design
process is generally divided into two sub-phases – logical design and physical design.
• The logical design of a system pertains to an abstract representation of the data flows,
inputs and outputs of the system.
34
• The physical design relates to the actual input and output processes of the system. This is
laid down in terms of how data is input into a system, how it is verified /authenticated,
how it is processed, and how it is displayed as output.
• It is much easier to use existing things than to design new things for uncertain use to
come. Reusable things include models, libraries, frameworks and patterns.
• A subsystem may be defined as a group of classes, associations, operations, events and
constraints that are interrelated and have a well-defined interface.
• In a layered architecture model, classes within each subsystem layer provide services to
the layer above it. Ideally, this knowledge is one-way: each layer knows about the layer
below it, but the converse is not true
• Partitions vertically divide a system into several independent or weakly subsystems, each
providing one kind of service.
• To increase the performance of system, multiple processors or hardware functional units
may be used. The number of processors required depends on the volume of computations
and the speed of the machine
• The system designer must allocate the tasks for various subsystems to processors. Each
concurrent subsystem should be allocated to an independent process or processor.
• System designer must decide from among several alternatives for data storage that can be
used separately or in combination of data structures, files and databases.
• The system designer must identify global resources and determine mechanisms for
controlling access to them
• There are two kinds of control flows in a software system: External control and internal
control. External control concerns the flow of externally visible events among the objects
35
in the system. There are three kinds of external events: procedural-driven sequential,
event-driven sequential and concurrent.
• Although most of the system design concerns steady-state behavior system designer must
consider boundary conditions as well and address issues like initialization, termination
and failure.
• The architecture of a system describes its gross structure. This structure illuminates the
top-level design decisions, including things such as how the system is composed of
interacting parts, what are the main pathways of interaction, and what are the key
properties of the parts.
Education-2007
Burd, Thomson-2007
TMH, 2004
1. What is system design? What are two types of system design? Explain.
36
2. What are different types of design decisions taken by a system designer? Explain in
detail.
3. What is reuse plan? Discuss three models for reusability.
4. What is library-based reuse? Discuss problems faced in library-based reuse.
5. What is framework based reuse? How is it different from pattern?
6. What is pattern based reuse? Explain.
7. What is subsystem? What are different types of relationships between subsystems?
Explain.
8. What are partitions and layers in a system?
9. How can you identify subsystems?
10. How do you identify concurrency?
11. How do you decide allocation of subsystems to processors?
12. Write a short note on data storage management.
13. Discuss the suitability of different types of data storages.
14. What are global resources in a system? How can you handle them?
15. How do you choose a software control strategy? Explain.
16. Distinguish between procedure driven and event driven control.
17. Distinguish between external and internal control.
18. What are boundary conditions? How do you handle them?
19. How do you set trade-off priorities?
20. What is software architecture? Discuss some commonly used architectural styles.
21. What is batch transformation architectural style? Enumerate the steps to be followed for
this style.
37
22. What is continuous transformation architectural style? Enumerate the steps to be followed
for this style.
23. What is interactive interface architectural style? Enumerate the steps to be followed for
this style.
24. What is dynamic simulation architectural style? Enumerate the steps to be followed for
this style.
25. What is transaction manager architectural style? Enumerate the steps to be followed for
this style.
26. What is real time system?
38

Uml Notes Rajender Nath Sir PDF

Uploaded by

Copyright:

Available Formats

You might also like

Uml Notes Rajender Nath Sir PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml Notes Rajender Nath Sir PDF

Uploaded by

Copyright:

Available Formats

Writer: Ms.

Vetter: Prof. Rajender Nath

1.3 History of UML

1.4 Principles of Modeling

1.5 Overview of UML Views

1.6 Building blocks of UML

1.7 Things of UML

1.7.1 Structural Things

1.7.1.4 Use Cases

1.7.1.5 Active Class

1.7.2 Behavioral Things

1.7.2.2 State Machine

1.7.3 Grouping Things

1.7.4 Annotational Things

1.8 Relationships in UML

1.9 Extensibility features

1.9.3 Tagged Values

1.11 Suggested Readings/Reference Materials

1.12 Self-Assessment Questions

complete and meaningful model.

behavior of artifacts of software systems. It is applied to diverse application domains (e.g.,

1.3 History of UML

concepts of Booch Methods, Object Modeling Techniques & Object-Oriented Software

revised to cover the latest revision of UML.

• UML 1.0 - 1996

• UML 1.1 - 1997

• UML 1.2 - 1999

• UML 1.3 - 2000

• UML 1.5 - 2003

• UML 2.0 - 2005

• UML 2.1.1 - 2007

• UML 2.1.2 - 2007

• UML 2.2 - 2009

• UML 2.3 - 2010

• UML 2.4.1 – 2011

• UML 2.5 - 2012

1.4 Principles of Modeling

A model is a simplification of reality. Models facilitate communication between the users,

system. So a model is an abstraction that hides the non-essential characteristics of a system

describes a model as a simplified representation of reality. A model provides a means for

conceptualization and communication of ideas in a precise and unambiguous form. The

A model may provide

We need models because a model helps us

• to visualize a system as it is or we want it to be.

• to specify the structure or behavior of the system.

• in providing a technique that guides us in constructing a system.

• in providing documenting the decisions we have made.

Modeling: Modeling consists of the gradual construction of a cognitively useful – though

of information more clearly than descriptive text.

Basic principles of modeling are:

attacked and how a solution is shaped.

• Every model may be expressed at different levels of precision.

• The best models are connected to reality.

through a small set of nearly independent models.

1.5 Overview of UML Views

contains 4+1 views:

include Class diagram, Communication diagram, and Sequence diagram.