Modelling with UML

Concepts and Diagrams

• Unified Modelling Language (UML) is a general purpose modelling language.
• The main aim of UML is to define a standard way to visualize the way a system has
been designed. (Similar to blueprints used in other fields of engineering)
• UML is not a programming language, it is rather a visual language.
• We use UML diagrams to portray the behaviour and structure of a system.
• UML helps software engineers, businessmen and system architects with modelling,
design and analysis.
• The Object Management Group (OMG) adopted Unified Modelling Language as a
standard in 1997. Its been managed by OMG ever since.
• International Organization for Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years and is reviewed periodically.
• UML is linked with object oriented design and analysis.
• UML makes the use of elements and forms associations between
them to form diagrams. Diagrams in UML can be broadly classified as:
1)Structural Diagrams – Capture static aspects or structure of a system.
Structural Diagrams include: Component Diagrams, Object Diagrams,
Class Diagrams and Deployment Diagrams.
2)Behavior Diagrams – Capture dynamic aspects or behavior of the
system. Behavior diagrams include: Use Case Diagrams, State Diagrams,
Activity Diagrams and Interaction Diagrams.
Hierarchy of diagrams according to UML 2.2
Object Oriented Concepts Used in UML –
• Class – A class defines the blue print i.e. structure and functions of an object.
• Objects – Objects help us to decompose large systems and help us to modularize our
system. Modularity helps to divide our system into understandable components so
that we can build our system piece by piece. An object is the fundamental unit
(building block) of a system which is used to depict an entity.
• Inheritance – Inheritance is a mechanism by which child classes inherit the properties
of their parent classes.
• Abstraction – Mechanism by which implementation details are hidden from user.
• Encapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
• Polymorphism – Mechanism by which functions or entities are able to exist in
different forms.
Use case diagram
• A use case diagram is a representation of a user's interaction with the
system that shows the relationship between the user and the
different use cases in which the user is involved.
• A use case diagram can identify the different types of users of a
system.It models the services, tasks, function that a system needs to
perform.
• These diagrams capture the dynamic behaviour of a live system. It
models how an external entity interacts with the system to make it
work. Use case diagrams are responsible for visualizing the external
things that interact with the part of the system.
Use-case diagram notations
• Following are the common notations used in a use case diagram:
1. Use-case:
• Use cases are used to represent high-level functionalities and how the
user will handle the system.
• It is denoted by an oval shape with the name of a use case written
inside the oval shape.
• The notation of a use case in UML is given below:

UML UseCase Notation

2. Actor:
• The actor is an entity that interacts with the system. (A user is the
best example of an actor).
• One actor can be associated with multiple use cases in the system.
The actor notation in UML is given below:

UML Actor Notation

 Drawing a use-case diagram
1. To draw a use case diagram in UML ,the entire system is to be analysed
carefully to find out every single function that is provided by the system. After
all the functionalities of a system are found out, then these functionalities are
converted into various use cases which will be used in the use case diagram.
2. A use case is a core functionality of any working system. After organizing the
use cases, the various actors or things that are going to interact with the
system are enlisted. These actors are responsible for invoking the functionality
of a system. Actors can be a person or a thing.
3. After the actors and use cases are enlisted, the relationship of a particular
actor with the use case or a system is found out . Identify the total number of
ways an actor could interact with the system. A single actor can interact with
multiple use cases at the same time.
• Following rules must be followed while drawing use-case for any
system:
1. The name of an actor or a use case must be meaningful and
relevant to the system.
2. Interaction of an actor with the use case must be defined clearly
and in an understandable way.
3. If a use case or an actor has multiple relationships, then only
significant interactions must be displayed.
Tips for drawing a use-case diagram
• A use case diagram should be as simple as possible.
• A use case diagram should be complete.
• A use case diagram should represent all interactions with the use
case.
• If there are too many use cases or actors, then only the essential use
cases should be represented.
Example of a use case diagram
Working of a student management system
Hospital management- use case diagram
Class Diagram
• Class diagram is a static diagram. It represents the static view of an
application.
• It is not only used for visualizing, describing, and documenting different
aspects of a system but also for constructing executable code of the
software application.
• It describes the attributes and operations of a class and also the
constraints imposed on the system.
• The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.
• Class diagrams are the most popular UML diagrams used for construction
of software applications. 
• Class : A description of a group of objects all with similar roles in the system, which
consists of certain characteristics and behaviour
• A class notation consists of three parts:
1. Class Name
2. Class Attributes
3. Class Operations (Methods)
• Relationship types
1. Inheritance or Generalization
‘is –a’ relationship

2. Simple Association:A structural link between two peer classes.

3. Aggregation:
”part of" relationship.

4. (Class2 is part of Class1.)Composition:(A special type of aggregation

where parts are destroyed when the whole is destroyed.)
Class 2 cannot stand by itself .It lives or dies with Class 1
5. Dependency: one class may cause changes to other.
Class1 depends on Class2

Relationship Names
• Names of relationships are written in the middle of the association
line. They have a small arrowhead to show the direction in which
direction to read the relationship.
Good relation names make sense when you read them out loud:
"Every spreadsheet contains some number of cells",
"an expression evaluates to a value"
Visibility of Class attributes and Operations
• In object-oriented design, there is a notation of visibility for attributes and
operations.
• UML identifies four types of visibility: public, protected, private,
and package.The +, -, # and ~ symbols before an attribute and operation
name in a class denote the visibility of the attribute and operation.
• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations
• ~ denotes package attributes or operations
Steps to construct a class diagram
• Step 1: Identify the class names
• Step 2: Distinguish relationships(determine how each of the classes or
objects are related to one another. )
• Step 3: Create the Structure(add the class names and link them with
the appropriate connectors. You can add attributes and functions/
methods/ operations later.)
Example class diagram showing Aggregation
Example class diagram showing Inheritance
Interaction diagrams
• Interaction diagram is used to describe the type of interactions among the different
elements in the model. This interaction is a part of dynamic behaviour of the system.
• This interactive behaviour is represented in UML by two diagrams :
1. Sequence diagram : emphasizes on time sequence of messages
2. Collaboration diagram: emphasizes on the structural organization of the objects that
send and receive messages.
• The basic purpose of both the diagrams are similar
• The purpose of interaction diagrams is to visualize the interactive behaviour of the
system,hence the solution is to use different types of models to capture the different
aspects of the interaction.
• Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.
• The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.
• Following things are to be identified clearly before drawing the
interaction diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.
Notation of an interaction diagram
State chart diagrams
• Statechart diagram is used to model the dynamic nature of a system.
• They define different states of an object during its lifetime and these
states are changed by events.
• Statechart diagrams are useful to model the reactive systems.
Reactive systems can be defined as a system that responds to external
or internal events.
•   It describes the flow of control from one state to another state.
States are defined as a condition in which an object exists and it
changes when some event is triggered.
Main purposes of using Statechart diagrams −
• To model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.
Before drawing a Statechart diagram we should
• Identify the important objects to be analyzed.
• Identify the states.
• Identify the events.
Activity diagram
• 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.

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.
• Before drawing an activity diagram, we should identify the following
elements −
• Activities
• Association
• Conditions
• Constraints
Component Diagrams
• Component diagrams are used to model the physical aspects of a
system.
Component diagrams can be used to −
• Model the components of a system.
• Model the database schema.
• Model the executables of an application.
• Model the system's source code.
Before drawing a component diagram, the following artifacts are to be
identified clearly −
• Files used in the system.
• Libraries and other artifacts relevant to the application.
• Relationships among the artifacts.
After identifying the artifacts, the following points need to be kept in mind.
• Use a meaningful name to identify the component for which the diagram is to
be drawn.
• Prepare a mental layout before producing the using tools.
• Use notes for clarifying important points
Deployment diagram
• Deployment Diagram is a type of diagram that specifies the physical
hardware on which the software system will execute.
• It also determines how the software is deployed on the underlying hardware.
It maps software pieces of a system to the device that are going to execute it.
• The deployment diagram maps the software architecture created in design to
the physical system architecture that executes it.
• Deployment diagrams are used to visualize the topology of the physical
components of a system, where the software components are deployed.
• Deployment diagrams are used to describe the static deployment view of a
system. 
• The purpose of deployment diagrams can be described as −
1.Visualize the hardware topology of a system.
2. Describe the hardware components used to deploy software components.
3. Describe the runtime processing nodes.
• An efficient deployment diagram is very important as it controls the following
parameters −
1. Performance
2. Scalability
3. Maintainability
4. Portability
• Before drawing a deployment diagram, the following artifacts should be
identified −
1. Nodes(3-D box shows a node , represents either software or hardware)
2. Relationships among nodes
• Deployment diagrams can be used −
1.To model the hardware topology of a system.
2.To model the embedded system.
3.To model the hardware details for a client/server system.
4.To model the hardware details of a distributed application.
Package Diagrams
• Package diagrams are used to structure high level system elements.
• Packages are used for organizing large system which contains
diagrams, documents and other key deliverables.
• Package Diagram can be used to simplify complex class diagrams, it
can group classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any of the
UML diagrams.
• Package is used to group together elements that are semantically
related and might change together.
• It is a general purpose mechanism to organize elements into groups to
provide better structure for system model.
• Owned members of a package should all be packagable elements. If
a package is removed from a model, so are all the elements owned by
the package.
• Package by itself is packagable element, so any package could be also
a member of other packages.
• Package can also be merged with other packages.
• A package is rendered as a tabbed folder - a rectangle with a small tab
attached to the left side of the top of the rectangle. If the members of the
package are not shown inside the package rectangle, then the name of the
package should be placed inside.
• The members of the package may be shown within the boundaries of the
package. In this case the name of the package should be placed on the tab.
• Members of the package may be shown outside the package by branching
lines from the package to the members. A plus sign (+) within a circle is
drawn at the end attached to the package.
Example package diagram
•  Elements may have a visibility that determines whether they are
available outside the package.
• If an element that is owned by a package has visibility, it could be
only public(+) or private(-) visibility. Protected or package visibility is
not allowed.
Design process
• Software Design is the process to transform the user requirements
into some suitable form, which helps the programmer in software
coding and implementation.
• During the software design phase, the design document is produced,
based on the customer requirements as documented in the SRS
document.
• The aim of this phase is to transform the SRS document into the
design document.
• The following items are designed and documented during the design
phase:
1. Different modules required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
5. Algorithms required to implement among the individual modules.
• The software design concept means the idea or principle behind the
design.
• It describes how you plan to solve the problem of designing software,
the logic, or thinking behind how you will design software.
• It allows the software engineer to create the model of the software or
product that is to be developed.
• The software design concept provides a supporting and essential
structure or model for developing the right software. 
Objectives of Software Design:
• Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of the
system.
• Efficiency:
A good software design should address the resources, time and cost optimization issues.
• Understandability:
A good design should be easily understandable, for which it should be modular and all the
modules are arranged in layers.
• Completeness:
The design should have all the components like data structures, modules, and external interfaces,
etc.
• Maintainability:
A good software design should be easily amenable to change whenever a change request is made
from the customer side.
Design Concepts
• A set of fundamental software design concepts have developed over
the history of software engineering.  
• Each provides the software designer with a foundation from which
more sophisticated design methods can be applied. 
• The following important software design concepts that span both
traditional and object-oriented software development. 
1. Abstraction- hide relevant data

• Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
• Different levels of Abstraction are necessary and must be applied at each stage of the design process so
that any error that is present can be removed to increase the efficiency of the software solution and to
refine the software solution.
• The solution should be described in broadways that cover a wide range of different things at a higher
level of abstraction and a more detailed description of a solution of software should be given at the
lower level of abstraction.
• Two types of abstraction :procedural abstraction and data abstraction
• Examples:An example of a procedural abstraction would be the word open for a door. Open implies a
long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull
door, step away from moving door, etc.)We can define a data abstraction called door. A set of attributes
that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). 
2. Architecture- design a structure of something

• Architecture simply means a technique to design a structure of

something.
• Architecture in designing software is a concept that focuses on
various elements and the data of the structure.
• These components interact with each other and use the data of the
structure in architecture.
3.Separation of concerns

• Separation of concerns is a design concept, that suggests any complex problem can be more
easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently.
• By separating concerns into smaller, and therefore more manageable pieces, a problem takes
less effort and time to solve.
• Separation of concern is visible) in other related design concepts:
o Modularity,
o Aspects,
o Functional independence,
o Refinement.
4. Pattern- a repeated form
• The pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern.
• The pattern in the design process means the repetition of a solution to a
common recurring problem within a certain context.
5. Modularity- subdivide the system
• Modularity simply means to divide the system or project into smaller parts to
reduce the complexity of the system or project.
• In the same way, modularity in design means to subdivide a system into smaller
parts so that these parts can be created independently and then use these parts
in different systems to perform different functions..
6.Information Hiding- hide the information
• Information hiding simply means to hide the information so that it cannot be accessed by an unwanted
party. In software design, information hiding is achieved by designing the modules in a manner that the
information gathered or contained in one module is hidden and it cant be accessed by any other
modules.
7.Functional independence-
• The functional independence is the concept of separation and related to the concept of modularity,
abstraction and information hiding. The functional independence is accessed using two criteria i.e
Cohesion and coupling.
1. Cohesion: Cohesion is an extension of the information hiding concept.
• A cohesive module performs a single task and it requires a small interaction with the other components
in other parts of the program.
2. Coupling:
• Coupling is an indication of interconnection between modules in a structure of software
8.Refinement- removes impurities
• Refinement simply means to refine something to remove any impurities if present and increase
the quality.
• The refinement concept of software design is actually a process of developing or presenting the
software or system in a detailed manner that means to elaborate a system or software.
• Refinement is very necessary to find out any error if present and then to reduce it.
9.Refactoring- reconstruct something
• Refactoring means to reconstruct something in such a way that it does not affect the behaviour or
any other features.
• Refactoring in software design means to reconstruct the design to reduce and complexity and
simplify it without affecting the behaviour or its functions.
• Fowler has defined refactoring as “the process of changing a software system in a way that it
won’t affect the behaviour of the design and improves the internal structure”.
10. Aspects:
• A representation of a cross-cutting concern that must be accommodated as
refinement and modularization occur.
• For example : (Module A cross cut Module B means B cannot be satisfied
without considering A).
11. Object-Oriented Design Concepts :
• The object-oriented (OO) paradigm is widely used in modern software
engineering. 
• OO design concepts such as classes and objects, inheritance, messages, and
polymorphism, among others are the different features of oo paradigm.
12. Design Class 
• Refine analysis classes by providing detail needed to implement the classes and
implement a software infrastructure the support the business solution 
• Five types of design classes can be developed to support the design architecture..
1. User interface classes – abstractions needed for human-computer interaction (HCI) 
2. Business domain classes – refinements of earlier analysis classes 
3. Process classes – implement lower level business abstractions required to fully
manage the business domain classes. 
4. Persistent classes – represents data stores that will persist beyond software
execution 
5. System classes – implement software management and control functions…
Design model
• A design model in Software Engineering is an object-based picture or
pictures that represent the use cases for a system.
• Or t it means to describe a system's implementation and source code
in a diagrammatic fashion.
• This type of representation has two advantages.
1) it is a simpler representation than words alone.
2) people can look at these simple diagrams and quickly get the
general idea behind a system.
Elements of design model
• Data: The data design element produced a model of data which is
processed by the computer based system. The structure of data is the
most important part of the software design.
• Architectural - This involves breaking the system down into its major
functional pieces and describing each in a diagrammatic fashion. The
interaction between each piece is also described. For example, an
instant messaging system might have a 'send message' piece and an
interaction might be the user types characters that act as input to the
send message piece.
• Interface - The architectural interactions are broken down and described in
greater detail. For example, the user typed characters mentioned above might
be described as arriving a character at a time, each character is displayed on the
cell phone screen as it is typed.
• Component Level - The pieces described in the architectural item above are
broken down into lower level components. For example, the send message piece
might become 'receive character' component, 'display character' component,
and 'transmit character' component.
• Deployment Level - The components arrived at during the previous step are
grouped for the purpose of delivery to their final destination. For example, the
components of the 'send message' piece might be grouped together with other
pieces for deployment on a cell phone.
THANK YOU