502 Object Oriented Analysis and Design.pdf

Unit Contents Page No.
1 Object-Oriented Concepts, Modeling and UML 1-11
CONTENTS
2 Iterative Development and UML 12-41
3 Basic and Advanced Structural Modeling 42-67
4 Interaction Modelling 68-77
5 Architectural Modelling 78-88
6 Object Oriented Programming Styles 89-108

NOTES
Object Oriented Analysis
and Design
1
UNIT NO - I
OBJECT-ORIENTED CONCEPTS,
MODELING AND UML
Objectives of the Chapter
• To revisit the concepts of Object Oriented Paradigm with reference to
Analysis and Design
• To understand the concept of Modeling
• To Understand the general steps in Object Oriented Analysis and Design
Introduction
Object Oriented Analysis and Design (OOAD) subject deals with analysis
and design of the system which is to be developed using any object oriented
platform. If, a software as a system is analyzed and designed using a scientific
approach, then the end product i.e. the software is always a quality product which
can get through the acceptance test as well as satisfies the user. System Analysis
and Design (SAD) and Software Engineering like subjects helps to develop this
approach while developing any software. But these subjects deals with general
software and does not applies to software being developed using any Object
Oriented Language. Object Oriented Languages are featured with concepts like
data abstraction, data hiding, data binding, class, object, inheritance,
polymorphism and message passing. If the software is featured with these
concepts, makes the software more secure for data, durable and easily upgradable.
Any previously used techniques like software engineering does not consider these
concepts while designing software. Hence a need for other approach for
designing Object Oriented System was observed, named as Object Oriented
Analysis and Design.
Now a day’s mostly software are application softwares, which helps to store
and process business data. Hence the software is responsible for business data.
But the software defines different procedures which processes the business data
which has become now precious for business decisions. Which has given rise to
a need for the software which limits the procedures from processing data.
Software, most of the times is seen as collection of programs. But in actual
sense it is not only programs but also data, platform being used (machine
specifications, operating system, memory size available and many more
characteristics of system). By considering all specifications at clients location
Object-Oriented
Concepts,
Modeling and UML

NOTES
2
and Design
designer of software designs the software. The major decision is about
programming paradigm. Section 1.1 discusses about programming paradigms
and object orientation.
What is Object Orientation
Programming paradigm is the way to classify different programming
languages depending on their features. Features of every programming language
used decides features of the software. Roughly software can be system software
or application software. The category of software helps to define general features
hold by the software and consequently helps to select proper programming
language an also programming paradigm to be followed.
Generally the data centric application software follows Object Oriented
Paradigm. Object- Oriented Programming (OOP) is one of programming
paradigm, considered next to Procedure Oriented Programming. The objective
of OOP is to secure data from unintended access of procedures. Here procedures
are programming constructs or functions which accepts data as input, processes
it and generates output, and hence are responsible for changing or damaging data.
In the previous semester while studying Java you have seen characteristics
of OOP. With respect to design of a software we will revise here some of the
characteristics of OOP languages.
Class
Class is a basic software construct of any OOP language. The concept of
‘class’ helps to achieve basic objective of any OOP language like data hiding,
data binding, data abstraction and data encapsulation. Class is always termed as
a blueprint of an object. Class is treated as user defined data type and helps user
to bind data and methods together. The class defines data as properties and
methods
More than a software construct, class plays crucial role in any Object
Oriented system. Design of an Object Oriented System is always seen as sharing
of responsibilities. Here system data and methods (processes) for processing
system data are assigned as responsibilities to classes in the system. Hence classes
in any Object Oriented Systems forms its base structure.
Object
Object is a runtime entity defined on a class. An object is responsible for
storing system data and process it. An object is responsible for carrying out major
functionalities in a system. While designing a system an object view helps to
design classes. While designing software classes, visualization of objects can
help us for defining properties and add methods after understanding role of each
object in the system.
One need to imagine what different roles will be played by an object in the
system while accomplishing its functionalities.
Object-Oriented
Concepts,
Modeling and UML

NOTES
and Design
3
Inheritance
The concept of inheritance allows reusability. With the help of inheritance,
a previously developed system can be easily upgraded. On the base of the existing
system, with the help of the concept of inheritance one can modify or add new
functionalities. For the purpose previously defined classes and interfaces can be
used for modification and defining new classes and interfaces.
But the basic condition for upgrading the system, classes in the system needs
to be designed and developed so that those can be inherited. The designer of an
original system should visualize future enhancement which can be introduced in
the system.
Polymorphism
The word ‘polymorphism’ is a Greek word which means ‘One Thing
Having Many Forms’. In OOP polymorphism is achieved through method
overloading, method overriding and Dynamic Method Dispatch (DMD) which
is also known as virtual functions. The concept of polymorphism can be
considered as a major advantage of OOP. Without giving much pain to user it
allows user to add variations in functionalities. Major advantages of
polymorphism can be observed while upgrading any system.
Message Passing or Association
Major objectives of OOP are data hiding and data encapsulation, which
doesnot allow objects to share system data among them. At the same time, as
objects form basic components, need to share some necessary data among them
so that system can work smoothly.
For example if we consider ‘Motor Bike’ as a system, petrol tank, engine,
gear box, wheels, accelerator etc are basic components which has their own roles
in working of system ( a motor bike). But at the same time there exist dependency
among all these, which helps system working fluently. This dependency is
sharing fuel with engine, sharing generated power with accelerator and onwards.
This sharing helps working of motor bike. But this sharing has to be done
properly, otherwise system stops it’s working.
This kind of sharing we need in any software system, where data sharing is
expected to be carried out between objects and is implemented through Message
Passing or Association.
Model
Model represents, not all but, major features original system. From the
model one can, get idea about the original system. The model may not represent
minute features, but it clears major part of system. For example, the model of
building kept at builders or architecture’s office which represents original
building, a small representation of real one. Object-Oriented
Concepts,
Modeling and UML

NOTES
4
and Design
Model for software system is its design, diagrams explaining processes and
data in system. Various diagrams help stakeholders to understand and to visualize
the system. This section helps in understanding modeling of software.
Introduction to Modeling
As discussed while introducing with word ‘model’, for understanding any
new system being developed or under construction, model of the system is
required. Every system’s modeling is done differently depending on nature of
system. The software after development cannot be seen and touched, and hence
modeling of any becomes tough. In this case a software can be represented using
diagrams explaining major features of software. Through different diagrams we
can understand working of software, interaction between its processes and data
as well as data stores. Along with software design, for explaining each program
also different diagrams are also available. In this section we are going to revise
traditionally used diagrams for designing software.
Data Flow Diagram (DFD)
Different processes handled by the software forms its characteristics. At the
same time data accepted as an input, and generated output by the software is also
important to understand for its stakeholders. So if anybody wants to describe his
or her software under study, it can be described with the help of major processes,
data being used by these processes, data as given output and the entities
interacting with the software.
For describing these details different methodologies can be used. Basically
it can be described using either text or using diagrammatic representation. The
study shows that diagrams always can better explain the context rather than text.
Hence for describing the software under study, which is already complex in
nature, diagrams will be more helpful. The technique of DFD (Data Flow
Diagram) was developed with the same view and was accepted as one of the
efficient tool for designing of the software.
DFD, for describing any software, always concentrates on three major
participants –
o Processes – These represents major functionalities or program constructs
are to be written in the software under study. The process symbol in any
DFD helps to explain characteristics of the current software. Any
stakeholder can understand easily what different situations can be
handled by the software and role of the software in their day to day
business life.
o Data – Data in any DFD is represented with data flow (arrows) and ‘data
stores’. ‘Data stores’ can be seen as tables in Database. ‘Data Stores’
helps in designing ERD for the current system. Flow of data through
various processes and entities is shown with arrows.
Object-Oriented
Concepts,
Modeling and UML

NOTES
and Design
5
o Entities – Entity in DFD is the one who interacts with the system. Entity
generally explains role like customer, manager etc., or it may be anyother
system who expects some output or gives some input to the system under
study. DFD, to represent every minute but important process, is drawn
in various levels. The first level is ‘Context Level’, which gives overview
of the system. First level onwards designer go on detailing the system.
First level onwards each level goes on detailing a process. Following
diagram shows First Level DFD for ‘Order Management System’.
Fig 1.1 : DFD for Order Management System
Source : https://www.memoireonline.com/07/12/5995/m_Online-
ordering-and- inventory- system16.html
Entity Relationship Diagram (ERD) – DFD is the diagram used for
modeling processes. These processes are carried out on data which is represented
as data stores in DFD. With reference to data stores in DFD, ERD is designed
for the system.As the name suggests, it represents relationships between different
entities. Here entities represent objects from the system for which data needs to
be stored for processing purpose. Every entity in system is related with some
other entity, which is explained with the help of an action(verb). Each entity, to
describe as a table, is represented with attributes. These attributes helps to explain
data in detail. Following diagram shows ERD for ‘Order Management System’.
Object-Oriented
Concepts,
Modeling and UML

NOTES
6
and Design
Fig 1.2 : ERD for ‘Order Management System’
Source : https://www.visual-paradigm.com/guide/data-
modeling/what-is-entity- relationship- diagram/
• Algorithm
DFD and ERD models the entire system. System consists of collection
of different programs, represented as a process in DFD. For a
developer, who actually works on development of the system, every
process need to be explained in more detail. This detail explanation
for the process is done with the help of ‘algorithm’. Algorithm is a
collection of step by step sequence of instructions written in simple
English. With the help of algorithm it becomes easy to write a program
using any programming language. Following table shows a simple
algorithm for the process ‘1.0 Manage Orders’ from the above system
‘Order Management System’.
Fig 3.3 : Algorithm for Order Processing System
Object-Oriented
Concepts,
Modeling and UML

NOTES
and Design
7
• Flow Chart
As discussed earlier understanding a diagram is more easy than
understanding any textual information. The algorithm written for the
process can be represented diagrammatically with the help of
flowchart. Flowchart is defined as diagrammatic representation of
algorithm. Following diagram shows the flowchart for the same
algorithm given above.
Fig 3.4 : Flowchart for Order Processing System
Source : https://www.edrawsoft.com/template-order-processing-
flowchart.php
Object-Oriented Modeling
In the above section we have discussed about modeling a system. In the
section we have discussed about the techniques used traditionally for designing
any software system. But these techniques were observed to have certain
drawbacks. The drawback of these techniques was observed after development
of new programming paradigm i.e. Object Oriented Programming (OOP)
Paradigm.
This new paradigm has presented totally new concepts of programming.
These new concepts entirely changed programming scenario. Model of the
software is considered to be a bridge between user of the system and developers
of the system. Developers refers model to understand requirements and
expectations of client and direct users of system. But the modeling done through
previous techniques does not consider these newly introduced concepts and hence
development of system becomes challenging job for developing team and may
fail to implement the model properly. Consequently the end product was unable
to satisfy the end user. This happened though model of the system was designed
after considering all user requirements. Hence some new changes were expected
in modeling of software system following OOP concepts.
Object-Oriented
Concepts,
Modeling and UML

NOTES
8
and Design
Here to avoid failures in acceptance test of the software, need for
development of new techniques which can help in representing OOP concepts
was observed. The concepts of OOP, which are implemented as programming
constructs are discussed in section 1.1, like class, object, polymorphism etc. Now
the requirement of new technique is to model the software in the form of these
concepts, so that development of software will become easier and will meet the
requirements of the developer team and user.
In this subject ‘Object Oriented Analysis and Design’ we are going to
discuss about Object- Oriented Modeling.
Object-Oriented System Development
The outcome of discussion in section 1.2.2 Object-Oriented Modeling, is
same modeling techniques as used previously cannot be used for modeling OOP
systems. Hence new techniques were developed for modeling of OOP softwares.
These new techniques helps designer to design the system by considering all
OOP concepts. When the model for OOP system is being designed, it should
follow certain sequence so that modeling should be more productive. Following
subsections discusses about the ideal sequence to be followed while working on
OOP systems.
Functions / Methods and Data
In any software the major role is palyed by processes. Every software
designing starts with defining functionalities in desired system. Unlike in
procedure oriented systems where functionalities are defined independently and
are connected afterwards, in OOP systems executing a desired functionality is
the responsibility of an object in the system. Therefore executing functionality
is responsibility of an object, and cannot be exist or executed independently.
When we think of functionality, data comes along with it. Hence with each
functionality a thought is given for data also. The data which is being processed
by the functionality. When a designer think of functionality and data used by it
together, it helps him to design ‘class’. As discussed earlier, class is the basic
concept of OOP. Classes in the system and relationships among those forms basic
structure for the system.
To start with the new system design, like procedure oriented systems or
previous concepts in Software Engineering, a designer only think of major
functions and data required by these functions.
For example, while designing software for a hospital management system
as a designer we will go on defining functions firstly and then considering each
function in detail will list all data along with its probable datatype.
Here designer has not considered any object oriented approach while listing
all major functions and required data. The next challenge for designer is to now
introduce object oriented concepts like class, object and inheritance. If the
designer fails to do this, the system also fails as an Object Oriented System and
Object-Oriented
Concepts,
Modeling and UML

NOTES
and Design
9
cannot achieve goals and features of OOP systems. Next sub-section 1.3.2
discusses how OO Analysis can be carried out.
Object-Oriented Analysis
As stated in previous sub-section 1.3.1, now designer have the list of major
functionalities along with the required data and ready to carry out the Object
Oriented Analysis. While analyzing the system with the view of Object Oriented
System, designer has to see every entity in a system as an Object, which
encapsulates data with functions. Every object in system has its own
characteristics, role, behavior and responsibility towards the System.
For example, in simple language an object can be visualized as a person, as
a part of a society, having his own characteristics (expertise), his own role, his
own behavior which defines his reactions to other persons (objects) in the society
(software system) and also responsibilities according to which he is expected to
accomplish tasks.
The functionalities and data listed for the system are nothing but the
responsibilities of different objects in the system. Now the task remaining is
defining or finding objects in the system and assigning data and functionalities
as a responsibility to them. This assignment job is to be done very carefully with
consideration of different OOP concepts discussed earlier in section 1.1.
Assignment of functionalities as the responsibility to objects is the most
challenging job for the designer. He need to achieve two opposite goals-
• Data hiding with data binding – To keep data secure and to avoid
unintended data handling
• Data Sharing – To make the system work fluently
These goals are possible to achieve only with a thoughtful design of ‘Class
Diagram’. Here class diagram, which is considered as basic diagram for any
object oriented software, represents classes and their relationships. Goal of each
class is to encapsulate data with process (functionalities) to achieve the goal of
data hiding with data binding. While goal of relation between any two classes is
to share their private data with each other so that working of the system is carried
out fluently.
As an output of Object Oriented Analysis a class diagram is designed. The
next step towards development of software is construction of the software. The
process of software construction is discussed in the sub-section 1.3.3.
Object-Oriented Construction
Once the analysis for the system is completed, the first iteration of class
diagram is ready for further improvements in upcoming iterations.
Simultaneously the team starts with the development of artifacts (small software
constructs which may include rough definition of classes or functions) and thus
construction of system starts. While defining these artifacts the designer come
Object-Oriented
Concepts,
Modeling and UML

NOTES
10
and Design
forward with some constructional problems, like setting relation between classes,
or for smoothing the communication between two classes associate class may be
needed.Accordingly again the previously designed diagrams and defined artifacts
are modified. This process is done iteratively.
While the construction process with the help of artifacts is going on, for
better understanding of system different UML diagrams are designed like state
transition diagram(STD), activity diagram, sequence diagram which helps
development of artifacts more easy. With the end of every iteration much part of
construction is done.
In construction one cannot concentrate on only coding of classes and their
interaction, but need to think and design for software architecture and hardware
architecture. The OOP platforms are very powerful to support different types of
software and hardware architectures. With the development of different types of
software and hardware architectures. Hence going beyond only coding part of
software, designer now has to think about architecture of software and hardware.
Therefore while constructing system designer uses component diagram and
deployment diagram which are UML architectural diagrams.
Thus the OOAD system is constructed iteratively. With the end of
construction phase, the system enters in the next phase of testing. The testing
phase of testing is discussed in the next sub-section 1.3.4.
Object-Oriented Testing
Like a Procedure Oriented software, Object Oriented Software also need to
undergo various rigorous tests for assuring its quality and acceptance. For testing
any software different techniques are developed like unit testing, integration
testing. These testing techniques are carried out at different levels of software
development lifecycle. The steps undertaken for testing considers testing of
procedure oriented software. Applying the same techniques for Object Oriented
software becomes difficult. Research confirms that testing methods proposed for
procedural approach are not adequate for OO approach. These testing problems
are faced due to distinguishing characteristics of Object Oriented Languages.
Typical OO software characteristics that affects testing can be stated as –
• State dependent behavior
• Encapsulation
• Inheritance
• Polymorphism and dynamic binding
• Abstract and generic classes
• Exception handling
Hence there is need to think differently and redesign the testing strategies
for Object Oriented Software.
Object-Oriented
Concepts,
Modeling and UML

NOTES
and Design
11
Though Unit testing and Integration testing are considered to be better
techniques for testing of any software, for applying same for testing of Object
Oriented Software need to be modified. These techniques to be applied for OO
systems are discussed below –
• Unit Testing - Considering any procedure oriented system the term unit
testing defines testing of individual programs or functions. But in Object
Oriented Software unit testing need to be carried out at different levels.
In any OO program definition of a ‘class’ forms a unit. Hence at unit
testing individual classes are tested for their functionalities. This is also
called as ‘intra-class Testing’. In intra class testing, class functionalities
are tested as reference to the system working. The testing of OO software
is more time consuming and hence it becomes expensive to test every
event individually. Therefore every event is tested with context with class.
• Integrated Testing – once every class functionalities are tested, the next
step is to carry out integrated testing. For any OO software in integrated
testing inter-class testing is carried out. The classes of any system cannot
work individually, and need to have interaction with other classes in the
system. These interactions between classes takes place with data sharing.
These interactions are tested in integration testing.
Conclusion
The Object Oriented Paradigm introduces new concepts of programming
which are more powerful and useful for data centric as well as network systems.
Using Object Oriented platform for development of softwares is the demand of
time. But at the same time just switching from other paradigm to OOP paradigm
is not sufficient. Hence the process of software development need to rethink and
new techniques for analysis and design of the software need to be developed.
The chapter has discussed how OOP is different than other programming
paradigms, and a base has been created for study of Object Oriented Analysis
and Design (OOAD).
*****
Object-Oriented
Concepts,
Modeling and UML

NOTES
12
and Design
UNIT NO - II
ITERATIVE DEVELOPMENT
AND UML
To understand
• Iterative development of software and its advantages over sequential
development
• Rational Unified Process (RUP) as iterative development lifecycle
• Unified Modeling Language (UML) as a tool for OOAD
• Use Case Modeling as Behavioural modeling for the Object Oriented
Software
• How to draw activity diagram for any OO software
Introduction
In the first chapter we have discussed characteristics of object-oriented
languages, and with reference to these characteristics, we have also seen why
and how designing for object-oriented software is different. Hence need for some
different techniques for designing object-oriented software was observed.
In this chapter, we are going to learn a new technique, Unified Modeling
Language (UML), which is a powerful method for designing object-oriented
software. UML is the latest designing tool and is being used for designing any
type of software like a desktop application, or a website or web application, or a
complex system software. UML as a designing tool provides collection of
different diagrams dealing with various aspects of software. The designer can
select required diagrams that are sufficient for explaining the system and can be
referred by a developing team while working on development of the software.
These diagrams are so self-explanatory and can be used by the client to cross-
verify various functionalities being covered under the software. This helps client
to get idea about the software and its working. After understanding the system
diagrams, if in case the client feels he may come up with some new requirements
and accordingly the system diagrams consequently system can be modified. In
the sense this reduces the possibility of occurrence of problems while acceptance
test.
Moreover UML supports iterative development of system, which allows
designer and developer to entertain new requirements or modify existing one at
any stage of development. This iterative development is possible due to the
Iterative Development
and UML

NOTES
and Design
13
concept of RUP (Rational Unified Process). In the chapter we are also going to
study about RUP and phases in RUP.
The chapter also discusses about the different types of diagrams and
introduces them with short explanation for each. After going through these
various types of diagrams you will understand as a designing tool, UML is
powerful.
The same chapter discusses about the Use case diagram and activity diagram
which are the diagrams from which designing process for system starts. As
discussed earlier, you will observe how UML diagrams are easy to draw and
understand. It will also explain interdependency among the various diagrams
which we are going to study through.
Understanding Requirements
Before starting software system design or development, firstly the team
needs to work on the requirements of the client. The software development
lifecycle initiates with the collection of requirements from different users, may
be direct or indirect. For collecting requirements from users of system different
methods like interviews, questionnaires, creation of a particular scenario and
understanding the flow of process, etc. are used. But gathering and writing of
requirements is not enough to design the software. Further work need to be done
on these collected requirements so that designing the software will be more easy
for designer.
Previously in software engineering for processing requirements a scientific
process was used which is termed as requirement engineering. Requirement
engineering is a technical term that consists of various stages which helps for
defining, documenting and maintaining the requirements. Phases of requirement
engineering process are requirement elicitation, requirement specifications,
requirement verification and validation, and the last phase is requirement
management. Every phase gives the output as some model of the system under
study like DFD, ERD, Functional Dependencies etc. these models are used or
referred as design of the system which are interdependent.
The major problem faced with the requirement engineering is each phase
goes on finalizing the requirements and hence modification of existing
requirements or addition of new requirements becomes tough task. For adding
any new requirement one need to modify all dependent diagrams and hence
software may not be able to satisfy the client or the user. Implementing these
changes are more time consuming and hence are not affordable for the company.
Hence need for iterative development was felt.
With the development of new techniques, researchers and designers of
software also started thinking for iterative development lifecycle. The advantage
of iterative development lifecyle, improved or new requirements can be easily
added to the designing and development process and satisfaction of client
improves result of acceptance test. The iterative development lifecycle is Iterative Development
and UML

NOTES
14
and Design
discussed in 2.2 section. For improving the processing of requirement and for
accepting the challenge the designing of software the new concept is used is –
‘understanding of requirements’. Only technical writing of requirements is not
sufficient for designing an object oriented software. And, therefore, while
working on any requirement, it is explained with the scenario, to explain how
the process is carried out in reality at the working place. The advantage of
scenarios is, various small and apparently negligible requirements are covered
with every scenario. This also helps in finding relations and dependencies
between different data collected and used in different scenarios. To understand
writing scenario with example, we will consider Hospital Management System,
discussed in previous chapter. In the hospital instead of writing requirements just
as –
a) For new patient generate new OPD card by entering patient
information.
b) If the OPD card is existing already then renew it after checking validity
date, else just charge minimum.
c) Open the case paper for the patient and add to the queue for doctor.
d) Generate receipt.
Here if the requirements are written like above it does not clear the situation
and does not help in writing programs.
Instead, the above related requirements can be explained well with the
following scenario as –
a) A patient arrives at the reception table. He was asked to provide OPD
card number which is his unique ID in the system. The patient says he
didn’t have OPD card. The receptionist asks him if he is visiting
hospital for the first time. If he says ‘yes’, receptionist will ask him to
fill up the form. The form accepts the patient’s information as his
name, address, contact number, age, disease, allergies. While accepting
the filled form the receptionist will take his snap which will be stored
with his file. The receptionist will ask him to pay charges for new OPD
card. The receptionist will enter his information and will print card as
well as receipt for him. At the same time a new case-paper will be
generated with same information as for OPD card, and will be added
to queue. The patient will receive the OPD card and receipt from
receptionist.
b) A patient arrives at the reception table. He was asked to provide OPD
card number which is his unique ID in the system. The patient will
provide the OPD card. The receptionist will enter the card number.
b1) If the validity duration, as set by the administrator, is over, the
patient will be asked to pay renewal charges for the card. The
receipt will give receipt to the patient. The case paper for the
patient will be opened and will be added to the queue.
and UML

NOTES
and Design
15
b2) If date of card is within validity period, the patient will be asked
to pay visiting charges. The receipt will give receipt to the patient.
The case paper for the patient will be opened and will be added
to the queue.
If the requirements are written like these scenarios it explains more better
as well as helps designer and developer to imagine the situation and develop
artifacts also. Developing artifacts with analysis phase is one of the characteristic
of iterative development and scenarios helps this with the chance of improvement
in upcoming stages. How iterative development works that will be explained in
the next section.
Rational Unified Process (RUP)
Rational Unified Process abbreviated as RUP defines an iterative process
for software development, and hence helps overcome the drawback of sequential
software development process. RUP was created by the Rational Software
Corporation which is a division of IBM since 2003. RUP, as a software
development process, does not defines any strict phases, and hence depending
on demand of the system the process can be modified. Hence it keeps designer
free to accommodate new requirements at any specific phase and allows to select
the elements of the process that are appropriate for their needs.
The initiative for the development of an iterative process was taken by
Philippe Kruchten who was an experienced Rational technical representative.
The development of the RUP began with the creation of the Rational Objectory
Process (ROP) in 1996 written by Ivar Jacobson and company. This was renamed
Rational Unified Process (RUP) in subsequent releases, in part to align the name
with that of the Unified Modeling Language, which was again contributed by
Ivar Jacobson. During different releases initial versions were with Objectory's
guidance on practices such as use cases, and incorporated extensive content from
Jim Rumbaugh's Object Modeling
Technology (OMT) approach to modeling, Grady Booch's Booch method,
and the newly released UML 0.8. It can be observed that the development of
RUP and UML is going on parallel.
RUP is based on a set of building blocks and content elements, describing
what is to be produced, the necessary skills required and the step-by-step
explanation describing how specific development goals are to be achieved. The
main building blocks, or content elements, are the following:
• Roles (who) – A role defines a set of related skills, competencies and
responsibilities.
• Work products (what) – A work product represents something resulting
from a task, including all the documents and models produced while
working through the process.
• Tasks (how) – A task describes a unit of work assigned to a Role that
provides a meaningful result.
and UML

NOTES
16
and Design
As we have discussed in section 2.1, ‘requirement understanding’, every
phase of RUP creates certain artifacts (small software constructs like class or
functions). While designing for new requirements, these previously developed
artifacts are assessed for quality and satisfaction of the requirement. If necessary
are modified along with the development of new artifacts for new requirements.
This feature of RUP was introduced over the time period to fit the current
requirements of software development process. These modifications in RUP to
hold the following characteristics, which makes software development process
more flexible for modern software engineering –
• Develop iteratively - It is best to know all requirements in advance;
however, often this is not the case. Several software development
processes exist that deal with providing solutions to minimize cost in
terms of development phases.
• Manage requirements - Always keep in mind the requirements set by
users.
• Use components - Breaking down an advanced project is not only
suggested but in fact unavoidable. This promotes ability to test individual
components before they are integrated into a larger system. Also, code
reuse is a big plus and can be accomplished more easily through the use
of object-oriented programming.
• Model visually - Use diagrams to represent all major components, users,
and their interaction. "UML", short for Unified Modeling Language, is
one tool that can be used to make this task more feasible.
• Verify quality - Always make testing a major part of the project at any
point of time. Testing becomes heavier as the project progresses but
should be a constant factor in any software product creation.
• Control changes - Many projects are created by many teams, sometimes
in various locations, different platforms may be used, etc. As a result, it
is essential to make sure that changes made to a system are synchronized
and verified constantly.
Still the development is going on and RUP process is in modification phase.
Latest releases of RUP try to cope up with the new upcoming types of softwares
and try to overcome the problems faced while development of software, so that
will always give quality software as an output of the process.
RUP Phases
The RUP, as a software development process, has determined a project life-
cycle consisting of four phases. Like SDLC in Software Engineering, these
phases, at a high level appear in a similar way. Although the deatails of the
process explains every phase as an iterative phase. Also, each phase sets an
objective and at the end of the phase fulfillment of objectives is assured.
and UML

NOTES
and Design
17
Following subsections explains four phases of RUP.
I Inception
The word inception itself explains role of the phase in software
development. The phase can be compared with feasibility study, where initial
study for the project is carried out.Athorough study about the system under study
is carried out and objectives of the study are to get knowledge about –
• Business context i.e. to understand and get current working system details
• Success factors which includes expected revenue generated, market
recognition, etc.
• Financial forecast which helps to budget the cost of the final product.
In the phase the working team’s objective is to generate –
• Basic use case model
• Project plan
• Project description which includes core project requirements, constraints
and key features
• Initial risk Assessment
Once all above reports are ready with the team, now the project is
checked against the following criteria:
• Discussion with Stakeholder regarding project scope with reference to
use case model and other estimates about cost and schedule estimates.
• ‘Requirements understanding’ as represented in use cases.
If the project does not pass this the life cycle objective milestone, it either
can be cancelled or repeated after being redesigned to better meet the criteria.
II Elaboration
In the phase, as the name suggests, the system is more elaborated or
explained with some more depth. With the help of different diagrams artifacts
from the system are elaborated. The phase is iteratively executed, till artifacts
for most of the use cases are not being generated. Along with the development
of various diagrams and artifacts primary objective is to minimize the key risk
items identified by analysis up to the end of this phase. The elaboration phase is
where the project starts to take shape. In this phase the problem domain analysis
is made and the architecture of the project gets its basic form.
The outcome of the elaboration phase is
• A use-case model in which the use-cases and the actors have been
identified and most of the use-case descriptions are developed. The use-
case model should be 80% complete.
and UML

NOTES
18
and Design
• A description of the software architecture in a software system
development process.
An executable architecture that realizes architecturally significant use cases.
• Business case and risk list which are revised.
• A development plan for the overall project.
• Prototypes that demonstrably mitigate each identified technical risk.
• A preliminary user manual (optional)
If the project cannot pass this milestone, there is still time for it to be
canceled or redesigned. However, after leaving this phase, the project transitions
into a high-risk operation where changes are much more difficult and detrimental
when made.
The key domain analysis for the elaboration is the system architecture.
III Construction
The primary objective is to build the software system. In this phase, the
main focus is on the development of components and other features of the system.
This is the phase when the bulk of the coding takes place. In larger projects,
several construction iterations may be developed in an effort to divide the use
cases into manageable segments produce demonstrable prototypes.
IV Transition
The primary objective is to 'transit' the system from development into
production, making it available to and understood by the end user. The activities
of this phase include training the end users and maintainers and beta testing the
system to validate it against the end users' expectations. The system also goes
through an evaluation phase, any developer which is not producing the required
work is replaced or removed. The product is also checked against the quality
level set in the Inception phase.
With the end of Transition Phase it is checked if all requirements are met.
The requirements of the system defines the objectives of the system and on
satisfaction of these objectives the RUP lifecycle ends here. If the elaboration
phase takes sufficient iterations chance of satisfaction of objectives gets
improved. Theoretically at least three to four iterations for elaboration are
suggested.
Unified Modelling Language (UML)
As discussed in Chapter 1, the primitive techniques used for designing
software are not suitable for object oriented software analysis and designing and
hence UML techniques were developed during the era of 1990’s as an
amalgamation of several techniques, prominently OOAD technique by Grady
Booch, OMT (Object Modeling Technique) by James Rumbaugh, and OOSE
and UML

NOTES
and Design
19
(Object Oriented Software Engineering) by Ivar Jacobson. UML attempted to
standardize semantic models, syntactic notations, and diagrams of OOAD.
UML is a powerful technique which provides number of diagrams for
designing an object oriented system by considering different aspects of the
system like -
• Design
• Implementation
• Process
• Deployment
These are discussed in detail in subsection 2.3.3. Like RUP, UML is also in
development stage. Still new improved techniques are being introduced which
tries to include newly introduced technologies. Next subsections discusses more
aspects of UML.
Designing Tool for Object Oriented Analysis and Design (OOAD)
The objective for development of Object Oriented Programming Paradigm
was data security and reusability. But with the development of this new
programming paradigm it was observed that old software designing techniques
were not sufficient to represent Object Oriented concepts. And so development
of new designing technique was felt. Different scientists started working on
development of new designing techniques, and UML was the output of their
efforts.
It was named as Unified Modelling Techniques, which was abbreviated as
UML. Different scientists were working independently on development of new
designing techniques, which were having their own advantages and
disadvantages. These all techniques were compared with each other and the best
of those were selected and were added under heading of UML. Hence it was
named as ‘Unified’. These unified techniques helps to model different aspects
of the system like coding, building components, deployment system, and hence
the word ‘modeling’ is used in UML. Though major techniques under UML
represents the system graphically, each diagram is sufficient to communicate
with reader as every diagram is easy to understand. Moreover each diagram is
so self explanatory that it is able to explain the programming construct. All
diagrams in UML provides a graphical language for OOAD that gives a standard
way to write a software system’s blueprint. It helps to visualize, specify,
construct, and document the artifacts of an object-oriented system. It is used to
depict the structures and the relationships in a complex system. Hence these
techniques are named as ‘Language’.
As discussed earlier any Object Oriented System acts at two levels,
structural level and behavioural level. UML provides a collection of diagrams.
With powerful graphical representation, these various diagrams also covers these
both levels of system. These diagrams are categorized under two headings –
and UML

NOTES
20
and Design
structural diagrams and behavioural diagrams. This reason makes UML more
suitable technique for developing Object Oriented Systems. UML has four
common mechanisms which makes it different than other analysis and designing
techniques−
• Specifications - In UML, behind each graphical notation, there is a textual
statement denoting the syntax and semantics. These are the specifications.
The specifications provide a semantic backplane that contains all the parts
of a system and the relationship among the different paths.
• Adornments - Each element in UML has a unique graphical notation.
Besides, there are notations to represent the important aspects of an
element like name, scope, visibility, etc.
• Common Divisions - Object-oriented systems can be divided in many
ways. The two common ways of division are −
i. Division of classes and objects − A class is an abstraction of a
group of similar objects. An object is the concrete instance that
has actual existence in the system.
ii. Division of Interface and Implementation − An interface defines
the rules for interaction. Implementation is the concrete
realization of the rules defined in the interface.
• Extensibility Mechanisms - UML is an open-ended language. It is
possible to extend the capabilities of UML in a controlled manner to suit
the requirements of a system. The extensibility mechanisms are −
i. Stereotypes − It extends the vocabulary of the UML, through
which new building blocks can be created out of existing ones.
ii. Tagged Values − It extends the properties of UML building
blocks.
iii. Constraints − It extends the semantics of UML building blocks.
Overview of UML
As per previous discussion, UML has many features which makes it unique
as a designing tool. Due to this Unified Modeling Language is now accepted as
a standardized general- purpose modeling language and is managed as a de facto
industry standard by the Object Management Group (OMG). Though still it is
under development and keep on modifying with new concepts it is accepted by
software industry as it enables designer to view the system with two different
views - Static vs Dynamic View. For expressing system with these two different
views UML takes help of various diagrams. Hence the diagrams in UML are
categorize under two headings as – structural modeling which explains the static
view of the system; while behavioural modeling and interaction modeling which
explains the dynamic view of the system.
and UML

NOTES
and Design
21
Static view is used to specify the static structure of the objects, classes or
components that exist in the problem domain which are expressed using class,
object or component. It includes class diagrams and composite structure
diagrams.
While dynamic view refers to the dynamic behaviour of the system. Objects
defined for the classes are responsible for adding dynamic behaviour to the
system. The dynamic behaviour of an object can be its reactions to the external
environment, or its involvement in different situations faced by the system or its
interaction with other objects in the system. For explaining object’s dynamic
behaviour two types of modeling is used, the first is behavioural modeling while
the other is interaction modeling. Both these helps to represent the object’s
behaviour during runtime. It is represented by use case, sequence, activity,
collaboration, and state.
Over the time period UML has go on developing and different versions of
UML were introduced. The current version used of UML is 2.5.1 which was
released in December 2017. According to this version there are 11 different
diagrams which are used majorly, which are divided into three categories:
• 5 diagrams represent structural information,
• 3 represents general behavioural diagrams,
• While 3 other represents different aspects of interactions among objects.
These diagrams will be discussed briefly in next section.
Conceptual Model of UML
Before starting with the discussion on diagrams in UML firstly one need to
understand basic building blocks of UML. These basic building blocks helps in
modeling the system. In any Object Oriented Software basic building block is
‘an object’. For fulfillment of basic requirements like storing data, processing
data and storing results, an object is responsible. It is not only responsible for
storing and processing its own data but also responsible for developing
interactions between different objects in the system. An object is an basic
construct of an OOP, and the entire system is build around these various objects.
Objects and relations between objects can be implemented through basic concepts
of OOP. A conceptual model for the system is made up of various concepts which
are interrelated. It helps us to understand –
• What the objects are?
• How interaction takes place to execute a process?
You have to understand the entities and relationships between them before
actually modeling the system. These defined entities and their relations helps to
define basic objects and their relations in the system. Once the objects are found,
it becomes easy to implement Object Oriented concepts which are expected to
be implemented to achieve objectives of any Object Oriented System. Iterative Development
and UML

NOTES
22
and Design
Following object-oriented concepts are required to begin with UML
• Object: It is a real-world entity. There are multiple objects available
within a single system. It is a fundamental building block of UML.
• Class: A class is nothing but a container where objects and their
relationships are maintained.
• Abstraction: It is a mechanism of representing an entity without showing
the implementation details. It is used to visualize the behaviour of an
object.
• Inheritance: It is a mechanism of extending an existing class to create a
new class.
• Polymorphism: It is a mechanism of representing an object having
multiple forms which are used for different purposes.
• Encapsulation: It is a method of binding the object and the data together
as a single unit. It ensures tight coupling between the object and the data.
Concepts stated above are also called as the basic building blocks of a UML.
At the center of these building blocks of the system is the Use Case view. A Use
Case represents the functionality of the system. Hence, other perspectives as
discussed in section 2.3 i.e. design, implementation, process and deployment are
dependent on use case. Design of any object oriented system consists of classes,
interfaces, and collaboration. UML provides different diagrams like class
diagram, object diagram to explain structural view of the system. Implementation
defines the components assembled together to make a complete physical system.
UML component diagram is used to support the implementation perspective.
Process defines the flow of the system. Hence, the same elements as used in
Design are also used to support this perspective. Deployment represents the
physical nodes of the system that forms the hardware. UML deployment diagram
is used to support this perspective.
Hence the conceptual model is to implement concepts of OOP in the system
effectively wherever possible, which is possible only when the designer of the
system has expertise in it.
Diagrams in UML
After conceptual model which explains how efficiently different concepts
of OOP can be used in the system, the next task is to design various diagrams
for the system under study. UML provides a rich collection of diagrams which
tries to cover all aspects of Object Oriented Software. As discussed in subsection
2.3.2, UML diagrams covers two views of the system, the structural view and
behavioural view. The behavioural view again with behavioural covers
interaction view of the diagram. Accordingly diagrams in UML are divided in
three categories –
and UML

NOTES
and Design
23
• Structural Diagrams
• Behavioural Diagrams
• Interaction Diagrams
We are going to cover nine UML diagrams here. These all diagrams along
with their categories hierarchically as shown in the following UML diagram map:
Fig 2.1 : Arrangement of UML Diagrams in Three Categories
The UML diagram’s application and role in development process of the
software system decides category of the diagram. For example if the diagram
explains about major software or hardware components of the system like class
or object or using a particular type of topology for arranging nodes then it forms
the structural diagram. If the diagram explains how a system will handle a
particular scenario either step by step or when and how a particular object will
react then the diagram is explaining behaviour of the system and hence will be Iterative Development
and UML

NOTES
24
and Design
added under the category behavioural diagrams. Below all three categories are
explained –
Structural Diagrams - Structural diagrams depict the static structure of
the elements in the system. i.e., how one object relates to another. It shows the
things in the system– classes, objects, packages or modules, physical nodes,
components, and interfaces. For example, just as the static aspects of a house
encompass the existence and placement of such things as walls, doors, windows,
pipes, wires, and vents. The five UML structural diagrams are roughly organized
around the major groups of things. Since structural diagrams represent the
structure, they are used extensively in documenting the software architecture of
software systems.
For example, the class diagram describes classes and different relations
between them for sharing data among.
• Behavioural Diagrams – As we know, in any Object Oriented System
an object exist at two different levels – structural and behavioural.
Behaviour of an object defines its reactions to different situations. UML
provides three behavioural diagrams used to visualize, specify, construct
and document the dynamic aspects of a system. It shows how the system
behaves and interacts with itself and other entities (users, other systems).
They show how data moves through the system, how objects
communicate with each other, how the passage of time affects the system,
or what events cause the system to change internal states. Since behaviour
diagrams illustrate the behaviour of a system, they are used extensively
to describe the functionality of software systems. In other words, a
behavioural diagram shows how the system works ‘in motion’, that is
how the system interacts with external entities and users, how it responds
to input or event and what constraints it operates under.
As an example, the activity diagram describes the business and operational
step-by- step activities of the components in a system.
• Interaction Diagrams – These are again a kind of behavioural diagrams
which helps in explaining involvement of different objects of the system
while handling a particular use case. Class diagram or an object diagram
explains different objects involved in the system while activity diagram
explains step by step activities carried out in completion of an use case.
In an interaction diagram designer explains which objects from object
diagram are responsible for completion of an activity.
For example sequence diagram based on activity diagram explains how
different objects interact with each other to complete the activity.
and UML

NOTES
and Design
25
The table given below explains purpose of each diagram in brief –
and UML

NOTES
26
and Design
There is dependency between these diagrams and hence while designing
any system a flow of sequence need to be maintained. Always a system design
starts with Use Case Diagram which covers all major as well as minor
functionalities along with direct and indirect users. Depending on the use case
diagram Activity Diagrams are drawn which explains step-by-step execution of
activities in a single or a group of related use cases. Depending on use case
diagram and activity diagram designer goes for Class Diagram. With the help of
use case and activity diagram major functionalities are clear and hence now
designer can think of assignment of responsibility with reference to data and
functionalities. After defining classes the Object Diagram is the next in sequence,
which is similar to class diagram. Depending on Object diagram the next is the
State Transition Diagram, for explaining behaviour of an object in different
situations. Next comes is any one of interaction diagram, it may be Sequence
Diagram or Collaboration Diagram or Interaction Overview Diagram which
depends on activity diagram and class diagram or object diagram. With the
interaction diagrams most of the coding part gets cleared and hence the designer
starts thinking about Transition phase of RUP where next comes is Package
Diagram which depends on class diagram. Once the package diagram is ready
the idea for components of the system is clear and hence next comes is
Component Diagram and depending on it comes is Deployment Diagram. Here
the actions in Transition phase of RUP are covered and it ends with the
elaboration and construction phase is completed.
Advantages of UML
UML is a versatile visual language that is used to model a software system.
Though it was accepted widely by software industry still some were having
doubts for using it and were feeling it is not necessary to use this as designing
tool. Like every designing technique it has got its own advantages and
disadvantages. The section discusses the advantages and disadvantages of UML
as a designing tool.
and UML

NOTES
and Design
27
Advantages of UML –
• Most-Used designing tool
UML is a highly recognized and understood platform for software design.
It is a standard notation among software developers. It can be safely
assumed that most software professionals will be at least acquainted with,
if not well-versed in, UML diagrams, thus making it the go-to alternative
to explain software design models.
• Flexible
What makes UML well-suited to and much-needed for software
development is its flexibility. Designer can customize his modeling
elements and interactions in a UML diagram specifically to suit the
domain or technologies you are using.
• The Software Architecture Must Be Communicated Effectively
When a designer is working on any software he need to consider in his
each design. Which is not done by any other designing technique other
than UML. If the architecture of the software is not considered while
designing it, while implementation avoids effective use of architecture
of software. The software architecture is the blueprint of the system. It is
the framework on which the efficiency of the system and its processes
depend.
• Rich and Extensive Modeling Language
UML is a rich and extensive language that can be used to model not just
object- oriented software engineering, but application structure and
behaviour, and business processes too. Software players have agreed that
we cannot do away with documentation of the architecture. It is
important. It helps in assessing performance, security, tracking, and
provides important guidelines for the assignment under operation.
Because of its wide reach, UML is the perfect visual language to
communicate detailed information about the architecture to the largest
number of users.
• You Need to Know Only a Fraction of the Language to Use It
Though there are number of different types of UML diagrams for
modeling applications, developers use only three or four to document a
software system. Class diagrams, sequence diagrams, and use case
diagrams remain the most in vogue. What this implies is that only 20%
of the UML language knowledge can explain 80% of modeling.
• Abundance of UML Tools
Number of UML tools are so widely used which has made it more
popular. UML tools range from free open-source software to those Iterative Development
and UML

NOTES
28
and Design
costing millions of dollars. These tools cover much territory beyond just
drawing diagrams. They can generate code from the design, apply design
patterns, mine requirements, reverse engineer code, and perform impact
and complexity analysis.
Disadvantages of UML
Despite its myriad uses and benefits, UML is not preferred by all. In fact, a
considerable section of software developers, don’t use UML and heap heavy
criticism on the same. Let’s look at the arguments against using UML.
• Formal Notation is Not Necessary
Any UML diagram doesnot specify any hard and fast rule to be followed
while modeling the software. This characteristic adds flexibility to the
modeling. But the same has become disadvantage of UML. Instead of
communicating the diagrams formally, the same impact and effect can
be felt with informal, box-and-line diagrams created in PowerPoint,
Visio, or a whiteboard. As coding is a formal language by itself, a lot of
developers don’t prefer the complexity and the formality at the
architectural level, which discourages the use of UML and has become
one of its disadvantages.
• Ascending Degree of Complexity
Since its initiation until now, UML has grown in complexity and size.
The sheer size of UML makes a lot of people nervous right at the onset,
and they feel like they won’t be able to learn it, and are better off without
it.
• Not Necessary in ‘Architecture-Indifferent Design’
A term ‘Architecture-Indifferent Design’ was coined by George
Fairbanks, which is used to explain a situation where UML is considered
unnecessary.
At its core, an architecture-indifferent design refers to a software
architecture that is simple and basic, and does not need any complex diagrams
to represent or explain the design. If the firms lay more emphasis on formal
coding, and there is a prevalent culture of minimal design documentation, UML
is regarded unnecessary.
Though the UML is having these disadvantages, it has become a popular
designing tool and is accepted widely to make the designing process more
effective.
Behavioural Modeling
Always the inception phase ends with the collection of requirements and
finalizing the functional requirements, though not final with scope of changes.
Now the designer of system starts thinking of design of the system. In case of
and UML

NOTES
and Design
29
Object Oriented System the design has to consider two major aspects of the
system. One is the structural or static model and the other is behavioural or
dynamic model.
Here we are starting with the discussion on behavioural modeling of the
system. How effectively system can handle different situations when it is
running/operating is explained with the help of behavioural modeling.
Behavioural modeling helps in developing code for the system, as the coding
part is responsible for deciding reactions of the system. And therefore most of
the behavioural diagrams deals with the functionalities of the system. Effective
behavioural design helps in designing effective situation handling for the system.
There are number of UML diagrams which helps to design behaviour of the
system but the system design starts with Use Case Diagram and Activity
Diagram.
Use Case Diagram
In 1986, Ivar Jacobson first formulated textual and visual modeling
techniques for specifying use cases. In 1992 his co-authored book Object-
Oriented Software Engineering - A Use Case Driven Approach helped to
popularize the technique for capturing functional requirements, especially in
software development.
Use Case diagram comes under behavioural modeling. It is the diagram
from which designing of the system starts. Designing of the system starts in
inception phase itself and always it starts with use case diagram. It is the primary
form of system/software requirements for a new software program
underdeveloped. A key concept of use case modeling is that it helps us design a
system from the end user's perspective. It is an effective technique for
communicating system behaviour in the user's terms by specifying all externally
visible system behaviour.
The diagram is used to model the system/subsystem of an application. A
single use case diagram captures a particular functionality of a system. Use case
diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared.
Hence to model the entire system, a number of use case diagrams are used In
brief, the purposes of use case diagrams can be said to be as follows −
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.
Use case diagrams are considered for high level requirement analysis of a
system. When the requirements of a system are analyzed, the functionalities are
captured in use cases. Use cases specify the expected behaviour (what), and not
and UML

NOTES
30
and Design
the exact method of making it happen (how). Use cases once specified can be
denoted both textual and visual representation (i.e. use case diagram).
These internal and external agents are known as actors. Use case diagrams
consists of actors, use cases and their relationships. We can say that use cases
are nothing but the system functionalities written in an organized manner. The
second thing which is relevant to use cases are the actors. Actors can be defined
as something that interacts with the system.
Actors can be a human user, some internal applications, or may be some
external applications. When we are planning to draw a use case diagram, we
should have the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
The purpose of the use case diagram is –
• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts together with domain experts
Developing Use Case Diagram
• The name of a use case is very important. The name should be chosen in
such a way so that it can identify the functionalities performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main purpose of
the diagram is to identify the requirements.
• Use notes whenever required to clarify some important points.
Following is a sample use case diagram representing the order management
system. Hence, if we look into the diagram then we will find three use cases
(Order, SpecialOrder, and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use
case. Hence, they have extended relationship. Another important point is to
identify the system boundary, which is shown in the picture. The actor Customer
lies outside the system as it is an external user of the system.
and UML

NOTES
and Design
31
Fig 2.2 : Sample Use Case Diagram
I Realization of Use Cases
Identifying the Use Cases, and then the scenario-based elicitation process
carries on by asking what externally visible, observable value that each actor
desires. The following questions can be asked to identify use cases, once your
actors have been identified:
• What functions will the actor want from the system?
• Does the system store information? What actors will create, read, update
or delete this information?
• Does the system need to notify an actor about changes in the internal
state?
• Are there any external events the system must know about? What actor
informs the system of those events?
II Finding Actors
Next step after defining use cases is to find actors who initiates the use
cases. The following questions can help you identify the actors of the system:
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
and UML

NOTES
32
and Design
III Defining Relations among Use Cases
When it comes to drawing use case diagrams one area many struggles with
is showing various relationships in use case diagrams. There can be 5 relationship
types in a use case diagram.
• Association between actor and use case - This one is straightforward and
present in every use case diagram. Few things to note.
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.
Fig. 2.3 : Association relationship appears in use case diagrams
• Generalization of an actor – Generalization of an actor means that one
actor can inherit the role of the other actor. The descendant inherits all
the use cases of the ancestor. The descendant has one or more use cases
that are specific to that role. Let’s expand the previous use case diagram
to show the generalization of an actor.
Fig 2.4 : Generalization Relation Between Actors
and UML

NOTES
and Design
33
• Extend between two use cases - As the name implies it extends the base
use case and adds more functionality to the system. Here are a few things
to consider when using the <<extend>> relationship. The extending use
case is dependent on the extended (base) use case. In the below diagram
the “Calculate Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case. The extending use case is usually optional and
can be triggered conditionally. In the diagram, you can see that the
extending use case is triggered only for deposits over 10,000 or when the
age is over 55. The extended (base) use case must be meaningful on its
own. This means it should be independent and must not rely on the
behaviour of the extending use case. Lets expand our current example to
show the <<extend>> relationship.
Fig 2.5 : Extend relationship between use cases
Although extending use case is optional most of the time it is not a must.
An extending use case can have non-optional behaviour as well. This mostly
happens when your modeling complex behaviours.
For example, in an accounting system, one use case might be “Add Account
Ledger Entry”. This might have extending use cases “Add Tax Ledger Entry”
and “Add Payment Ledger Entry”. These are not optional but depend on the
account ledger entry. Also, they have their own specific behaviour to be modeled
as a separate use case.
Include between two use cases - Include relationship show that the
behaviour of the included use case is part of the including (base) use case. The
main reason for this is to reuse common actions across multiple use cases. In
some situations, this is done to simplify complex behaviours. Few things to
consider when using the <<include>> relationship.
• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.
and UML

NOTES
34
and Design
Lest expand our banking system use case diagram to show include
relationships as well.
Fig 2.6: Include relation between Use Cases
• Generalization of a use case - This is similar to the generalization of an
actor. The behaviour of the ancestor is inherited by the descendant. This
is used when there is common behaviour between two use cases and also
specialized behaviour specific to each use case.
For example, in the previous banking example, there might be a use case
called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by
Bank Balance” etc.
IV Writing Use Cases
For more explanation for the use case diagram a document is prepared
which is known as ‘Use Case Document’. This document is used as a part of
SRS (Software Requirement Specification), which is considered to be a crucial
document in the lifecycle of the software system. The use case document explains
each use case in detail along with its intiator actor, beneficiary actor, pre-
condition, post-condition, extension use cases etc. Following two images gives
explanation for the sample of use case document.
and UML

NOTES
and Design
35
Fig 2.7 : System Overview document
Source : https://www.researchgate.net/figure/System-Overview-
Document- template_fig3_3946201
The figure 2.7 gives the list of points to be covered while preparing system
overview document. As the name suggests the document takes overview of the
system, and along with the different specifications of the system, it also consists
of use case diagram for the system. This is the general report about the system
created after completion of major part of inception phase.
While the next figure fig 2.8 is the template for use case document.
and UML

NOTES
36
and Design
Fig 2.8 : Use Case Document Template
Source : https://www.researchgate.net/figure/Global-Use-Case-
Document- Template_fig4_3946201
It consists of all use case in the use case diagram given in the system
overview document. This document for each use case explains majorly following
points for each use case –
• Participating Actors – it gives the list of actors which are involved in the
use case execution. It consists of initiator, beneficiary, as well as actor
who are involved in the process. For example in the use case ‘Billing’,
clerk is the initiator who activates the use case, customer is beneficiary
who can buy the products at the end of use case, while barcode reader
and printer are actors who are involved in the completion of the use case.
• Flow of events – lists the sequence of events which will be carried out
right from the starting of the use case till the completion of use case. This
helps to explain the entire scenario to the stakeholders as well also helpful
in preparing other dependent diagrams like activity and sequence
diagram.
and UML

NOTES
and Design
37
• Precondition – for execution of every use case some preliminary
condition is to be satisfied before starting with use case, for example for
the use case ‘login to the system’ a precondition is accepting the user
name and password. These conditions are specified as precondition for
the execution of use case.
• Postcondition – after completion of execution of the use case some
condition to satisfy which is given as postcondition. For example, after
execution of login user’s credentials needs to be checked, is the
postcondition for use case.
Once the documents are prepared and signed by the client and the authority
from developing team the actual development process starts.
Activity Diagram
Activity diagram is another important diagram in UML to describe the
dynamic aspects of the system. Activity diagram is basically a flowchart to
represent the flow from one activity to another activity. The activity can be
described as an operation of the system. The control flow is drawn from one
operation to another. This flow can be sequential, branched, or concurrent.
Activity diagrams deal with all type of flow control by using different elements
such as fork, join, etc.
The basic purposes of activity diagrams is to capture the dynamic behaviour
of the system. Other four diagrams are used to show the message flow from one
object to another but activity diagram is used to show message flow from one
activity to another.
Activity is a particular operation of the system. Activity diagrams are not
only used for visualizing the dynamic nature of a system, but they are also used
to construct the executable system by using forward and reverse engineering
techniques. The only missing thing in the activity diagram is the message part.
It does not show any message flow from one activity to another. Activity
diagram is sometimes considered as the flowchart. Although the diagrams look
like a flowchart, they are not. It shows different flows such as parallel, branched,
concurrent, and single.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
Activity diagrams are mainly used as a flowchart that consists of activities
performed by the system. Activity diagrams are not exactly flowcharts as they
have some additional capabilities. These additional capabilities include
branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding
about the elements used in activity diagram. The main element of an activity
and UML

NOTES
38
and Design
diagram is the activity itself. An activity is a function performed by the system.
After identifying the activities, we need to understand how they are associated
with constraints and conditions.
Before drawing an activity diagram, we should identify the following
elements −
• Activities
• Association
• Conditions
• Constraints
Once the above-mentioned parameters are identified, we need to make a
mental layout of the entire flow. This mental layout is then transformed into an
activity diagram.
Following is an example of an activity diagram for order management
system. In the diagram, four activities are identified which are associated with
conditions. One important point should be clearly understood that an activity
diagram cannot be exactly matched with the code. The activity diagram is made
to understand the flow of activities and is mainly used by the business users
Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check
if it is normal or special order. After the type of order is identified, dispatch
activity is performed and that is marked as the termination of the process.
Fig 2.9 : Activity diagram for Order management System
Source :
https://www.tutorialspoint.com/uml/uml_activity_diagram.html
and UMLHamlet

NOTES
and Design
39
Following table explains various symbols used in activity diagram –
and UML

NOTES
40
and Design
In addition to these symbols one more symbol is used in activity diagrams
which is named as ‘Swimlanes’. When an activity is complex and either one or
both conditions exist in the activity then swimlanes are used to group related
activities into one column. It helps to simplify the activity diagram which makes
it easy to read. The conditions for using swimlanes are –
• Activity diagram consists of many minor activities, each is having its
own flow of activities
• In an activity many actors are involved who are responsible for
completion of some activities in major activity.
Fig 2.10 : Activity diagram for ‘Order Processing’ using swimlanes
Source : https://www.smartdraw.com/activity-diagram/
and UML

NOTES
and Design
41
The basic usage of activity diagram is similar to other four UML diagrams.
The specific usage is to model the control flow from one activity to another. This
control flow does not include messages.Activity diagram is suitable for modeling
the activity flow of the system. An application can have multiple systems.
Activity diagram also captures these systems and describes the flow from one
system to another. This specific usage is not available in other diagrams. These
systems can be database, external queues, or any other system.
An activity diagram is drawn from a very high level. So it gives high level
view of a system. This high level view is mainly for business users or any other
person who is not a technical person.
This diagram is used to model the activities which are nothing but business
requirements. The diagram has more impact on business understanding rather
than on implementation details.
Activity diagram can be used for −
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage
References
• https://en.wikipedia.org/wiki/Rational_Unified_Process
https://www.webopedia.com/TERM/R/RUP.html https://creately.com
/blog/diagrams/advantages-and-disadvantages-of-uml/
• https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what- is-use-case- diagram/
• https://creately.com/blog/diagrams/use-case-diagram-relationships/
language/what-is-activity- diagram/
• https://www.usability.gov/how-to-and-tools/methods/use-cases.html
*****
and UML

NOTES
42
UNIT NO - 3
BASIC AND ADVANCED
STRUCTURAL MODELING
Objectives of Chapter
To understand –
• What is structural modeling
• Finding and defining classes
• Relating classes
• What is state of an object and how to draw STD
• What is role of Object Diagram
• How to define packages and how to draw package diagram
Introduction
In this chapter, we are going to discuss various UML diagrams which are
to be dawn as an elaboration of the system. This chapter talks about preliminary
diagrams like class diagram, object diagram, package diagram, and state
transition diagram. These all are the basic diagrams of any object-oriented
diagram as they all deal with the basic programming construct of any object-
oriented system.
From these all diagrams, the class diagram is a crucial diagram which
defines the base structure for the system. Therefore class structure needs to be
designed very carefully and by considering all possibilities which help to make
the system more durable, easily upgradable, and efficient. The Object- Oriented
systems designed using the RUP process always insist on designing the
component- based system. In any Object-Oriented system class and collection
of classes (packages) form components. hence this chapter helps you to develop
your skills for designing the Object-Oriented system.
Class Diagram
The term class diagram is defined as ‘a diagrammatic representation of
classes and their relations for a specific system’. It is a structural diagram. The
class diagram forms structure of the system based on which the entire system
stands and works. So obviously it has to be strong enough. At the same time, the
structure should be designed in such a way that in future the system should be
easily upgradeable. Here the designer should concentrate not only on current
requirements but should also give a moment to think about future developments.
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
43
This makes the system more flexible and acceptable.
To start with the class diagram following sequence is to be followed –
1. Firstly try to find the objects which are playing a major role in the
system with respect to data storing and data processing.
2. With reference to these objects, roughly classes can be defined.
3. The last phase in this process is to define relations between classes,
which completes the design of the class diagram.
The following sub-sections discuss the process in detail.
Object Modeling
When we think of software, always it comes with some programming
language. But it is not only a collection of programs but it consists of many small
programming constructs which as a designer one needs to visualize. In any
object-oriented system, the smallest programming construct is a ‘class’. The
technical definition of a ‘class’ is given as ‘encapsulation of data and methods
processing data together as an abstract definition’. So when a designer starts
designing a class he has to think of data and methods processing data together.
Visualization and defining of classes in the system is a challenging task and is to
be done very carefully. With the help of ‘Object Modeling’, defining classes
becomes an easy task. The Object- Oriented Modeling (OOM) technique
visualizes things in an application by using model objects. In
In object-oriented software engineering, the software developer identifies
and organizes the application in terms of object-oriented concepts, prior to their
final representation in any specific programming language or software tools.
Identifying Classes and Objects
Once the use case diagram is ready, the designer gets idea about different
functionalities, defined as use cases, which will be carried out as a part of the
system. Now it is time to think about the data used by the system. From the use
case document, where events undertaken for the use case are listed, now it is
easy to list data that need to be stored and processed.
But this not only data which we should consider. In any object oriented
system the basic entity responsible for storing and processing data is an object.
Here we need to think of assigning the data and the use cases (methods or
functionalities) as responsibility to objects. Hence finding and defining classes
and objects is Assignment of responsibilities.
To start with the process of finding classes or objects, by going through
scenario list the objects and then go for detailing of these listed objects. While
listing the objects, always keep in mind that object is somewhat like an entity
for which we need to store and process data. These entities holds ‘nouns’ as
names. For finding the objects read the scenario carefully and find the entities
for which we need to store data.
Basic and Advanced
Structural Modeling

NOTES
44
In any OOP system objects are of three types –
• Entity objects -- these represent persistent information tracked by a
system. This is the closest parallel to "real world" objects.
• Boundary objects -- these represent interactions between user and system.
(For instance, a button, a form, a display) generally used while
developing User Interface for the system.
• Control objects -- usually set up to manage a given usage of the system.
Often represent the control of some activity performed by a system
These different types of objects also helps to find the objects. As here still
we are in system development state we concentrate only on two types of objects
namely entity objects and control objects. Preferably in the first iteration a
designer is able to find only majorly entity objects.
For example, in order management system, if we go through the scenario,
we need to store data for customer, order, product stock so these can be our three
objects.
After listing objects, there detailing is to be done. This detailing can be done
using two traditional and popular techniques can be used –
• Natural language analysis (i.e. parts of speech)
• CRC cards
It also helps to interact with domain experts -- these are people who are
already well-versed in the realm being studied. Note that here the goal is NOT
to find implementation specific objects, but to get rough idea about the objects
which participate in class diagram.
Natural language analysis was pioneered by Russell Abbott (1983),
popularized by Grady Booch. It is not the perfect technique but at least helps to
start with the process of finding objects. It emphases on mapping parts of speech
to object model components where nouns usually map to classes, objects, or
attributes and verbs usually map to operations or associations. Following table
explains how to work finding objects -
Table 3.1 : Natural Language processing for finding objects
Source : http://www.cs.fsu.edu/~myers/cop3331/notes/analysis1.html
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
45
CRC (Class Responsibility Collaborators) Cards is a simple object-oriented
analysis technique that includes the users and developers in the analysis process.
A CRC card is an index card with three parts:
• Class -- name goes at the top of the card
• Responsibilities -- as a list on the left side of the card
• Collaborators -- as a list on the right side of the card Here's the layout of
CRC card:
Table 3.2 : CRC Card
Source : http://www.cs.fsu.edu/~myers/cop3331/notes/analysis1.html
Following points explains each column and its details -
• Class
o Represents a type of object being modeled
o One card per class
• Responsibility
o Something that the class knows (keeps track of) or does
o These should be the high-level responsibilities. Not trying to list
out all member functions here
o Example: class Mailbox in a voice mail system might have these
responsibilities:
o keep new and saved messages
o manage the recorded greeting
• Collaborator
o Another class that the current class has to work with to complete
its responsibilities
o Could be a class that has information we need
o Could be a class that helps perform a task
o Typically, we list a class as a collaborator if we (the current class)
need to callupon it to help complete our own responsibilities
o Example: To successfully keep new and saved messages, the Basic and Advanced
Structural Modeling

NOTES
46
Mailbox class has to send them to a MessageQueue to be added
and stored. So on the Mailbox card, we list MessageQueue as a
collaborator
These CRC cards are designed by using brain storming technique where
different stakeholders participate in the process of adding items to each column
for each class. After creating CRC cards for each class, firstly responsibility
column is designed and then after completing responsibility column for all
classes, then collaborator column should be finalized.
Once the CRC cards are ready the designer is ready for the next step of
finalizing the definition of classes.
For example following CRC card is designed for class ‘order’ in ‘Order
Management System’
Table 3.3 : Sample of CRC Card for class ‘Order’
From the above CRC card for class ‘Order’, if we observe the column
responsibility the items with nouns specifies the attributes of an object while
attributes with verbs specifies operation that can be carried out by object. The
collaborator column helps to relate the class with other classes while going for
advanced class modeling.
Specifying the Attributes
Finalization of class definition starts with specifying attributes. Attributes
in any class ‘data’ as responsibility of the class. These attributes are nothing but
the member variables defined in the class. While specifying attributes, its
datatype and visibility is also considered.
For example, with reference to CRC card designed for class ‘Order’we can
define attributes for class ‘Order’ as orderId, custId etc. and can finalize their
data types and visibility. To finalize visibility we need to go for some more
iterations.
Defining Operations
After finalizing specification of attributes next step is to finalize operation
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
47
carried out by the class, actually by an object defined on the class. For defining
operations in addition to CRC cards use case diagram is also referred. Like
attributes these operations will also have datatype (return datatype), visibility
and one additional information that is arguments passed.
For example the class ‘Order’will have right now only three operations like
create, edit and cancel defined with proper arguments. Their arguments and
visibility will be finalized after certain iterations.
Finalizing the Object Definition
Once the attributes and operations are specified a step towards finalizing
the object in turn class definition is taken. Here every class diagrammatically is
represented using ‘detailed notation for class’. In detailed notations for each class
diagrammatically its attributes and methods are represented along with their
datatype and visibility.
Fig 3.1 : Detailed Notation for class
The above diagram shows diagrammatic representation for a detailed
notation of the class. Using such notation each class as per CRC card is designed
and represented with three compartments. These three compartments define three
parts of the class.
The first compartment represents class name. The class name is noun.
According to the naming conventions the class name always starts with capital
letter.
The second compartment represents attributes or data members. These data
members are assigned as responsibility to class towards the system. While
representing data members the syntax used is given as –
Object oriented programming languages allows user to add individual
visibilities to any member in the class. This visibility of the member decides who
and where the member can be accessed. Every OOP language provides three
types of visibilities – private, protected and public. The private members are
accessible within class, protected are accessible within class and within its
derived class while public are accessible within class as well as within its derived
class and outside the class using its object. While representing attributes in
detailed notations the access specifiers need to be mentioned. Access specifier Basic and Advanced
Structural Modeling

NOTES
48
in detailed notation is represented symbolically. The symbols used for access
specifier are given below -
+ : It denotes public access for the member.
- : It is private access.
# : It is protected access.
After access specifier next is the data member name. The data member name
should follow rules for variable names.
The datatype for the data member is given after colon ( : ) . The datatype
explains about the data hold by the member. Here datatype can be primitive or
derived or user defined (class). If the data type is user defined then only care
should be taken that the used datatype has been defined before use, this helps to
avoid confusion.
The third compartment describes methods from the class. Syntax for
specifying methods from class is given below –
Here method name is followed by list of argument datatypes which are
required for executing the functionality. The return datatype of the method is
considered as its datatype, which is given after colon (:).
Following diagram explains detailed notation for class with the example of
class ‘Order’.
Fig 3.2 : Detailed notation for class ‘Order’
Here detailing of class definition ends. Still these definitions are under
modification. The introduction of relations between classes tends to modification
in definition of classes as well as may add some new classes to the system.
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
49
Advanced Class Modeling (Relating Classes)
The next step towards designing structure of the system is considered as
advanced class modeling. Under advanced class modeling the relations between
classes is defined. These relations between classes helps to share system data
between them which is shared among them while defining classes. A class may
be involved in one or more relationships with other classes. Though relations
are defined within classes executed by the objects on the class.
There are three types of relations which can be defined within classes –
• Generalization Relation
• Association Relation
• Aggregation Relation
Following subsections explains these relations.
I Generalization Relation
The relation of Inheritance is represented as Generalization relation in UML.
It represents an "is-a" relationship. The concept of inheritance allows user to
reuse the attributes and methods from previously defined class. The previously
defined class is known as super class or base class, while the newly defined class
is known as sub class or derived class. Sub class derives private and public
characteristics from its super class. Diagrammatically generalization relation is
represented by connecting two classes with an hollow arrow. The arrow always
points to the super class. Following diagram represents pictorial representation
for generalization relation.
Fig 3.1 : Generalization Relation
For example,
Fig 3.2 : Generalization relation between class ‘Vehicle’ and class ‘Car’
Here as the class ‘Car’ shares characteristics of class ‘Vehicle’ and hence
both are related with generalization relation. The generalization relation exist
between classes.
II Association Relation
When to satisfy the demand of an use case or functionality if two classes
need to share minimum data then the association relation is used. It is the most
preferred relation in class diagram as it promotes minimum data sharing.
It is implemented through the concept of message passing. When two
classes are associated with each other to carry out the relation a method is added Basic and Advanced
Structural Modeling

NOTES
50
to the associated class. This method sends message to associated class to share
the required data. Hence the association relation exist between two objects.
Diagrammatically the association relation is represented with a thick line
connecting two classes. Following diagram explains representation of association
relation.
Fig 3.3 : Association Relation
Here classes ‘Class1’and ‘Class2’are said to be associated with each other.
For example,
Fig 3.3 : Association Relation between class ‘Customer’ and ‘Bill’
The figure 3.3 shows two classes ‘Customer’ and ‘Bill’ are associated with
each other. But from this diagram one cannot understand how to implement the
relation. Hence the association between these two can be made more explanatory
by adding something extra characteristics to this relation which is explained
below –
• Naming the relation – To add some more explanation to the relation we
can name these relations. These names are generally verbs which also
explains about the activity in which the relation will be used.
For example, figure 3.4 explains the relation between ‘Customer’and ‘Bill’
by adding names. Now it is clear that ‘Customer’ object pays ‘Bill’, while ‘Bill
is generated for ‘Customer’.
Generated for
Fig 3.4 : Named Association Relation between class
‘Customer’ and ‘Bill’
• Direction to the relation – Still, after adding names to the relation, we
need to understand in which direction the relation exist so that
accordingly message passing can be done. Hence here we can add
directions to the relation as shown below –
For example, adding arrows to the association adds more explanation to the
diagram which is shown in diagram 3.5.
Fig 3.5 : Directed Association Relation between class
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
51
• Multiplicity – It is the number which explains the number of objects
associated with each other which is shown with the following diagram.
Fig 3.5 : Association Relation with multiplicity between class
The diagram 3.5 explains the association in more detail after adding all
characteristics to it and can be read as –
One object of class ‘Customer’ can pays Bill and can be associated with 1
to any number of objects of ‘Bill’. While one object of ‘Bill’ is generated for a
single object of ‘Customer’.
III Aggregation Relation
It is special kind of association relation. The aggregation relation adds one
more responsibility to the associated class. In any OO system the major problem
is of creation of objects. When an activity needs the object for the class need to
be created first. The problem faced is - who will create the object?
The problem of creation of objects can be solved with the help of
aggregation relation. The responsibility of creation of object is assigned to the
associated class which is considered to be ‘whole class’.
There are two types of aggregation relation. This categories are based on
multiplicity from the direction of part class. These categories are explained as –
• Simple or shared aggregation – In shared a part class can be part of
more than one whole class object. It is explained with the help of
following diagram –
Fig 3.6 : Shared Aggregation between class
‘Employer’ and ‘PartTimeEmployee’
Here the ‘Employer’ is the whole class while ‘PartTimeEmployee’ is a part
class. Hence by using shared aggregation we ca assign the responsibility of
creation of object for class ‘PartTimeEmployee’.
The reason behind using ‘shared aggregation is the multiplicity of object
for class ‘PartTimeEmployee’ towards ‘Employer’ object is one to many. As he
is a part time employee he can work with more than one employee.
• Composite aggregation – In composite aggregation the multiplicity of
whole class is always one. In simple language, a part class object can be
associated with a single whole class object. It is denoted by filled
rhombus towards whole class.
Basic and Advanced
Structural Modeling

NOTES
52
The diagram 3.7 explains the composite aggregation relation.
Fig 3.7 : Composite Aggregation between class
‘Employer’ and ‘FullTimeEmployee’
Here in diagram ‘FullTimeEmployee’ is a part class while ‘Employer’ is
whole class. Here multiplicity of object of class ‘FullTimeEmployee’ towards
‘Employer’ class object is one as a full time employee can be associated with a
single employer, hence here we have used ‘composite aggregation relation.
As stated earlier, aggregation relation are special kind of association
relation. Hence all characteristics that is naming the relation, direction and
multiplicity can be used with aggregation relation to make it more explanatory.
Interface and Abstract Class
As discussed in OOP concepts, interface and abstract class are kind of class.
Both can be used for data abstraction and encapsulation, but cannot be
instantiated. As a programmer, we know how an interface or an abstract class is
defined, but as a designer we should know when we should define an abstract
class or an interface instead of defining a class.
• Abstract Class
An abstract class is a concept using which user can abstract his own
data type but cannot instantiate it. In simple language, objects cannot
be declared on an abstract class. Thus abstract class cannot be used for
storing any data, but only to define a data type.
Majorly abstract class is used through inheritance. Sometimes a
situation may occur where a designer wants to define some
characteristics or properties (as attributes) or roles (as methods), which
are to be commonly shared by two or more different classes. These
characteristics or roles can be encapsulated and abstracted as a user
defined data type using a ‘class’ and other classes in system can share
the same using the concept of inheritance. Thus the problem of
common characteristics has been solved, but one class, which is not
actually used by system has been defined and may be instantiated by
user (user can define objects on class and can use to store data). Now
the problem of designer is, the new class is requirement of design and
not system, and he want to stop user from instantiating the class. The
solution for the problem is to define the class as an abstract class.
Hence an abstract class can be used in following conditions, when user
need to –
• Abstract attributes which are to be commonly used by different
classes from system so that they will not vary in data type.
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
53
• Some behavior needs to be kept common through methods.
• Disadvantage of abstract class is it cannot be used in multiple
inheritance.
In class diagram using short hand notation the abstract class can be
represented as –
Here the keyword ‘abstract’ is written within curly brackets which at the
right end of the class name. The keyword ‘abstract’ helps to describe class as an
‘abstract class’.
• Interface
The other concept is of ‘interface’ which was introduced by newly
launched OOP languages. The concept of ‘interface’ helps to achieve
multiple inheritance. In multiple inheritance a sub-class is derived from
more than one super-classes. Multiple inheritance may face a problem
of creating multiple copies of attributes and hence the OOP languages
like java, php etc. comes with the concept of interface. Interface also
allows abstraction, but does not allow instantiation. And hence allows
multiple inheritance.
The other advantage of interface it keeps user free to implement.
Definition of interface consists of only signatures of methods, while
all defined methods are implemented by user. Hence depending on
demand of situation the user can define its own role.
When a system requires –
• Multiple inheritance
• There is a need to provide some common functionalities
• The user is to be kept free for implementation
In addition to any of these three conditions the necessary condition is - as
this is not requirement of system, but requirement of designer and so he does not
the class to be instantiated. Then here the better option than abstract class is an
‘interface’.
Diagrammatically the interface in class diagram using short hand notation
is represented as–
Like with abstract class, with an ‘interface’the keyword used is ‘interface’,
which helps to differentiate it from normal class. The symbol used with keyword
is called stereotypes which is used in UML diagrams to mention some added
characteristics.
Basic and Advanced
Structural Modeling

NOTES
54
Types and Roles of Classes
As discussed earlier while discussing ‘finding classes’there are three types
of classes that can be defined –
• Entity classes
• Boundry classes
• Controller classes
The boundry classes are defined while designing user interface for the
system. But we need to remember that these classes are associated with the
system classes.
The controller classes role is to control the activities taking place in the
system. These controller classes are added while developing class diagram.
One more type of class that is ‘Association Class’ which is added between
two associated classes. These classes are added when two classes need to share
data bt those donot want to directly share data with each other.
For example,
Fig 3.8 : Association class
Object Diagram
An object is defined as a runtime entity defined for a class. An object holds
data for attributes defined in a class and methods in the class adds behaviour to
object. So at design level the only difference between class and object is object
will have values for attributes in class.
After completing class diagram a designer goes for object diagram, which
is based on class diagram. Same relations as in class exist between objects on
class. Actually object diagram is also known as instance diagram and represents
runtime existence of relations between objects at an instance of time.
Now the question is, if both class and object diagram are same, then why
and when one should go for object diagram? What is the purpose of object
diagram? The same is explained by object diagram as by class diagram. But as
object represents the relation at particular instance of time it becomes more
concrete in nature.
The association relation between two objects is the relation between two
objects and shares some data between two objects. This data sharing takes place
only if the object receives request from the other. Sending and receiving requests
from object takes place at particular instance of time and in particular situation.
Here situation defines a scenario. Passing and receiving of request is response
of system to the situation, also defined as behaviour of system. This cannot be
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
55
observed in class diagram as it is static in nature and cannot represent such
runtime situations. So as a conclusion object diagram is drawn to understand
runtime relation between objects. To summarize object diagram helps in -
• Forward and reverse engineering.
• Object relationships of a system
• Static view of an interaction.
• Understand object behaviour and their relationship from practical
perspective
We have already discussed that an object diagram is an instance of a class
diagram. It implies that an object diagram consists of instances of things used in
a class diagram.
So both diagrams are made of same basic elements but in different form. In
class diagram elements are in abstract form to represent the blue print and in
object diagram the elements are in concrete form to represent the real world
object.
To capture a particular system, numbers of class diagrams are limited.
However, if we consider object diagrams then we can have unlimited number of
instances, which are unique in nature. Only those instances are considered, which
have an 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 the objects of a
system. Hence, the solution is −
• First, analyze the system and decide which instances have important data
and association.
• Second, consider only those instances, which will cover the functionality.
• Third, make some optimization as the number of instances are unlimited.
Before drawing an object diagram, the following things should be
remembered and understood clearly−
• 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.
After this, the following things are to be decided before starting the
construction of the diagram −
• The object diagram should have a meaningful name to indicate its
purpose.
• The most important elements are to be identified.
• The association among objects should be clarified.
Basic and Advanced
Structural Modeling

NOTES
56
• Values of different elements need to be captured to include in the object
diagram.
• Add proper notes at points where more clarity is required.
The following diagram is an example of an object diagram. It represents
the Order management system.
Fig 3.9 : Object Diagram for ‘Order Management System’
State Chart Diagram
The behavior of an entity is not only a direct consequence of its inputs, but
it also depends on its preceding state. UML State Machine Diagrams (or
sometimes referred to as state diagram, state machine or state chart) show the
different states of an entity. State machine diagrams can also show how an entity
responds to various events by changing from one state to another. State machine
diagram is a UML diagram used to model the dynamic nature of a system.
State machine diagram typically are used to describe state-dependent
behavior for an object. An object responds differently to the same event
depending on what state it is in. State machine diagrams are usually applied to
objects but can be applied to any element that has behavior to other entities such
as: actors, use cases, methods, subsystems systems and etc. and they are typically
used in conjunction with interaction diagrams (usually sequence diagrams).
For example
Consider you have $100,000 in a bank account. The behavior of the
withdraw function would be: balance := balance - withdrawAmount; provided
that the balance after the withdrawal is not less than $0; this is true regardless of
how many times you have withdrawn money from the bank. In such situations,
the withdrawals do not affect the abstraction of the attribute values, and hence
the gross behavior of the object remains unchanged.
However, if the account balance would become negative after a withdrawal,
the behavior of the withdraw function would be quite different. This is because
the state of the bank account is changed from positive to negative; in technical
jargon, a transition from the positive state to the negative state is fired.
The abstraction of the attribute value is a property of the system, rather than
a globally applicable rule. For example, if the bank changes the business rule to
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
57
allow the bank balance to be overdrawn by 2000 dollars, the state of the bank
account will be redefined with condition that the balance after withdrawal must
not be less than $2000 in deficit.
Note That
• A state machine diagram describes all events (and states and transitions
for a single object)
• A sequence diagram describes the events for a single interaction across
all objectsinvolved Basic Concepts of State Machine Diagram
Characteristics of State Machine Notations are -
There are several characteristics of states in general, regardless of their
types:
• A state occupies an interval of time.
• A state is often associated with an abstraction of attribute values of an
entity satisfying some condition(s).
• An entity changes its state not only as a direct consequence of the current
input, but it is also dependent on some past history of its inputs.
Notations used in STD are explaind here.
• State -
A state is a constraint or a situation in the life cycle of an object, in which
a constraint holds, the object executes an activity or waits for an event.
A state machine diagram is a graph consisting of:
• States (simple states or composite states)
• State transitions connecting the states For Example:
Fig 3.9 : State Transition Diagram
Characteristics of State are given as -
• State represent the conditions of objects at certain points in time.
• Objects (or Systems) can be viewed as moving from state to state
• A point in the lifecycle of a model element that satisfies some condition,
where some particular action is being performed or where some event is
waited
Basic and Advanced
Structural Modeling

NOTES
58
Initial and Final States
The initial state of a state machine diagram, known as an initial pseudo-
state, is indicated with a solid circle. A transition from this state will show the
first real state.
The final state of a state machine diagram is shown as concentric circles.
An open loop state machine represents an object that may terminate before the
system terminates, while a closed loop state machine diagram does not have a
final state; if it is the case, then the object lives until the entire system terminates.
For Example:
Fig 3.10 : Initial state and final state in STD
Events
An event signature is described as Event-name (comma-separated-
parameter-list). Events appear in the internal transition compartment of a state
or on a transition between states. An event may be one of four types:
1. Signal event - corresponding to the arrival of an asynchronous message
or signal
2. Call event - corresponding to the arrival of a procedural call to an
operation
3. Time event - a time event occurs after a specified time has elapsed
4. Change event - a change event occurs whenever a specified condition
is met Characteristics of Events are given as –
• Represents incidents that cause objects to transition from one
state to another.
• Internal or External Events trigger some activity that changes the
state of the system and of some of its parts
• Events pass information, which is elaborated by Objects
operations. Objects realize Events
• Design involves examining events in a state machine diagram
and considering how those events will be supported by system
objects
Transition
Transition lines depict the movement from one state to another. Each
transition line is labeled with the event that causes the transition. Viewing a
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
59
system as a set of states and transitions between states is very useful for
describing complex behaviors. Understanding state transitions is part of system
analysis and design and a Transition is the movement from one state to another
state. Transitions between states occur as follows:
1. An element is in a source state
2. An event occurs
3. An action is performed
4. The element enters a target state
Multiple transitions occur either when different events result in a state
terminating or when there are guard conditions on the transitions. A transition
without an event and action is known as automatic transitions.
Actions
Action is an executable atomic computation, which includes operation calls,
the creation or destruction of another object, or the sending of a signal to an
object. An action is associated with transitions and during which an action is not
interruptible - e.g., entry, exit
Activity
Activity is associated with states, which is a non-atomic or ongoing
computation.Activity may run to completion or continue indefinitely.AnActivity
will be terminated by an event that causes a transition from the state in which
the activity is defined.
Characteristics of Action and Activities are stated as –
• States can trigger actions
• States can have a second compartment that contains actions or activities
performed while an entity is in a given state
• An action is an atomic execution and therefore completes without
interruption
• Five triggers for actions: On Entry, Do, On Event, On Exit, and Include
• An activity captures complex behavior that may run for a long duration
- An activity may be interrupted by events, in which case it does not
complete occur when an object arrives in a state.
A Simple State Machine Diagram using all above discussed notations
can be given as -
Fig 3.11 : STD for payment
Basic and Advanced
Structural Modeling

NOTES
60
The above diagram explains the STD for payment object with two states
‘unpaid’ and ‘paid’, while ‘invoice created’, ‘paying’ and invoice destroyed’ are
the activities responsible for transition of states.
Entry and Exit Actions
Entry and Exit actions specified in the state. It must be true for every entry
/ exit occurrence. If not, then you must use actions on the individual transition
arcs
• Entry Action executed on entry into state with the notation: Entry / action
• Exit Action executed on exit from state with the notation: Exit / action
Substates
A simple state is one which has no substructure. A state which has substates
(nested states) is called a composite state. Substates may be nested to any level.
A nested state machine may have at most one initial state and one final state.
Substates are used to simplify complex flat state machines by showing that some
states are only possible within a particular context (the enclosing state).
Substate Example - Heater
Fig 3.12 : STD with substate
Concurrent State
As mentioned above, states in state machine diagrams can be nested.
Related states can be grouped together into a single composite state. Nesting
states inside others is necessary when an activity involves concurrent sub-
activities. The following state machine diagram models an auction with two
concurrent substates: processing the bid and authorizing the payment limit.
Concurrent State Machine Diagram Example - Auction Process
In this example, the state machine first entering the Auction requires a fork
at the start into two separate start threads. Each substate has an exit state to mark
the end of the thread. Unless there is an abnormal exit (Canceled or Rejected),
the exit from the composite state occurs when both substates have exited.
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
61
Fig 3.13 : STD with concurrent states
Package Diagram
Package diagram, a kind of structural diagram, shows the arrangement and
organization of model elements in middle to large scale project. Package diagram
can show both structure and dependencies between sub-systems or modules,
showing different views of a system, for example, as multi-layered (aka multi-
tiered) application - multi-layered application model.
Package diagrams are used to structure high level system elements.
Packages are used for organizing large system which contains diagrams,
documents and other key deliverables.
• Package Diagram can be used to simplify complex class diagrams, it can
group classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any of the UML
diagrams.
Package diagram is used to simplify complex class diagrams, where classes
are grouped into packages. A package is a collection of logically related UML
elements.
The diagram below is a business model in which the classes are grouped
into packages:
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly
force changes in the first.
Basic and Advanced
Structural Modeling

NOTES
62
Fig 3.1 : Package Diagram for an online business
Source : https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/what-is- package- diagram/
Package diagram follows hierarchal structure of nested packages. Atomic
module for nested package are usually class diagrams. There are few constraints
while using package diagrams, they are as follows.
• Package name should not be the same for a system, however classes
inside different packages could have the same name.
• Packages can include whole diagrams, name of components alone or no
components at all.
• Fully qualified name of a package has the following syntax.
For example, the figure 3.2 explains how for nested package the package
name can be described –
Fig 3.2 : Representing Nested Package
For example in java the ‘date’ package is defined within ‘util’ package
which again comes in package ‘java’, whose diagrammatical representation is
shown in figure 3.2 -
Fig 3.3 : Representing ‘date’ as nested package
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
63
Nested Packages can also be represented by the notations with some
examples shown below:
Fig 3.4 : other Diagrammatic representation for
‘date’ as nested package
Upto the point the discussion was about representing an individual package.
But in the system there may be number of packages which work together. This
is defined as dependency between packages. There are two sub-types involved
in dependency. They are <<import>> &
<<access>>. Though there are two stereotypes users can use their own
stereotype to represent the type of dependency between two packages. Following
two diagrams explains these two types of dependencies between two packages –
The figure 3.5 shows the <<import>> dependency where ‘package 2’
imports ‘package 1’. This avails all class definitions from ‘package 1’ either for
object definition or extending the class.
Fig 3.5 : ‘import’ dependency between two packages
modeling-language/what-is-package- diagram/
While the figure 3.6 shows the <<access>> dependency between ‘package
2’ and ‘package 1’. This dependency allows to access certain functionality or
data only for particular usage but does not allow to use class for object definition
or extending it.
Basic and Advanced
Structural Modeling

NOTES
64
Fig 3.6 : ‘access’ dependency between two packages
For designing package diagram for nay system the steps can be defined as
• Identify classes from class diagram with similar functionalities or
participating in related use cases.
• Group the classes and form a package.
• Define all required packages.
• Find dependencies and type of dependencies between packages.
• Show all classes with their dependencies which forms the package
diagram for the entire system.
Here designing process for package diagram can be explained with the
example. The package diagram is to be designed for "Track Order" scenario for
an online shopping store. Track Order module is responsible for providing
tracking information for the products ordered by customers. Customer types in
the tracking serial number, Track Order modules refers the system and updates
the current shipping status to the customer. The next explanation explains steps
for designing package diagram for ‘Order subsystem’.
• Identify the packages of the system - Based on the project Description
first identify the packages in the system and then related them together
according to the relationship:
• There is a track order module, it has to talk with other module to know
about the order details, let us call it "Order Details".
• Next after fetching Order Details it has to know about shipping details,
let us call that as "Shipping".
Fig 3.7 : Identify packages in the subsystem
modeling-language/what- is-package- diagram/
• Identify the dependencies in the System
• Track order should get order details from "Order Details" and "Order
Details" has to know the tracking info given by the customer. Two
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
65
modules are accessing each other which suffices <<access>> dual
dependency
Fig 3.8 : Identifying dependency between packages in the subsystem
• To know shipping information, "Shipping" can import "Track Order" to
make the navigation easier.
• Finally, Track Order dependency to UI Framework is also mapped which
completes our Package Diagram for Order Processing subsystem.
Basic and Advanced
Structural Modeling

NOTES
66
Thus for a subsystem a package diagram can be can be defined as shown in
figure 3.2 –
Fig 3.11 : Package diagram for subsystem
modeling-language/what-is-package- diagram/
Here we can observe that it defines and explains the structure of the system.
The package diagram is useful and referred for designing component diagram
and deployment diagram. Hence it takes one step ahead towards finalizing
structure for the system.
and Design
Basic and Advanced
Structural Modeling

NOTES
and Design
67
References
language/what-is-class-diagram/
language/what-is-state-machine- diagram/
language/what-is-package- diagram/
*****
Basic and Advanced
Structural Modeling

NOTES
68
UNIT NO - IV
INTERACTION MODELLING
To understand
• Role of interaction modeling in construction phase
• How to draw Collaboration diagram
• How to draw Sequence diagram
Introduction
The use case diagram and activity diagram are two behavioral diagrams
which were covered in chapter two. Each use case in Use case diagram represents
reactions or functionality of the system while activity diagram explains each use
case step by step. These are the processes carried out as a part of each
functionality.
The class diagrams and other diagrams based on the class diagram, like state
transition diagram and package diagram which comes under the structural
category. The classes forms basic structure of the software system. The class
diagram, along with classes, also shows relations among objects to explain how
data is shared among them through interacting with each other. The interaction
between objects takes place only if required or demand of any functionality.
Now a designer and a developer need to understand participation of different
objects in different functionalities. For the purpose the designer can refer to two
diagrams class or object diagram and activity diagram to find the objects
participating in the functionality. The participating objects shares data with each
other as per the requirement of the functionality by interacting with each other.
The diagrammatic representation of interaction of objects is known as interaction
diagram. The interaction diagram also explains the sequence of interaction. In
UML three interaction diagrams can be used – namely sequence diagram,
collaboration diagram and interaction overview diagram. Any one of these three
can be used for representing the interaction for different functionalities.
Interaction Diagrams
It is a third category of UML diagrams under which there are three
diagrams. These interaction diagrams previously were considered under
behavioural category. So originally these diagrams were behavioural diagrams.
The behavioural diagrams explains behaviour of the system. Though these
diagrams were considered as behavioural diagrams, they does not directly deals
and Design
Interaction
Modelling

NOTES
and Design
69
with coding reactions of the system like other behavioural diagrams does. The
basic idea behind interaction diagrams is to explain interaction between objects,
and therefore in recent versions of UML a new category of diagrams was added
as ‘Interaction Diagrams’.
Design of any system starts with use case diagram and activity diagram.
These two diagrams explains behaviour or reactions of system while handling
different situations. The next diagrams are class diagram and object diagram,
which explains structure of the system. The next challenge for a designer is to
explain role of objects in completion of the activity, as objects are the only entities
in any object oriented system to complete any activity. Interaction diagrams are
based on two diagrams- class diagram and activity diagram. These two diagrams
need to be referred while going for any type of interaction diagram.
Need of Interaction Diagrams
The purpose of interaction diagrams is to visualize the interactive behaviour
of the system. Visualizing the interaction is a difficult task. Hence, the solution
is to use different types of models to capture the different aspects of the
interaction.
The purpose of interaction diagrams is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.
Types of Interaction Diagrams
In UML there are three types of interaction diagrams available. From these
three diagrams any one of them can be used for designing the interaction for the
system. Interaction diagrams used in UML are as below –
• Collaboration Diagram
• Sequence Diagram
Interaction Overview Diagram
All three explains the interaction system in similar way with some minor
changes in diagrammatic representation. Any diagram can easily replace the
other. Subsections below discusses one by one interaction diagram.
Collaboration Diagram
Collaboration diagrams also known as Communication Diagram in UML
2.x. As stated above it comes under the category of interaction diagrams. The
word collaboration itself explains the diagram as ‘the action of working with
other objects to complete the activity’. It represents diagrammatically the
sequence of communication taking place among number of objects from the
Interaction
Modelling

NOTES
70
system while completing a particular use case. Following are points which help
to understand collaboration diagram –
• A Collaboration is a collection of named objects and actors with links
connecting them. They collaborate in performing some task.
• A Collaboration defines a set of participants and relationships that are
meaningful for a given set of purposes
• A Collaboration between objects working together provides emergent
desirable functionalities in Object-Oriented systems
• Each object (responsibility) partially supports emergent functionalities
• Objects are able to produce (usable) high-level functionalities by working
together
• Objects collaborate by communicating (passing messages) with one
another in order to work together
So, here are some use cases that we want to create a collaboration
diagram for:
• Model collaborations between objects or roles that deliver the
functionalities of use cases and operations
• Model mechanisms within the architectural design of the system
• Capture interactions that show the messages passing between objects and
roles within the collaboration
• Model alternative scenarios within use cases or operations that involve
the collaboration of different objects and interactions
• Support the identification of objects (hence classes) that participate in
use cases
• Each message in a collaboration diagram has a sequence number.
• The top-level message is numbered 1. Messages sent during the same
call have the same decimal prefix but suffixes of 1, 2, etc. according to
when they occur.
Following table 4.1 explains different symbols used in collaboration
diagram.
and Design
Interaction
Modelling

NOTES
and Design
71
Table 4.1: Collaboration Diagram Notations
The above symbols are used in drawing collaboration diagram. While
drawing collaboration diagram following steps can be followed –
1. Identify behavior whose realization and implementation is specified
2. Identify the structural elements (class roles, objects, subsystems)
necessary to carry out the functionality of the collaboration
• Decide on the context of interaction: system, subsystem, use case
and operation
3. Model structural relationships between those elements to produce a
diagram showing the context of the interaction
4. Consider the alternative scenarios that may be required
• Draw instance level collaboration diagrams, if required.
• Optionally draw a specification level collaboration diagram to
summarize the alternative scenarios in the instance level sequence
diagrams
Interaction
Modelling

NOTES
72
Fig. 4.1 : Collaboration diagram for an activity
‘product order and query management’
Source:
https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_um
l_behavioural_diagrams.html
The above diagram represents collaboration diagram for ‘product order and
query management’ system. The diagram shows nine interactions taking place
between five objects while completing the activity. The activity is initiated by
customer object while ends with manager for handling query. Each process is
numbered here to explain the flow of processes carried out during activity. Here
the rectangles represent objects and links between objects connects two objects
which can communicate with each other by message passing.
Because of the format of the collaboration diagram, they tend to better suited
for analysis activities. Specifically, they tend to be better suited to depicting
simpler interactions of smaller numbers of objects. However, if the number of
objects and messages grows, the diagram becomes increasingly hard to read. In
addition, it is difficult to show additional descriptive information such as timing,
decision points, or other unstructured information that can be easily added to the
notes in a sequence diagram. The next subsection discusses about the sequence
diagram.
Sequence Diagram
A sequence diagram is the most commonly used UML interaction diagram.
A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place. Sequence diagrams
describe how and in what order the objects in a system function. These diagrams
are widely used by businessmen and software developers to document and
understand requirements for new and existing systems.
It is the popular interaction diagram as it considers objects, its lifetime,
activation, message passing and much more aspects of interaction. Moreover
these are easy to understand as the arrangement of symbols is done so that at a
first glance any business person can understand how the interaction takes place.
The symbols used in sequence diagram are explained below while explaining
and Design
Interaction
Modelling

NOTES
and Design
73
notations for the diagram. In addition to these notations sequence diagram
provides a group of symbols which can handle different situations which can be
faced during interaction while completing the activity.
Following are uses of sequence diagrams, which explains how sequence
diagram can help in construction of the system –
• Used to model and visualise the logic behind a sophisticated function,
use case or procedure.
• They are also used to show details of UML use case diagrams.
• Used to understand the detailed functionality of current or future systems.
• Visualise how messages and tasks move between objects or components
in a system. Sequence Diagrams captures:
• the interaction that takes place in a collaboration that either realizes a use
case or an operation (instance diagrams or generic diagrams)
• high-level interactions between user of the system and the system,
between the system and other systems, or between subsystems
(sometimes known as system sequence diagrams)
• Model high-level interaction between active objects in a system
• Model the interaction between object instances within a collaboration
that realizes a use case
• Model the interaction between objects within a collaboration that realizes
an operation
• Either model generic interactions (showing all possible paths through the
interaction) or specific instances of a interaction (showing just one path
through the interaction)
Sequence Diagrams show elements as they interact over time and they are
organized according to object (horizontally) and time and lifeline (vertically),
hence the sequence diagram is drawn considering two axis, X-axis to represent
objects while the time and lifeline of objects on Y-axis. Firstly we will see
notations used in sequence diagram which are explained in table 4.2.
Interaction
Modelling

NOTES
74
and Design
Interaction
Modelling

NOTES
and Design
75
Table 4.2 : Sequence Diagram Notations
Using the above notations following diagram 4.2 explains how a sequence
diagram is drawn. To draw a simple sequence diagram following steps can be
followed –
• The entire sequence diagram is enclosed within a rectangle which
explains its scope.
• The rectangle is given heading in upper left corner. The heading starts
with the abbreviation of sequence diagram as ‘sd’ and followed by the
activity name.
Interaction
Modelling

NOTES
76
• The diagram starts on upper x-axis. To start with diagram firstly list all
involved objects on x-axis sequentially from left to right as they
participate in the activity.
• The vertical y-axis represents time proceedings (or progressing) down
the page. Here though we are saying time is all about ordering, not
duration. The lifeline is shown vertically on y-axis. The lifeline for each
object represents that the object is ready or created previously but not
being used.
• The very first object on x-axis is activated first, which is represented by
vertical rectangle. The height of vertical rectangle represents activation
period.
• The activated object sends message to the next object in the list. The
message passing is represented with horizontal line which is headed with
the functionality name from class used for sending messages.
• After receiving message from previous object, the object is activated. If
in case the object wants to send acknowledgement to the sending object,
it passes message to the previous object in opposite direction. It is the
first message send by receiving object.
• After activation it sends message to the next object in the list and the next
object is activated.
In complex activities where more decisions are to be taken and accordingly
activity is executed, or in some situation a particular activity is executed
iteratively. In such activities the sequence diagram can have different fragments.
The fragment operator was introduced in UML 2.0 which shown in diagram 4.2.
Fig 4.2 : Fragment operator in Sequence diagram
Sequence fragments make it easier to create and maintain accurate sequence
diagrams. A sequence fragment is represented as a box, called a combined
fragment, which encloses a portion of the interactions within a sequence diagram.
The fragment operator (in the top left cornet) indicates the type of fragment like
ref, assert, loop, break, alt, opt, neg. All fragment types are explained in table
4.3, which will explain various situations faced in activity diagram can be
handled with the help of fragment operator.
and Design
Interaction
Modelling

NOTES
and Design
77
Table 4.3 : Sequence Fragment Operators
The diagram 4.2 represents sequence diagram for ‘order management
system’. The heading of the diagram is ‘sd order management system’. On X-
axis we have four objects for ‘Order’, two objects for ‘Distributor’ which are
characterized as ‘careful’ and ‘regular’ and the fourth object for ‘Messanger’,
and has used loop, alt and opt as fragment opeartors.
Fig 4.3 : Sequence diagram for Order Management System
References
• https://www.geeksforgeeks.org/unified-modeling-language-uml-
sequence-diagrams/
*****
Interaction
Modelling

NOTES
78
UNIT NO - V
ARCHITECTURAL MODELLING
To understand
• What is architecture of the System
• What is role of component Diagram in the system design
• How to draw component diagram
• What is role of deployment Diagram in the system deployment
• How to draw Deployment Diagram
Introduction
The word ‘architecture’ is widely used in construction business, which
defines ‘the art or practice of designing and building structures and especially
habitable ones’. Now a days after development of new types of software it is also
being used in ‘computer field’ also. In the field of ‘Information Technology’ its
meaning is ‘the manner in which the components of a computer or computer
system are organized and integrated’. When we are talking about the architecture
of any Information System, it refers both – Hardware as well as software. While
designing any software system, the designer need to pay attention towards
hardware components and software components separately.
The chapter discusses two different types of diagrams which deals with
Software architecture and hardware architecture. The first is the ‘component
diagram’, which represents different components of the software and
relationships or connections between these components. While the other diagram
is the ‘deployment diagram’, which explains different hardware components
being used by the software while accomplishing the tasks assigned to software
and their relationships.
Architectural Modelling
Software architecture refers to the fundamental structures of a software
system, which comprises software elements, relations among them, and
properties of both, elements and relations. By the time of developing various
types of software architecture has been introduced which satisfies different
requirements of the client. These types of software architecture have been
discussed in the 5.3.3 subsection.
and Design
Architectural
Modelling

NOTES
and Design
79
With other software design, the designer also needs to give a thought for
Software architecture. Along with the software artifacts, a designer plans about
arrangement and connectivity of these software artifacts and accordingly the
relations between components is defined. This has to be done in design phase
only, as it keeps him free for fundamental structural choices. In later stages if the
changes are to be implemented then it adds to the cost of the project. According
to the need of the system the design of architecture may change. For example,
for the system which are more data centric then a dedicated data server need to
be used and at the same time designer should be able to visualize the growth rate
of data. In case the data growth rate is high, to manage this big data according
architecture should be considered while in design phase. Similarly some systems
may be distributed systems or may be real time systems, accordingly architecture
for those should be designed.
Advantages of documenting software architecture can be given as –
• Facilitates communication between stakeholders,
• Captures early decisions about the high-level design,
• Allows reuse of design components between projects.
Any real-world system is used by different users. The users can be
developers, testers, business people, analysts, and many more. Hence, before
designing a system, the architecture is made with different perspectives in mind.
The most important part is to visualize the system from the perspective of
different viewers. The better we understand the better we can build the system.
Component Diagram
Before understanding Component diagram we need to understand what do
we understand with the ‘software component’. A ‘software component’ is a
modular, portable, replaceable, and reusable set of well-defined functionality that
encapsulates its implementation and exporting it as a higher- level interface. It is
a collection of software artifacts like a software package, a web service, a web
resource, or a module that encapsulates a set of related functions (or data). For
example,
• A package in ‘hospital management system’which consists of all classes
dealing with GUI (Graphical User Interface) can be called as ‘a GUI
component’ in Hospital Management System.
• A group of packages like ‘ICU patients’, ‘Ward’, ‘Bill’ which deals with
‘ICU Patients’ can be defined as ‘ICU Component’ in Hospital
Management System.
• A web service added for online payment forms a component
A ‘component diagram’ represents components in the system and their
relationships with each other. Technically a ‘component diagram’can be defined
as ‘an architectural diagram which focuses on the decomposition of the design
into individual functional or logical components’. Along with components the
Architectural
Modelling

NOTES
80
diagram also represents well-defined communication interfaces containing
methods, events, and properties. It provides a higher level of abstraction and
divides the problem into sub- problems, each associated with component
partitions.
The primary objective of component-based architecture is to ensure
component reusability. A component encapsulates functionality and behaviours
of a software element into a reusable and self- deployable binary unit. There are
many standard component frameworks such as COM/DCOM, JavaBean, EJB,
CORBA, .NET, web services, and grid services. These technologies are widely
used in local desktop GUI application design such as graphic JavaBean
components, MS ActiveX components, and COM components which can be
reused by simply drag and drop operation.
Component-oriented software design has many advantages over the
traditional object-oriented approaches such as −
• Reduced time in market and the development cost by reusing existing
components.
• Increased reliability with the reuse of the existing components.
• Components are designed to operate in different environments and
contexts.
• A component can be extended from existing components to provide new
behaviour.
• A component depicts the interfaces, which allow the caller to use its
functionality, and do not expose details of the internal processes or any
internal variables or state.
• Components are designed to have minimal dependencies on other
components.
Following subsections discusses need and process for developing
component diagram for the system.
Need of Component Diagram
Component diagram does not describe the functionality of the system but
it describes the components used to make those functionalities. Thus from that
point of view, component diagrams are used to visualize the physical components
in a system. These components are libraries, packages, files, etc. Component
diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular
moment. A single component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
and Design
Architectural
Modelling

NOTES
and Design
81
The purpose of the component diagram can be summarized as −
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
The purpose of this diagram is different. Component diagrams are used
during the implementation phase of an application. However, it is prepared well
in advance to visualize the implementation details. These diagrams show the
physical components of a system. To clarify it, we can say that component
diagrams describe the organization of the components in a system. Organization
can be further described as the location of the components in a system. These
components are organized in a special way to meet the system requirements. As
we have already discussed, those components are libraries, files, executables,
etc. Before implementing the application, these components are to be organized.
This component organization is also designed separately as a part of project
execution. Component diagrams are very important from implementation
perspective. Thus, the implementation team of an application should have a
proper knowledge of the component details
Component diagrams can be used to −
• Model the components of a system.
• Model the database schema.
• Model the executables of an application.
• Model the system's source code.
Advantages of component diagram can be stated as-
• Ease of deployment − As new compatible versions become available, it
is easier to replace existing versions with no impact on the other
components or the system as a whole.
• Reduced cost − The use of third-party components allows you to spread
the cost of development and maintenance.
• Ease of development − Components implement well-known interfaces
to provide defined functionality, allowing development without
impacting other parts of the system.
• Reusable − The use of reusable components means that they can be used
to spread the development and maintenance cost across several
applications or systems.
• Modification of technical complexity − A component modifies the
complexity through the use of a component container and its services.
• Reliability − The overall system reliability increases since the reliability
of each individual component enhances the reliability of the whole
system via reuse. Architectural
Modelling

NOTES
82
• System maintenance and evolution − Easy to change and update the
implementation without affecting the rest of the system.
• Independent − Independency and flexible connectivity of components.
Independent development of components by different group in parallel.
Productivity for the software development and future software
development.
Realization of Components
Recognizes all design classes that correspond to the problem domain as
defined in the analysis model and architectural model.
• Recognizes all design classes that correspond to the infrastructure
domain.
• Describes all design classes that are not acquired as reusable components,
and specifies message details.
• Identifies appropriate interfaces for each component and elaborates
attributes and defines data types and data structures required to
implement them.
• Describes processing flow within each operation in detail by means of
pseudo code or UML activity diagrams.
• Describes persistent data sources (databases and files) and identifies the
classes required to manage them.
• Develop and elaborates behavioral representations for a class or
component. This can be done by elaborating the UML state diagrams
created for the analysis model and by examining all use cases that are
relevant to the design class.
• Elaborates deployment diagrams to provide additional implementation
detail.
• Demonstrates the location of key packages or classes of components in
a system by using class instances and designating specific hardware and
operating system environment.
• The final decision can be made by using established design principles
and guidelines. Experienced designers consider all (or most) of the
alternative design solutions before settling on the final design model.
Component diagrams are used to describe the physical artifacts of a system.
This artifact includes files, executables, libraries, etc. Initially, the system is
designed using different UML diagrams and then when the artifacts are ready,
component diagrams are used to get an idea of the implementation.
This diagram is very important as without it the application cannot be
implemented efficiently. A well-prepared component diagram is also important
for other aspects such as application performance, maintenance, etc.
and Design
Architectural
Modelling

NOTES
and Design
83
Before working a component diagram, the following artifacts are to be
identified clearly −
• Files used in the system.
• Libraries and other artifacts relevant to the application.
• Relationships among the artifacts.
After identifying the artifacts, the following points need to be kept in mind.
• Use a meaningful name to identify the component for which the diagram
is to be drawn.
• Prepare a mental layout before producing the using tools.
• Use notes for clarifying important points.
Relating Components
Component diagrams are different in terms of nature and behaviour.
Component diagrams are used to model the physical aspects of a system. Now
the question is, what are these physical aspects? Physical aspects are the elements
such as executable, libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and
relationships among components in a system. These diagrams are also used to
make executable systems.
Creates a naming conventions for components that are specified as part of
the architectural model and then refines or elaborates as part of the component-
level model.
• Attains architectural component names from the problem domain and
ensures that they have meaning to all stakeholders who view the
architectural model. Architectural
Modelling

NOTES
84
• Extracts the business process entities that can exist independently without
any associated dependency on other entities.
• Recognizes and discover these independent entities as new components.
• Uses infrastructure component names that reflect their implementation-
specific meaning.
• Models any dependencies from left to right and inheritance from top
(base class) to bottom (derived classes).
• Model any component dependencies as interfaces rather than representing
them as a direct component-to-component dependency.
Deployment Diagram
One of the advantages of UML diagrams is while designing it does not
consider only software but also hardware through deployment diagram. After
software components, now the designer need to think and visualize about the
physical arrangement of physical components used for the system. So for
visualizing the topology of the physical components of the system ‘deployment
diagrams’ are used. Using these physical components the software components
are deploed. Deployment diagrams are used to describe the static deployment
view of a system. Deployment diagrams consist of nodes and their relationships.
Using deployment diagram
Purpose of Deployment Diagram
The term Deployment itself describes the purpose of the diagram.
Deployment diagrams are used for describing the hardware components, where
software components are deployed. Component diagrams and deployment
diagrams are closely related.
Component diagrams are used to describe the components and deployment
diagrams shows how they are deployed in hardware.
UML is mainly designed to focus on the software artifacts of a system.
However, these two diagrams are special diagrams used to focus on software and
hardware components.
Most of the UML diagrams are used to handle logical components but
deployment diagrams are made to focus on the hardware topology of a system.
Deployment diagrams are used by the system engineers.
The purpose of deployment diagrams can be described as −
• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software components.
• Describe the runtime processing nodes.
Deployment diagrams are mainly used by system engineers. These diagrams
are used to describe the physical components (hardware), their distribution, and
and Design
Architectural
Modelling

NOTES
and Design
85
association. Deployment diagrams can be visualized as the hardware
components/nodes on which the software components reside. Software
applications are developed to model complex business processes. Efficient
software applications are not sufficient to meet the business requirements.
Business requirements can be described as the need to support the increasing
number of users, quick response time, etc.
To meet these types of requirements, hardware components should be
designed efficiently and in a cost-effective way. Now-a-days software
applications are very complex in nature. Software applications can be standalone,
web-based, distributed, mainframe-based and many more. Hence, it is very
important to design the hardware components efficiently.
Deployment diagrams can be used −
• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.
Architecture of System
The architecture of any software system can be defined as selection and
arrangement of hardware, network topology and deployment of different software
components on these hardware components, is in all known as architecture of
system.
Different Architectures used for System
Over the time period the IT field has gone on progressing and different
architectures have been developed. In this section we are going to discuss
different architectures. The architectural styles that are used while designing the
software as follows:
1. Data-centered architecture
• The data store in the file or database is occupying at the center of
the architecture.
• Store data is access continuously by the other components like
an update, delete, add, modify from the data store.
• Data-centered architecture helps integrity.
• Pass data between clients using the blackboard mechanism.
• The processes are independently executed by the client components.
Architectural
Modelling

NOTES
86
2. Data-flow architecture
• This architecture is applied when the input data is converted into
a series of manipulative components into output data.
• A pipe and filter pattern is a set of components called as filters.
• Filters are connected through pipes and transfer data from one
component to the next component.
• The flow of data degenerates into a single line of transform then
it is known as batch sequential.
3. Call and return architectures
This architecture style allows to achieve a program structure which is
easy to modify. There are many sub styles like main program
architecture, remote procedure call architecture, etc.
4. Object-oriented architectures
• This architecture is the latest version of call-and-return architecture.
• It consist of the bundling of data and methods.
5. Layered architectures
• The different layers are defined in the architecture. It consists of
outer and inner layer.
• The components of outer layer manage the user interface operations.
• Components execute the operating system interfacing at the inner
layer.
• The inner layers are application layer, utility layer and the core layer.
• In many cases, It is possible that more than one pattern is suitable
and the alternate architectural style can be designed and
evaluated.
and Design
Architectural
Modelling

NOTES
and Design
87
In addition to these there are many architectures like client-server, peer to
peer, MVC, Event Driven Architecture. These all are interdependent and are used
along with the other. This makes deployment of the system more complex. Hence
while designing the system if deployment diagram is ready, then it makes the
transition phase easy.
Representing Architecture using Deployment Diagram
In this developing era, which is still under development, different
architectures were introduced and used by Above discussed all the architectures
can be represented with the help of Deployment diagram. represents the
deployment view of a system. It is related to the component diagram because the
components are deployed using the deployment diagrams.Adeployment diagram
consists of nodes. Nodes are nothing but physical hardware used to deploy the
application.
Deployment diagrams are useful for system engineers. An efficient
deployment diagram is very important as it controls the following parameters −
• Performance
• Scalability
• Maintainability
• Portability
Before drawing a deployment diagram, the following artifacts should be
identified −
• Nodes
• Relationships among nodes
Following is a sample deployment diagram to provide an idea of the
deployment view of order management system. Here, we have shown nodes as
Architectural
Modelling

NOTES
88
• Monitor
• Modem
• Caching server
• Server
The application is assumed to be a web-based application, which is
deployed in a clustered environment using server 1, server 2, and server 3. The
user connects to the application using the Internet. The control flows from the
caching server to the clustered environment.
The following deployment diagram has been drawn considering all the
points mentioned above.
Fig 5.1 : Deployment diagram for Order Management System
*****
and Design
Architectural
Modelling

NOTES
and Design
89
UNIT NO - VI
OBJECT ORIENTED
PROGRAMMING STYLES
To understand
• Advantages of Object Oriented style of software design
• Advantages of concept reusability and extensibility
• Designing of system with the help of diagrams discussed for different
case studies
Introduction
The major characteristic of any Object Oriented Language is reusability,
extensibility and robustness. Any developer of the object oriented software
system also wishes to have same characteristics to be hold by his system.
The designer who is willing to have these characteristics in his system, the
care has to be taken from the designing phase of the system. If the designer
properly implements concepts of OOP while designing the system and if
structural diagrams are designed carefully then the system can hold the properties
of reusability, extensibility and robustness. Design of classes in the system helps
to achieve the above discussed characteristics.
The chapter discusses how a designer can design a system so that it will be
reusable, extensible and robust.
Object Oriented Style
Understanding Object Oriented concepts and using them efficiently in
construction of software components is called as Object Oriented Style of
Programming. In the construction of any software 70% of efforts are taken on
designing then for an object oriented systems it may be 85% of total efforts for
designing of the system. While designing any software artifact, the designer
should be able to visualize it in future. He should be able to visualize what future
modifications it will need, and accordingly the artifact should be designed or
coded. For example if a class is being designed which plays a crucial role in the
system, then while defining its members the designer has to be careful. Visibility
of each member should be decided carefully and also a thought should be given
to its future extension. This makes the system easily upgradable and is widely
accepted by users. The section 6.1.1 discusses about designing a extensible and
reusable software systems. Object Oriented
Programming Styles

NOTES
90
Reusability and Extensibility
These two words, reusability and extensibility, may be confused but both
these words tries to explain two different aspects of the current system. The term
‘reusability’ deals with generalization of the system; so that these generalized
components can be reusable, while the term ‘extensibility’ deals with future
growth of the system where the designer thinks about up gradation of the system.
Following subsections discusses concept of reusability and extensibility in detail.
I. Reusability
The term reusability can be explained as using the previously defined
software artifacts or processes for developing new artifacts. The concepts of
Object Oriented Paradigms, like inheritance, polymorphism and message passing,
allows user to develop reusable software components which can be used for
developing more artifacts. Reusability saves efforts of the designer as well as
programmer of writing same program code again, so with this the existing
investment can be reused. Framework, Software components, chunks of code
can be designed so that it can be reused.
Software framework is represented by its code which consists of a set of
classes, abstract classes and interfaces, a set of behavior and a set of hooks where
subclasses can insert their specialized behavior. The framework is to be designed
in such a way so that code, design, domain analysis can be reusable. Once the
framework has become reusable it reduces code writing efforts and also gives
opportunity for inexperienced designers and developers to develop good software
as the well-developed framework represents the extract of knowledge of
experimented designers and programmers. Reuse of framework components
improves developer productivity, as well as software performance, reliability,
and interoperability. The stable interfaces define generic components that can be
extended to create new applications.
Like framework components, which contributes to the framework a lot,
needs to be designed reusable. In the previous chapter we have discussed about
the components and the component diagram. Components are the software
artifacts which may consists of any framework, packages designed by designer
of the system, classes, chunks of codes (functions), etc. while a component
diagram shows the dependency between components of the system. A designer
can make his system reusable by concentrating on the design of these various
components.
Techniques used for reusability are –
• Object composition and
• Inheritance
These techniques help for reusing functionality in object-oriented systems.
Class inheritance allows a subclass implementation to be defined in terms of the
parent class implementation. This type of reuse is often called white-box reuse.
and Design
Object Oriented
Programming Styles

NOTES
and Design
91
Object composition is a different method of reusing functionality. Objects are
composed to achieve more complex functionality. This approach requires that
the objects have well-defined interfaces since the internals of the objects are
unknown. Because objects are treated only as black boxes, this type of reuse is
often called black-box reuse. The components can be reusable if those are
generalized in definition.
Following are tricks which help to make the components more reusable-
i. Components should be designed to work on different context so that
they can be easily reused instead of defining new.
ii. Generalize design as much as possible by using Frameworks, Patterns,
and UML Collaborations. Frameworks or reusable patterns helps to
keep design more flexible and hence can be reused in different
scenarios.
iii. Design the system to contain hooks.
iv. Keep the design as simple as possible.
II. Extensibility –
The feature of Extensibility makes system easily upgradable. It is a system
design principle where the implementation takes future growth into
consideration. When a designer thinks about extensibility he needs to consider
various aspects of the system, which will help to extend the system in future.
Extensions can be through the addition of new functionality or through
modification of existing functionality.
In any Object Oriented Software System the least element is ‘a class’, which
plays a major role in extending the system. While designing a class the designer
should think and try to implement maximum concepts so that the class can hold
the feature of extensibility without violating or introducing major changes in
original data. The care, while designing the class, has to be taken so that the
extensibility of system does not compromise the data security.
The central theme is to provide for change typically enhancements while
minimizing impact to existing system functions.
Like classes in the system, the framework of the system can also be
designed to be extensible. A framework enhances extensibility by providing
explicit hook methods for planned variability. These hook methods allows
developer to extend the functionalities.
The extensibility mechanisms are classified as
• White-Box extensibility - White-box extensibility refers to the ways in
which a software system can be extended by modifying or adding to the
source code. This is the least restrictive and most flexible form of
extensibility.
Object Oriented
Programming Styles

NOTES
92
• Glass-Box extensibility - Glass-box extensibility refers to the ways in
which a software system may be copied, when the source code is
available, but may not be modified. Programmers that want to extend the
system can view the code, but they have to separate their extensions from
the original system in a way that does not affect the original system.
• Black-Box extensibility - Black-box extensibility refers to the ways in
which a software system may be extended when no internal details about
a system’s architecture and implementation are available. Black-box
extensible systems are deployed and extended only by using their
interface specification. This approach allows system manufacturers to
fully encapsulate their systems and hide all implementation details.
Though till the discussion on extensibility and reusability was carried out
separately, there are some similarities in both the concepts. Both of them
emphasis on low coupling, modularity and high cohesion. Software reusability
is boosted by extensibility and refers to software elements ability to construct
for many different software systems, which is motivated by the observation of
software systems often sharing common elements. Reusability together with
extensibility allows a technology to be transferred to another project with less
development and maintenance time, as well as enhanced reliability and
consistency
Robustness
‘Robustness’ is again one of the characteristics of programming, which is
supported by most of the Object Oriented Programming Languages. The term
‘robustness’, with reference to programming languages can be explained as ‘the
ability of a computer system to cope with errors during execution as well as to
cope with erroneous input given to the program. For example the concept of
‘exception handling’, as learnt in java, helps to write robust programs.
A designer or a developer always tries to design or write programs which
will be error tolerant. Not only OOAD, but in other areas of computer science
also aims towards writing robust programs such as robust programming, robust
machine learning, and Robust Security Network. Various commercial software
products perform robustness testing of software analysis. This testing assures
stakeholders robustness of the software product.
For building a robust software system, the system is tested with all possible
input and all possible input combinations. Testing with all possible inputs and
their combinations helps to check the system ay every point of possible failure
due to unexpected input. But in reality it is difficult because of the vast quantity
of inputs and input combinations. Since all inputs and input combinations would
require too much time to test, developers cannot run through all cases
exhaustively.And therefore easiest way for developers is to generalize such cases.
The above situation can be explained with the help of a simple example. A
program expects an integer as an input. While some selected inputs might consist
and Design
Object Oriented
Programming Styles

NOTES
and Design
93
of a negative number, zero, and a positive number. When using these numbers
to test software in this way, the developer generalizes the set of all reals into three
numbers. This is a more efficient and manageable method, but more prone to
failure. Generalizing test cases is an example of just one technique to deal with
failure—specifically, failure due to invalid user input. Systems generally may
also fail due to other reasons as well, such as disconnecting from a network.
Regardless, complex systems should still handle any errors encountered
gracefully. There are many examples of such successful systems. Some of the
most robust systems are evolvable and can be easily adapted to new situations.
To overcome the situation we can have different programming constructs
to handle a particular situation so that if a particular functionality is not working
or fails to give expected results we can go for the other to handle the same
situation.
Programming in the Large
The concept of Programming in Large deals with developing a project or a
system in modules, so that at a time team can concentrate on different parts of
system and helps more in implementing the concept of reusability. If a large
program is divided in modules it helps to complete the program with
comparatively small duration of time.
In software engineering, programming in the large and programming in the
small describe two different approaches to writing software. The terms were
coined by Frank DeRemer and Hans Kron in their 1975 paper "Programming-
in-the-large versus programming-in-the-small".
In software development, programming in the large can involve
programming by larger groups of people or by smaller groups over longer time
periods. Either of these conditions will result in large, and hence complicated,
programs that can be challenging for maintainers to understand.
With programming in the large, coding managers place emphasis on
partitioning work into modules with precisely-specified interactions. This
requires careful planning and careful documentation.
With programming in the large, program changes can become difficult. If a
change operates across module boundaries, the work of many people may need
re-doing. Because of this, one goal of programming in the large involves setting
up modules that will not need altering in the event of probable changes. This is
achieved by designing modules so they have high cohesion and loose coupling.
Programming in the large requires abstraction-creating skills. Until a
module becomes implemented it remains an abstraction. Taken together, the
abstractions should create an architecture unlikely to need change.[citation
needed] They should define interactions that have precision and demonstrable
correctness.
z Object Oriented
Programming Styles

NOTES
94
Programming in the large requires management skills. The process of
building abstractions aims not just to describe something that can work but also
to direct the efforts of people who will make it work.
Case Studies
The section gives various sample UML diagrams for five different software
systems. These will enable you to understand better the usage of UML diagrams.
These are sample diagrams, as we have discussed earlier, UML is free and keeps
designer free to implement his own perception. According to your own
understanding the diagrams can be modified.
Library Management System
(Source : https://www.startertutorials.com/uml/uml- diagrams-
library-management-system.html)
a. Use case diagram
and Design
Object Oriented
Programming Styles

NOTES
and Design
95
b. Activity diagram – Activity Diagram for Use Case ‘Lend Item’
Object Oriented
Programming Styles

NOTES
96
c. Class diagram
d. State transition diagram for class ‘book’
and Design
Object Oriented
Programming Styles

NOTES
and Design
97
e. Sequence diagram : Sequence diagram for activity ‘Lend Item’
f. Collaboration diagram
Object Oriented
Programming Styles

NOTES
98
g. Component diagram
h. Deployment diagram
Hospital Management System
a. Use Case Diagram
and Design
Object Oriented
Programming Styles

NOTES
and Design
99
b. Activity Diagram – Activity Diagram for use case ‘Visit for Test’
Object Oriented
Programming Styles

NOTES
100
c. Class Diagram
d. State Transition Diagram for object Patient
and Design
Object Oriented
Programming Styles

NOTES
and Design
101
e. Collaboration Diagram
f. Sequence Diagram
Object Oriented
Programming Styles

NOTES
102
Online Shopping
(Source : https://www.uml-diagrams.org/examples/online-shopping-
example.html)
a. Use case diagram
b. Activity diagram
and Design
Object Oriented
Programming Styles

NOTES
and Design
103
c. Component diagram
Nukari.com
a. Use case
(Source : https://stackoverflow.com/questions/21534446/online-job-
portal- system-use-case-diagrams)
Object Oriented
Programming Styles

NOTES
104
b. Class diagram
(Source : https://www.geekletters.com/online-job-portal-project-uml-
diagrams/)
c. Activity diagram
and Design
Object Oriented
Programming Styles

NOTES
and Design
105
Matrimonial Website
(Source : https://meeraacademy.com/)
a. Use case diagram
Object Oriented
Programming Styles

NOTES
106
b. Activity Diagram – for user MEMBER
and Design
Object Oriented
Programming Styles

NOTES
and Design
107
c. Activity Diagram – for User ADMIN
Object Oriented
Programming Styles

NOTES
108
d. Class diagram
(Source : https://www.freeprojectz.com/uml/marriage-beuro-
management-class-diagram)
*****
and Design
Object Oriented
Programming Styles

502 Object Oriented Analysis and Design.pdf

Recommended

More Related Content

Similar to 502 Object Oriented Analysis and Design.pdf (20)

Recently uploaded (20)

502 Object Oriented Analysis and Design.pdf