OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT-4
Modelling with UML
UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.
UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.
OMG is continuously making efforts to create a truly industry standard.
• UML stands for Unified Modeling Language.
• UML is different from the other common programming languages such as C++, Java,
COBOL, etc.
• UML is a pictorial language used to make software blueprints.
• UML can be described as a general purpose visual modeling language to visualize,
specify, construct, and document software system.
• Although UML is generally used to model software systems, it is not limited within this
boundary. It is also used to model non-software systems as well. For example, the
process flow in a manufacturing unit, etc.
UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design. After
some standardization, UML has become an OMG standard.

Goals of UML
A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-oriented
concepts were introduced much earlier than UML. At that point of time, there were no standard
methodologies to organize and consolidate the object-oriented development. It was then that
UML came into picture.
There are a number of goals for developing UML but the most important is to define some general
purpose modeling language, which all modelers can use and it also needs to be made simple to
understand and use.
UML diagrams are not only made for developers but also for business users, common people,
and anybody interested to understand the system. The system can be a software or non-software
system. Thus it must be clear that UML is not a development method rather it accompanies with
processes to make it a successful system.
In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment.
Basic building blocks of UML
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the following
three major elements −

• UML building blocks

• Rules to connect the building blocks
• Common mechanisms of UML
This chapter describes all the UML building blocks. The building blocks of UML can be defined
as −

• Things
• Relationships
• Diagrams

Things
Things are the most important building blocks of UML. Things can be −

• Structural
• Behavioral
• Grouping
• Annotational
Structural Things
Structural things define the static part of the model. They represent the physical and conceptual
elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.
Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.

Behavioral Things
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things −
Interaction − Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is important.
It defines the sequence of states an object goes through in response to events. Events are
external factors responsible for state change

Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available −
Package − Package is the only one grouping thing available for gathering structural and
behavioral things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note - It is the only one Annotational thing available. A note
is used to render comments, constraints, etc. of an UML element.
Relationship
Relationship is another most important building block of UML. It shows how the elements are
associated with each other and this association describes the functionality of an application.
There are four kinds of relationships available.
Dependency
Dependency is a relationship between two things in which change in one element also affects
the other.

Association
Association is basically a set of links that connects the elements of a UML model. It also
describes how many objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the world of objects.

Realization
Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility, which is not implemented and the other one implements them.
This relationship exists in case of interfaces.

UML Diagrams
UML diagrams are the ultimate output of the entire discussion. All the elements, relationships
are used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the
other elements are used to make it complete.
UML includes the following nine diagrams, the details of which are described in the subsequent
chapters.

• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Activity diagram
• Statechart diagram
• Deployment diagram
• Component diagram

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a conceptual model?
and why a conceptual model is required?
• A conceptual model can be defined as a model which is made of concepts and their
relationships.
• A conceptual model is the first step before drawing a UML diagram. It helps to understand
the entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the following
three major elements −

• UML building blocks

• Rules to connect the building blocks
• Common mechanisms of UML

Object-Oriented Concepts
UML can be described as the successor of object-oriented (OO) analysis and design.
An object contains both data and methods that control the data. The data represents the state
of the object. A class describes an object and they also form a hierarchy to model the real-world
system. The hierarchy is represented as inheritance and the classes can also be associated in
different ways as per the requirement.
Objects are the real-world entities that exist around us and the basic concepts such as
abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.
UML is powerful enough to represent all the concepts that exist in object-oriented analysis and
design. UML diagrams are representation of object-oriented concepts only. Thus, before learning
UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
• Objects − Objects represent an entity and the basic building block.
• Class − Class is the blue print of an object.
• Abstraction − Abstraction represents the behavior of an real world entity.
• Encapsulation − Encapsulation is the mechanism of binding the data together and hiding
them from the outside world.
• Inheritance − Inheritance is the mechanism of making new classes from existing ones.
• Polymorphism − It defines the mechanism to exists in different forms.

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the investigation of objects.
Design means collaboration of identified objects.
Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also
done for an existing system. Now an efficient analysis is only possible when we are able to start
thinking in a way where objects can be identified. After identifying the objects, their relationships
are identified and finally the design is produced.
The purpose of OO analysis and design can described as −
• Identifying the objects of a system.
• Identifying their relationships.
• Making a design, which can be converted to executables using OO languages.
There are three basic steps where the OO concepts are applied and implemented. The steps
can be defined as
OO Analysis → OO Design → OO implementation using OO languages

The above three points can be described in detail as −

• During OO analysis, the most important purpose is to identify objects and describe them
in a proper way. If these objects are identified efficiently, then the next job of design is
easy. The objects should be identified with responsibilities. Responsibilities are the
functions performed by the object. Each and every object has some type of
responsibilities to be performed. When these responsibilities are collaborated, the
purpose of the system is fulfilled.
• The second phase is OO design. During this phase, emphasis is placed on the
requirements and their fulfilment. In this stage, the objects are collaborated according to
their intended association. After the association is complete, the design is also complete.
• The third phase is OO implementation. In this phase, the design is implemented using
OO languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML
is used for non-software systems, the emphasis is on modeling OO software applications. Most
of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before understanding
the UML in detail, the OO concept should be learned properly. Once the OO analysis and design
is done, the next step is very easy. The input from OO analysis and design is the input to UML
diagrams.
 Basic Structural Modelling
A. Classes
1. Why class
• Most important building block of any object-oriented system.
• A description of a set of objects that share the same attributes, operations, relationships, and
semantics.

• To capture the vocabulary of the system being developed in both application and implementation
domains.
1. Terms and concepts
• Class name: (noun with first letter in capital)
Simple name: Wall
Path name: java::awt::Rectangle
• Class attribute:
What is an attribute?
An attribute is a named property of a class that describes a range of values that
instances of the property may hold.
Name convention: noun with first letter in lower case
Definition of an attribute:
name: Type = defaultValue
e.g. height: float = 0.0
• Class operations
What is an operation?
An operation is the implementation of a service that can be requested from any object of
the class to affect behavior.
Name convention: verb with first letter in lower case
Definition of an operation with its signature
name(parameters): return type
e.g. getValue(o: Object): integer
• Class responsibility
What is responsibility?
A responsibility is a contract or an obligation of
obligation of a class.
Cohesion rule:
A class must have at least one, but very few responsibility.
Class attributes and operations realize the class’ responsibility.
In UML, class responsibility can be specified as free text in associated
documentation.

1. Common modeling techniques

• Modeling the vocabulary of a system
a. Identify those things that users or implementers use to describe the problem or solution.
b. For each abstraction, identify a set of responsibilities.
c. Provide the attributes and operations that are needed
• Modeling the distribution of responsibilities in a system
a. Identify a set of classes that work together closely to carry out some behavior
b. Identify a set of responsibilities for each of these classes
c. Look at this set of class as a whole,
 o Split classes that have too many responsibilities into small abstractions
o Collapse tiny classes that have trivial responsibilities into larger ones
o Reallocate responsibilities so that each abstraction reasonably stands on its own.
o Redistribute responsibilities for the collaboration to make each class not do too much or
too little.
1. What is a well-structured class
• Provides a crisp abstraction of something drawn from the vocabulary of the problem domain or
the solution domain.
• Embodies a small, well-defined set of responsibilities and carries them all out very well.
• Provides a clear separation of the abstraction’s specification and its implementation.
• Is understandable and simple yet extensible and adaptable.
A. Relationships between classes
1. Terms and Concepts
• Dependency
A dependency is a using relationship that states that a change in specification of one thing
may affect another thing that uses it, but not necessarily the reverse.
Common dependency in OO:
Class A depends on class B if B is referenced in A as a type name of a class attribute or a
parameter of an operation.
• Generalization
A generalization is a relationship between a general thing (superclass or parent) and a
more specific kind of that thing (subclass or child).
Generalization is an "is-a-kind-of" relationship.
Generalization means:
o A child inherits its parent’s attributes and operations. (inheritance)
o A child can redefine an operation inherited form its parent.
(polymorphism)
o A child is substitutable for the parent, but not reverse. (subtype)
Terms:
o Root class: a class has no parent but has child
o Leaf class: a class has no child
o Single inheritance: a child has only one parent
o Multiple inheritance: a child has two or more parent.
• Association
An association is a structural relationship that specifies that objects of one class are
connected to objects of another class.
Elements of an association
o Name:
describes meaning of the association
o Role name:
describes what is the role of each participating class in the association.

o Multiplicity
describes, for an object of one participating class, how many (range)
objects of the other participating class it can connect to.
o Aggregation
describes a "whole/part" or "has-a" relationship, i.e. an object of the
whole has objects of the part.
Plain association: peer to peer
Aggregation: whole to part
 1. Common modeling techniques
• Modeling simple dependencies
Create a dependency pointing from the class with the operation to the class used as a parameter in
the operation.
• Modeling single inheritance
a. Given a set of classes, look for responsibilities, attributes, and operations that common to two or
more classes.
b. Elevate these common responsibilities, attributes, and operations to a more general class.
c. Specify the more-specific classes inherited from the more-general class with generalization
relationship.

• Modeling structural relationship

a. Identify association using data-data-driven view Objects of class A send data to objects of class B
b. Identify association using behavior-driven view Objects of class A need to interact with objects of
class B
c. Set up roles and multiplicity
d. Identify whole/part or has-a relationship

C. Common Mechanisms
1. Terms and Concepts
• Notes
A note is a graphical symbol for rendering constraints or comments attached to an element or a
collection of elements.
• Named compartment

• Stereotype
A stereotype is an extension of the vocabulary of the UML, to allow creating new kinds of
building blocks.
• Tagged Values
A tagged value is en extension of the properties of a UML element to allow creating new
information in the specification of that element.
A tagged value is metadata.
• Constraints
A constraint is an extension of the semantics of a UML element to allow adding or modifying
rules.
1. Common Modeling Techniques
• Modeling Comments
1. Put a comment in a note and link the note to the corresponding
element using dependency.
2. Make a note visible or invisible
3. Embed external document in a note.
• Modeling New Building Block with Standard Blocks and Stereotypes
• Modeling New Properties for a UML element
Using stereotypes, and tagged values
• Modeling New Semantics for a UML element using constraints
D. UML Diagrams
1. Terms and Concepts
• Structural Diagrams
• Class diagram shows classes, interfaces, and their collaboration relationships
For illustrating the static design view of a system.
• Object diagram shows a set of objects and their relationships.
 For illustrating data structures, the static snapshots of class instances.
• Component Diagram shows a set of components and their relationships.
For illustrating the static implementation view of a system
• Deployment diagram shows a set of nodes and their relationships.
For illustrating the static deployment view of an architecture.
• Behavioral Diagrams
• Use case diagram shows a set of use cases and actors and their relationships.
For illustrating the static use case view of a system.
• Sequence diagram shows a set of objects and messages sent and received by those objects, with
emphasis on the time ordering of messages.
For illustrating the dynamic view of a system
• Collaboration diagram shows a set of objects that send and receive messages, with emphasis on
the structural organization of the collaboration objects.
For illustrating the dynamic view of a system
• Statechart diagram shows a state machine of a class, consisting of states, transitions, and
activities, with emphasis on the event-ordered behavior of an object.
For illustrating the dynamic view of a system
• Activity diagram shows the flow from activity to activity within a system.
For illustrating the dynamic view of a system
1. Common Modeling Techniques
• Modeling Different Views of a System
• Views
Use case view:
The use of use cases that describe the behavior of the system as seen by its end users,
analysts, and testers.
Design View:
The classes, interfaces, and collaborations that form the vocabulary of the problem and its
solution.
Supporting the functional requirements of the system.
Process View:
The threads and processes that form the concurrency and synchronization of the system.
Addressing the performance, scalability, and throughput of the system.
Implementation View:
The components and files that are used to assemble and release the physical system
Addressing the configuration of the system.
Deployment View:
The nodes that form the hardware topology of the system on which the system executes
Addressing the distribution, delivery, and installation of parts that make up the physical
system.
• Modeling the views using UML diagrams
Use case view:
Use case diagrams, interaction diagrams, activity diagrams
Design view:
Class diagrams, interaction diagrams, statechart diagrams
Process view:
Class diagrams (with active classes), interaction diagrams
Implementation view:
Component diagrams
Deployment view
Deployment diagram
• Simple monolithic application
 Use case view, design view
• Client/server systems
Use case view, design view, component view, deployment view
• Modeling Different Levels of Abstraction
• Presenting diagrams with different levels of detail in a single model
• Creating models at different levels of abstraction

E. Class Diagrams
1. Terms and Concepts
• Contents of class diagrams
• Classes
• Interfaces
• Collaborations
• Dependency, Generalization, and association relationships
• Notes
• Constraints
• Packages
• Subsystems
1. Common Modeling Techniques
• Modeling Simple Collaborations
1. Identify the mechanism to be modeled
Mechanism represents some function or behavior of the part of the system from interaction of
classes, interfaces, and others.
2. For each mechanism, identify the participating classes, interfaces, and others.
3. Use scenarios to walk through these things to discover missing and wrong.
• Modeling a Logical Database Schema
1. Identify those classes whose state must transcend the lifetime of their applications.
2. Create a class diagram that contains these classes and mark them as persistent (a standard tagged
value)
3. Specify the details of their attributes, associations, and cardinalities.
4. Use intermediate abstractions to solve cyclic, one-to-one, and n-ary associations.
5. Expanding operations for data access and data integrity. (No business rules in this layer)
• Forward and Reverse Engineering
• Forward engineering
The process of transforming a model into code through a mapping to an implementation
language.
Result in a loss of information (structural and behavioral features)
Forward engineering a class diagram:
1. Identify the rules for mapping to the implementation language
2. Constrain the use of certain UML features because of language limitation
3. Use tagged values to specify the target language
4. Use a tool to forward engineer the model.
o Reverse engineering
The process of transforming code into a model through a mapping from the
implementation language.
Result in a flood of low-level information.
 Basic Behavioral Modelling
A. Interactions
1. Terms and Concepts
• Interaction
A behavior that comprises a set of messages exchanged among a set of objects within a context to
accomplish a purpose.
• Message
A specification of a communication between objects that conveys information with the
expectation that activity will ensue.
• Objects and Roles
• An object participating an interaction can be a concrete instance or a prototype instance of a class
• A prototype instance of an abstract class represents a prototype of any subclass
• Links
A link is an instance of an association denoting a semantic connection between objects.
Stereotypes for visibility from sender to receiver
Association, self, global, local, parameter
• Messages
A message can trigger an action.
Kinds of actions:
• Call invokes an operation on the receiver
• Return a value to the sender
• Create a new object
• Destroy a existing object
• Sequencing
• Procedural sequencing: nested ordered messages
• Flat sequencing: linearly ordered messages

1. Common Modeling Techniques

• Modeling a Flow of Control
a. Set the context got the interaction
b. Identify participating objects and set their roles
c. Identify links between objects
d. Specify the messages that pass from object to object in time order with the associated arguments
and return values.

• Flow control by Time

• Flow control by Organization

B. Use Cases
1. Terms and Concepts
• Use case
A description of a set of sequences of actions, including variants, that a system performs to yield
an observable result of value to an actor.
• Names: simple, path
• Use cases and actors
An actor represents a coherent set of roles that users of use cases play when interacting with these
use cases.
Actor/actor relationship: generalization
 Actor/use case relationship: association
• Use case and flow of events
• Use case: WHAT
• Event flow: HOW
• Event flows: main, exceptional (alternative)
• Use cases and scenarios
• A scenario is an instance of a use case.
• A scenario consists of a set of interactions, each an instance of a (sub) event flow of the use case.
• Use cases and Collaborations
A use case can be implemented by a collaboration
• Organizing use cases
• Packages
• Generalization relationship
• Include relationship (for common behavior)
The base use case explicitly incorporates the behavior of another use case at a location
specified in the base
The base use case delegates part of work to the included use case
• Extend relationship (for system options/exceptions)
The base use case implicitly incorporates the behavior of another use case at a location
specified indirectly by the extending use case
The behavior of the base is extended by the behavior of the extending use case.
The base class can only be extended at its extension points
The extension use case push behavior to the base use case

2. Common Modeling Techniques

• Modeling the behavior of an Element
a. Identify the actors that interact with the element.
b. Organize actors by identifying general and more specialized roles.
c. For each actor, consider the primary ways in which the actor interact with the element
d. Consider exceptional ways in which each actor interacts with the element
e. Organize these behaviors (ways) as use cases

C. Use Case Diagrams

1. Terms and Concepts
• Contents
• Use cases
• Actors
• Dependency, generalization, association relationships
• Packages
1. Common Modeling Techniques
• Modeling the Context of a System
a. Identify actors by grouping user groups
o Those require help from the system to perform their tasks
o Those are needed to execute the system functions
a. Organize actors
b. Provide stereotype for each actor
c. Specify the paths of communication from each actor to the system use cases

• Modeling the Requirements of a System

a. Identify the actors to establish the system context
b. Consider each what behaviors each actor expect or require the system to provide
 c. Name these common behaviors as use cases
d. Organize the use cases using relationships

• Forward Engineering
Form test cases from a use case diagram
For each use case, create a test case
a. Identify the event flows (main, exceptional) of the use case
b. Generate a test script for each flow
c. Generate simulated actor(s)
D. Interaction Diagrams
1. Terms and Concepts
• Contents
• Objects
• Links
• Messages

• Sequence Diagram
Emphasize the time ordering of messages
Special features
• Show object lifetime
• Show the focus of control:
A period of time during which an object is performing an action directly
or indirectly.
• Collaboration Diagrams
Emphasize the organization of the objects that participate in an interaction
Distinct features:
• Show linking path
• Show procedural sequence number
Sequence diagram and collaboration diagram is semantically equivalent

1. Common Modeling Techniques

• Modeling Flows of Control by Time Ordering
a. Set the context for the interaction
b. Identify participating objects/roles
c. Set the lifeline for each object
d. Start the message that initiates this interaction from the top
e. Adorn the lifeline of each object with its focus of control
f. Adorn timing marks with time/space constraints

• Modeling Flow of Control by Organization

a. Same as sequence diagrams in first three steps
b. For an object whose state will be changed during this interaction, create a duplicated object with
new state and connected it with a message stereotyped as <<become>> or <<copy>>
c. Lay out association links
d. Lay out other links
e. Attach each message to the appropriate links with (nested) sequence numbers.
a. Attach pre/post-conditions

E. State Machines and Statecharts

1. Terms and Concept
• State machine
 A behavior that specifies the sequence of states an object goes through during its lifetime in
response to evens, together with its responses to those events.
• State
A condition or situation during the life of an object during which it satisfies some conditions,
perform some activities, or waits for some events.
Basic Parts:
o Name
o Entry/exit actions
• Event
An occurrence of a stimulus that cab trigger a state transition.
• Transition
A relationship between two states indicating that an object in the first state will perform certain
actions and enter the second state when a specified event occurs and specified condition occurs.
Parts:
o Source state
o Target state
o Event trigger
o Guard condition
o Action

1. Common Modeling Techniques

• Modeling Reactive Objects
Example: Parsing a simple context-free language

• Forward engineering
Code generation for a class from its (detailed) statechart
 Architectural Modelling
A. Components
1. Terms and Concepts
• Component
A physical and replaceable part of a system that conforms to and provides the realization of a set
of interfaces.
• Components and classes
o Classes represent logical abstractions
Components represent physical things
o Components represent the physical packaging of logical components at implementation
level
o Components can have operations that are reachable only through their interfaces

• Components and interfaces

o Interface
A collection of operations (not realization of the operations) that used to specify a service
of a class or a component
o Exporting interface of a component
The component realizes the interface to provide the services.
A component can realize more than one interface
o Importing interface of a component
The component uses the services provided by the interface to do the realization
A component can import more than one interface

• Kinds of components
o Deployment components (dll, exe)
Form an executable system
o Work product components (source file, data file)
Residue of the development process
o Execution component
Created as a consequence of an executing system
• Organizing components
Package and relationships (dependency, generalization, association)
• Standard UML stereotypes for components
o Executable
o Library
o Table
o File
o Document

1. Common Modeling Techniques

• Modeling Executables and Libraries
a. Identify the partitioning of the physical system
b. Model any executables and libraries as components
c. Model the significant interfaces
d. Model the relationships among the executables, libraries, and interfaces

• Modeling Tables, Files, and Documents

a. Identify the ancillary components of the system
 b. Model them as components
c. Model their relationships

• Modeling and API

a. Identify the programmatic seams in the system
b. Model each seam as an interface
c. Collection the attributes and operations that form the interface
d. Expose only the properties of the interface that are important to visualize in the given context

• Modeling Source Code

B. Deployment
1.Terms and Concepts
• Node
A physical element that exists at run time and represents a computational resource
• Nodes and components
Node Component
Execute components Participate in the execution
Represent physical deployment Represent physical packaging
Of components of logical elements
o Distribution unit
A set of objects or components that are allocated to a node as a group

• Connections
Association relationships among nodes

• Modeling the Distribution of Components

a. List each component deployed on a node in an additional compartment
b. Using dependency relationships to connect each node with the components it displays
c. Using association relationships to connect nodes

C. Component Diagrams
• Contents
Components, interfaces, relationships (dependency, generalization, association, and realization)
• Common uses
o To model source code
o To model executable release
o To model physical database (mapping classes to tables)
o To model adaptive systems (migration, duplication)

D. Deployment Diagrams
• Contents
o Nodes
o Dependency and association relationships

• Modeling a Client/Server System

a. Identify the nodes the represent the client and server processors
b. Highlight special devices other than computers
c. Provide visual cues for the processors and devices
d. Model the topology of the nodes in a deployment program
• Modeling a Fully Distributed System
a. Identify the processors and devices
b. Model communication devices to the desired detail level for performance evaluation
c. Model the underlying network as a node
d. Model the devices and processors using deployment diagrams
e. Create use case diagrams and interaction diagrams to specify the system interactions