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
Objectives of the Chapter
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/
• https://www.visual-paradigm.com/guide/uml-unified-modeling-
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

502 Object Oriented Analysis and Design.pdf

502 Object Oriented Analysis and Design.pdf

Recommended

Recommended

More Related Content

Similar to 502 Object Oriented Analysis and Design.pdf

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

Recently uploaded

Recently uploaded (20)

502 Object Oriented Analysis and Design.pdf