DR.P.VISU
PROFESSOR
DEPT OF CSE
VELAMMAL ENGINEERING COLLEGE

Objectives
To understand the phases in a software project
To understand fundamental concepts of
requirements engineering and Analysis Modeling.
To understand the basics of object oriented
concept
To understand the major considerations for
enterprise integration and deployment.
To learn various testing and project management
techniques

COURSE OUTCOMES
CO. NO. COURSE OUTCOME
BLOOM
S LEVEL
At the end of the course students will be able to
CO 1 Compare different process models. C4
CO 2
Formulate Concepts of requirements engineering
and Analysis Modeling.
C4
CO 3
To understand the fundamentals of object
oriented concept
C3
CO 4 Apply systematic procedure for software design C4
CO 5 Find errors with various testing techniques C4
CO6 Evaluate project schedule, estimate project cost
and effort required
C5

Syllabus
UNIT-I Software Process and Agile Development 9
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models – Introduction to Agility – Agile process – Extreme programming –
XP process - Estimation-FP,LOC and COCOMO I and II, Risk Management, Project
Scheduling.
.
UNIT-IIRequirements Analysis and Specification 9
Software Requirements: Functional and Non-Functional, User requirements,
Software Requirements Document – Requirement Engineering Process: Feasibility
Studies, Requirements elicitation and analysis, requirements validation, requirements
management-Classical analysis: Structured system Analysis, Petri Nets
UNIT III- Object Oriented Concepts 9
Introduction to OO concepts, UML Use case Diagram, Class Diagram-Object
Diagram-Component Diagram-Sequence and Collaboration-Deployment-Activity
Diagram-Package Diagram

Syllabus
UNIT-IV Software Design 9
Design Concepts- Design Heuristic – Architectural Design –Architectural styles,
Architectural Design, Architectural Mapping using Data Flow- User Interface
Design: Interface analysis, Interface Design –Component level Design: Designing
Class based components.
UNIT-VTesting and Management 9
Software testing fundamentals- white box testing- basis path testing-control
structure testing-black box testing- Regression Testing – Unit Testing – Integration
Testing – Validation Testing – System Testing And Debugging –Reengineering
process model – Reverse and Forward Engineering.
Total: 45 Periods

Syllabus
LEARNING RESOURCES:
TEXT BOOKS
1.Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, Eighth Edition,
McGraw-Hill International Edition, 2019.(Unit I,II,IV,V)
2. Ian Sommerville, “Software Engineering”, Global Edition, Pearson Education Asia,
2015.(Unit I,II,III)
3.Bernd Bruegge& Allen H. Dutoit Object-oriented software engineering using UML,
patterns, and Java ,Prentice hall ,3rd Edition 2010.(Unit III)
REFERENCES
1.Titus Winters,Tom Manshreck& Hyrum Wright, Software Engineering at Google,lessons
learned from programming over time, O’ REILLY publications,2020. (Unit I,II,IV,V)
2.Rajib Mall, “Fundamentals of Software Engineering”, Third Edition, PHI Learning
Private Limited, 2009. (Unit I,II,IV,V)
3.PankajJalote, “Software Engineering, A Precise Approach”, Wiley India, 2010 (Unit
I,II,IV,V)
ONLINE LINKS
1.http://www.nptelvideos.in/2012/11/software-engineering.html
2. https://nptel.ac.in/courses/106/101/106101061/

7
Unit 3

Object Basics
8
• Define Objects and classes
• Describe objects’ methods, attributes and how
objects respond to messages,
• Define Polymorphism, Inheritance, data abstraction,
encapsulation, and protocol
• Describe objects relationships,
• Describe object persistence,
• Understand meta-classes.
VEC
3/9/2022

class
3/9/2022 VEC 9
A class represents a collection of objects having same
characteristic properties that exhibit common behavior

What is an object?
• The term object was first formally utilized in the Simula language to
simulate some aspect of reality.
• An object is an entity.
– It knows things (has attributes)
– It does things (provides services or has methods)
10
VEC
3/9/2022

Attributes (Contd.)
I am a Car.
I know my color,
manufacturer, cost,
owner and model.
11
VEC
3/9/2022

It does things
(methods)
I know how to
compute
my payroll.
12
VEC
3/9/2022

Object’s Attributes and Methods
13
• Attributes
– represented by data type.
– They describe objects states.
– In the Car example the car’s attributes are:
• color, manufacturer, cost, owner, model, etc.
• Methods
– define objects behavior and specify the way in which
an Object’s data are manipulated.
– In the Car example the car’s methods are:
• drive it, lock it, tow it, carry passenger in it.
VEC
3/9/2022

Objects are Grouped in Classes
14
• The role of a class is to define the attributes
and methods (the state and behavior) of its
instances.
• The class car, for example, defines the
property color.
• Each individual car (object) will have a
value for this property, such as "maroon,"
"yellow" or "white."
VEC
3/9/2022

Employee Class
Jane object
15
Mark object
John object
VEC
3/9/2022

Difference between object and class
3/9/2022 VEC 16
Object Class
Object is an instance of a class.
Class is a blueprint or
template from which objects are
created.
Object is a real world
entity such as pen, laptop,
mobile, bed, keyboard, mouse,
chair etc.
Class is a group of similar
objects.
Object is a physical entity. Class is a logical entity.
Object is created many
times as per requirement.
Class is declared once.

Method in class
• A method is a block of code or collection of statements or a set
of code grouped together to perform a certain task or operation.
• It is used to achieve the reusability of code.
• We write a method once and use it many times. We do not
require to write code again and again.
• It also provides the easy modification and readability of code,
just by adding or removing a chunk of code.
• The method is executed only when we call or invoke it
• Method Declaration
• The method declaration provides information about method
attributes, such as visibility, return-type, name, and arguments.
3/9/2022 VEC 17

Class Hierarchy
18
• An object-oriented system organizes classes into
subclass-super hierarchy.
• At the top of the hierarchy are the most general
classes and at the bottom are the most specific.
VEC
3/9/2022

Class Hierarchy (Contd.)
• A subclass inherits all of the properties
and methods (procedures) defined in its
superclass.
Motor Vehicle
Truck Car
Bus
19
VEC
3/9/2022

Inheritance
20
• Inheritance is a relationship between classes where one class is the parent class
of another (derived) class.
• Inheritance allows classes to share and reuse behaviors and attributes.
• Inheritance is a mechanism in which one object acquires all the properties and
behaviors of a parent object
• The real advantage of inheritance is that we can build upon what we already
have and, Reuse what we already have.
• Sub Class/Child Class: Subclass is a class which inherits the other class. It is also
called a derived class, extended class, or child class.
• Super Class/Parent Class: Superclass is the class from where a subclass inherits
the features. It is also called a base class or a parent class.
VEC
3/9/2022

3/9/2022 VEC 21
Programmer is the subclass and Employee is
the superclass.
The relationship between the two classes
is Programmer IS-A Employee.
It means that Programmer is a type of
Employee

3/9/2022 VEC 22

3/9/2022 VEC 23

Multiple Inheritance
24
• OO systems permit a class to inherit from
more than one superclass.
• This kind of inheritance is referred to as
multiple inheritance.
VEC
3/9/2022

Multiple Inheritance (Contd.)
• For example utility vehicle inherits from Car and
Truck classes.
MotorVehicle
Truck Car Bus
UtilityVehicle
25
VEC
3/9/2022

Encapsulation and Information
Hiding
• Information hiding is a principle of hiding internal
data and procedures of an object.
Messages
Data
Private Protocol
Public Protocol
Permissible operations
26
VEC
3/9/2022

Encapsulation and Information
Hiding (Contd.)
27
• By providing an interface to each object in
such a way as to reveal as little as possible
about its inner workings.
• Encapsulation protects the data from
corruption.
VEC
3/9/2022

A Case Study - A Payroll Program
28
• Consider a payroll program that processes
employee records at a small manufacturing
firm. This company has three types of
employees:
• 1. Managers: Receive a regular salary.
• 2. Office Workers: Receive an hourly wage and are
eligible for overtime after 40 hours.
• 3. Production Workers: Are paid according to a piece
rate.
VEC
3/9/2022

Structured Approach
29
FOR EVERY EMPLOYEE DO BEGIN
IF employee = manager THEN CALL
computeManagerSalary
IF employee = office worker THEN CALL
computeOfficeWorkerSalary
IF employee = production worker THEN
CALL computeProductionWorkerSalary
END
VEC
3/9/2022

What if we add two new types of
employees?
30
• Temporary office workers ineligible for
overtime,
• Junior production workers who receive an
hourly wage plus a lower piece rate.
VEC
3/9/2022

FOR EVERY EMPLOYEE DO BEGIN
IF employee = manager THEN CALL
computeManagerSalary
IF employee = office worker THEN CALL
computeOfficeWorker_salary
IF employee = production worker THEN CALL
computeProductionWorker_salary
IF employee = temporary office worker THEN CALL
computeTemporaryOfficeWorkerSalary
IF employee = junior production worker THEN CALL
computeJuniorProductionWorkerSalary
END
31
VEC
3/9/2022

An Object-Oriented Approach
• What objects does the application need?
– The goal of OO analysis is to identify objects
and classes that support the problem domain
and system's requirements.
– Some general candidate classes are:
– Persons
– Places
– Things
32
VEC
3/9/2022

Whataresome of the application’s
classes?
• Employee
• Manager
• Office Workers
• Production Workers
33
VEC
3/9/2022

Class Hierarchy
34
• Identify class hierarchy
• Identify commonality among the classes
• Draw the general-specific class hierarchy.
VEC
3/9/2022

36
Class Hierarchy (Contd.)
OfficeWorker Manager ProductionWorker
Employee
name address
salary SS#
dataEntry
ComputePayroll
printReport
dataEntry
Compute Payroll
printReport
dataEntry
ComputePayroll
printReport
VEC 35
3/9/2022

OO Approach
36
FOR EVERY EMPLOYEE DO
BEGIN
employee computePayroll
END
VEC
3/9/2022

If new types of employees were added…
O ff ic eW o rk e r M a n age r P rodu c tio n W orke
r
E m p loy e e
na m e
ad d res s sa la ry
SS#
d a ta E n try
C o m p u teP ay ro l l p
rin tR e p o r t
da ta E n t ry
C o m pu te P a y ro l l
prin t R e port
d a ta E n try
C o m p u teP ay ro l
l prin t R e port
T e m porary O ffic e W orke r
C o m p u teP ay ro ll
Ju n io rP rodu c tio n W orke r
C o m p u teP ay ro ll
37
VEC
3/9/2022

Polymorphism
38
• Polymorphism means that the same operation
may behave differently on different classes.
• Example: computePayroll
VEC
3/9/2022

Associations
39
• The concept of association represents
relationships between objects and classes.
• For example a pilot can fly planes.
VEC
3/9/2022

Associations (Contd.)
Pilot Planes
can fly
40
flown by
VEC
3/9/2022

Clients and Servers
41
• A special form of association is a client-
server relationship.
• This relationship can be viewed as one-way
interaction: one object (client) requests the
service of another object (server).
VEC
3/9/2022

Clients and Servers
(Contd.)
PrintServer Request for printing Item
42
VEC
3/9/2022

Objects and Persistence
43
• Objects have a lifetime.
• An object can persist beyond application
session boundaries, during which the object
is stored in a file or a database, in some file
or database form.
VEC
3/9/2022

UML OVERVIEW
• UML stands for Unified Modeling Language.
• UML is a standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems.
• UML is a pictorial language used to make software
blueprints.
• 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

GOALS OF UML
• 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 goal of UML can be defined as a simple
modeling mechanism to model all possible practical
systems in today’s complex environment.
• The system can be a software or non-software
system.

UML IN OBJECT-ORIENTED CONCEPTS
• UML can be described as the successor of object-
oriented (OO) analysis and design.
• UML is powerful enough to represent all the concepts
that exist in object-oriented analysis and design.
• 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.

CONCEPTUAL MODEL 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

BUILDING BLOCKS OF UML
The building blocks of UML can be defined as:
Things
Relationships
Diagrams

UML THINGS
Things are the most important building blocks of UML. Things can be −
1.Structural
2.Behavioral
3.Grouping
4.Relationship
1.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.

2.Behavioral Things
A behavioural thing consists of the dynamic parts of UML
models. Following are the behavioural things −
Interaction − Interaction is defined as a behaviour 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.
3.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.

4.Relationship
Relationship is another most important building block of UML. It shows
how the elements are associated with each other.
There are four kinds of relationships available.
1.Dependency
Dependency is a relationship between two things in which change in one
element also affects the other.
2.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.
3.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.
4.Realization
Realization can be defined as a relationship in which two elements are
connected. One element describes some responsibility, which is not
implemented and 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.
 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

UML - CLASS DIAGRAM
• Class diagram is a static diagram. It represents the static
view of an application. Class diagram is not only used for
visualizing, describing, and documenting different aspects
of a system but also for constructing executable code of
the software application.
• Class diagram describes the attributes and operations of a
class and also the constraints imposed on the system. The
class diagrams are widely used in the modeling of object-
oriented systems because they are the only UML
diagrams, which can be mapped directly with object-
oriented languages.
• Class diagram shows a collection of classes, interfaces,
associations, collaborations, and constraints. It is also
known as a structural diagram.

CLASS DIAGRAM
 Class diagrams are used to describe the structure of the system.
 Classes are the common structure and behaviour of a set of objects.
 Class diagrams describe the system in terms of objects, classes, attributes,
operations and their associations.
CLASS NAME
ATTRIBUTES
METHODS

Rules For Drawing Class Diagram
•The name of the class diagram should be meaningful to describe the aspect of the
system.
•Each element and their relationships should be identified in advance.
•Responsibility (attributes and methods) of each class should be clearly identified
•For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
•Use notes whenever required to describe some aspect of the diagram. At the end
of the drawing it should be understandable to the developer/coder.
•Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.

The following diagram is an example of an Order System of an application. It
describes a particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can have
multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().

Perspectives of Class Diagram
A diagram can be interpreted from various
perspectives:
• Conceptual: represents the concepts in the
domain
• Specification: focus is on the interfaces of
Abstract Data Type (ADTs) in the software
• Implementation: describes how classes will
implement their interfaces

Relationships between classes
A class may be involved in one or more relationships with other classes. A
relationship can be one of the following types:

OBJECT DIAGRAM
Object diagrams are dependent on the class diagram as they are derived
from the class diagram. It represents an instance of a class diagram. The
objects help in portraying a static view of an object-oriented system at a
specific instant.
The difference between the class and object diagram is that the class
diagram mainly represents the bird's eye view of a system which is also
referred to as an abstract view.
An object diagram describes the instance of a class. It visualizes the
particular functionality of a system.
Notation of an Object Diagram
OBJECT NAME
OBJECT ATTRIBUTES

Purpose of an object diagram
It is used to describe the static aspect of a system.
It is used to represent an instance of a class.
It can be used to perform forward and reverse
engineering on systems.
It is used to understand the behaviour of an object.
It can be used to explore the relations of an object and
can be used to analyze other connecting objects.

EXAMPLE OBJECT DIAGRAM
CAR

USE CASE DIAGRAMS
A use case diagram is used to represent the dynamic
behaviour of a system. It encapsulates the system's functionality by
incorporating use cases, actors, and their relationships. It models
the tasks, services, and functions required by a system/subsystem of
an application. It depicts the high-level functionality of a system
and also tells how the user handles a system.
PURPOSE:
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.

RULES AND TIPS FOR DRAWING USE
CASE DIAGRAMS
Rules:
• The name of an actor or a use case must be meaningful and relevant to the
system.
• Interaction of an actor with the use case must be defined clearly and in an
understandable way.
• Annotations must be used wherever they are required.
• If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.
Tips:
• 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.
• A use case diagram should describe at least a single module of a system.
• If the use case diagram is large, then it should be generalized.

Example of a Use Case Diagram

Example of a Use Case Diagram

Uses of use case diagrams
• Analyzing the requirements of a system.
• High-level visual software designing.
• Capturing the functionalities of a system.
• Modelling the basic idea behind the system.
• Forward and reverse engineering of a system using
various test cases.

UML Component Diagram
A component diagram is used to break down a large object-oriented system into
the smaller components, so as to make them more manageable.
It models the physical view of a system such as executables, files, libraries, etc.
that resides within the node.
It visualizes the relationships as well as the organization between the
components present in the system.
It helps in forming an executable system.
A component is a single unit of the system, which is replaceable and executable.
The implementation details of a component are hidden, and it necessitates an
interface to execute a function. I
t is like a black box whose behaviour is explained by the provided and required
interfaces.

SYMBOLS IN COMPONENT DIAGRAMS

STEPS FOR DRAWING COMP DIA
•Step 1: Figure out the purpose of the diagram and identify the
artifacts such as the files, documents etc. in your system or
application that you need to represent in your diagram.
•Step 2: As you figure out the relationships between the elements
you identified earlier, create a mental layout of your component
diagram
•Step 3: As you draw the diagram, add components first,
grouping them within other components as you see fit
•Step 4: Next step is to add other elements such as interfaces,
classes, objects, dependencies etc. to your component diagram
and complete it.
•Step 5: You can attach notes on different parts of your
component diagram to clarify certain details to others.

EXAMPLE

USES
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.

Sequence Diagram
 The Sequence diagram represents the flow of messages in the
system and is also termed as an event diagram.
 They capture the interaction between objects in the context of a
collaboration.
 Sequence Diagrams are time focus and they show the order of the
interaction visually by using the vertical axis of the diagram to
represent time what messages are sent and when.
 A sequence diagram shows an implementation of a scenario in the
system. Lifelines in the system take part during the execution of a
system.
 In a sequence diagram, a lifeline is represented by a vertical bar.
 A message flow between two or more objects is represented using a
vertical dotted line which extends across the bottom of the page.
 In a sequence diagram, different types of messages and operators are
used which are described above.
 In a sequence diagram, iteration and branching are also used.

Purpose of Sequence Diagram
 Model high-level interaction between active objects in a
system.
 Model the interaction between object instances within a
collaboration that realizes a use case.
 Model the interaction between objects within a
collaboration that realizes an operation.
 Either model generic interactions (showing all possible
paths through the interaction) or specific instances of a
interaction (showing just one path through the interaction).

Notations of a Sequence Diagram
Lifeline:
Actor:

Sequence Diagram for Vending Machine

The diagram shows these lifelines:
Vending Machine
Customer
Cup Feeder
Water Supply
Syrup Canister
These were the interactions between the lifelines:
Choose a drink
Show price
Add sugar
[is the chosen drink good with milk] Add milk
Insert money
Change due
Eject a cup
Drip the syrup for the chosen drink
Fill water
Drink completed notification

Benefits of a Sequence Diagram
• It explores the real-time application.
• It depicts the message flow between the different objects.
• It has easy maintenance.
• It is easy to generate.
• Implement both forward and reverse engineering.
• It can easily update as per the new change in the system.

UML Collaboration Diagram
The collaboration diagram is used to show the relationship
between the objects in a system.
Both the sequence and the collaboration diagrams represent
the same information but differently.
Instead of showing the flow of messages, it depicts the
architecture of the object residing in the system as it is based
on object-oriented programming.
 An object consists of several features.
Multiple objects present in the system are connected to each
other.
The collaboration diagram, which is also known as a
communication diagram, is used to portray the object's
architecture in the system.

Notations of a Collaboration Diagram
 Objects: The representation of an object is done by an object symbol with
its name and class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
 The object is represented by specifying their name and class.
 It is not mandatory for every class to appear.
 A class may constitute more than one object.
 In the collaboration diagram, firstly, the object is created, and then its class is specified.
 To differentiate one object from another object, it is necessary to name them.
 Actors: In the collaboration diagram, the actor plays the main role as it
invokes the interaction. Each actor has its respective role and name. In this,
one actor initiates the use case.
 Links: The link is an instance of association, which associates the objects
and actors. It portrays a relationship between the objects through which the
messages are sent. It is represented by a solid line. The link helps an object
to connect with or navigate to another object, such that the message flows
are attached to links.
 Messages: It is a communication between objects which carries
information and includes a sequence number, so that the activity may take
place. It is represented by a labeled arrow, which is placed near a link.

Steps for creating a Collaboration Diagram
1. Determine the behaviour for which the realization and
implementation are specified.
2. Discover the structural elements that are class roles, objects,
and subsystems for performing the functionality of
collaboration.
 Choose the context of an interaction: system, subsystem,
use case, and operation.
3. Think through alternative situations that may be involved.
 Implementation of a collaboration diagram at an instance
level, if needed.
 A specification level diagram may be made in the instance
level sequence diagram for summarizing alternative
situations.

Benefits of a Collaboration Diagram
 It mainly puts emphasis on the structural aspect of an interaction diagram,
i.e., how lifelines are connected.
 The syntax of a collaboration diagram is similar to the sequence diagram;
just the difference is that the lifeline does not consist of tails.
 The messages transmitted over sequencing is represented by numbering
each individual message.
 The collaboration diagram is semantically weak in comparison to the
sequence diagram.
 The special case of a collaboration diagram is the object diagram.
 It focuses on the elements and not the message flow, like sequence
diagrams.
 Since the collaboration diagrams are not that expensive, the sequence
diagram can be directly converted to the collaboration diagram.

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.
• In distributed systems, it models the distribution of the software across the
physical nodes.
• Many nodes are involved in the deployment diagram; hence, the relation
between them is represented using communication paths.

There are two forms of a deployment diagram.
 Descriptor form
 It contains nodes, the relationship between nodes and artifacts.
 Instance form
 It contains node instance, the relationship between node instances and
artifact instance.
 An underlined name represents node instances.
Following are the purposes of deployment diagram enlisted
below:
 To envision the hardware topology of the system.
 To represent the hardware components on which the software
components are installed.
 To describe the processing of nodes at the runtime.

Deployment Diagram notations
Deployment diagram consists of the following notations:
A node
A component
An artifact
An interface
An Artifact
An artifact represents the specification of a concrete real-world entity related
to software development. You can use the artifact to describe a framework
which is used during the software development process or an executable file.
Artifacts are deployed on the nodes. The most common artifacts are as follows,
Source files
Executable files
Database tables
Scripts
DLL files
User manuals or documentation
Output files

Steps To Create A Deployment Diagram
The steps below outline the major steps to take in creating a UML
Deployment Diagram:
Decide on the purpose of the diagram
Add nodes to the diagram
Add communication associations to the diagram
Add other elements to the diagram, such as components or
active objects, if required
Add dependencies between components and objects, if
required

Example of a Deployment Diagram

Uses of Deployment Diagram
Deployment diagrams can be used for the followings:
•To model the network and hardware topology of a system.
•To model the distributed networks and systems.
•Implement forwarding and reverse engineering processes.
•To model the hardware details for a client/server system.
•For modelling the embedded system.

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 basic purpose of activity diagrams is to capture the
dynamic behaviour of the system.
 It is also called object-oriented flowchart.
This UML diagram focuses on the execution and flow of the
behaviour of a system instead of implementation.
 Activity diagrams consist of activities that are made up of
actions that apply to behavioural modelling technology.

Components of an Activity Diagram
1. Activities
 The categorization of behaviour into one or more actions is termed as an
activity. In other words, it can be said that an activity is a network of nodes
that are connected by edges. The edges depict the flow of execution. It may
contain action nodes, control nodes, or object nodes.
 The control flow of activity is represented by control nodes and object
nodes that illustrates the objects used within an activity. The activities are
initiated at the initial node and are terminated at the final node.
ACTIVITY

2. Activity partition /swimlane:
 The swimlane is used to cluster all the related activities in one
column or one row.
 It can be either vertical or horizontal.
 It used to add modularity to the activity diagram.
 It is not necessary to incorporate swimlane in the activity
diagram. But it is used to add more transparency to the activity
diagram.

3. Forks
 Forks and join nodes generate the concurrent flow inside the
activity.
 A fork node consists of one inward edge and several outward
edges.
 It is the same as that of various decision parameters.
 Whenever a data is received at an inward edge, it gets copied
and split crossways various outward edges.
 It split a single inward flow into multiple parallel flows.

4. Join Nodes
 Join nodes are the opposite of fork nodes.
 A Logical AND operation is performed on all of the inward
edges as it synchronizes the flow of input across one single
output (outward) edge.
5. Pins
 It is a small rectangle, which is attached to the action
rectangle.
 It clears out all the messy and complicated thing to manage the
execution flow of activities.
 It is an object node that precisely represents one input to or
output from the action.

Activity Diagram Notations
Activity diagrams symbols can be generated by using the following notations:
1. Initial states: The starting stage before an activity takes place is depicted
as the initial state
2. Final states: The state which the system reaches when a specific process
ends is known as a Final State
3. State or an activity box
4. Decision box: It is a diamond shape box which represents a decision with
alternate paths. It represents the flow of control.

RULES
Following rules must be followed while developing an
activity diagram:
1) All activities in the system should be named.
2) Activity names should be meaningful.
3) Constraints must be identified.
4) Activity associations must be known.

Basic Activity Diagram

EXAMPLE FOR ACTIVITY DIAGRAM
Word Processor

USES
 Most commonly activity diagrams are used to,
 Model the workflow in a graphical way, which is easily
understandable.
 Model the execution flow between various entities of a system.
 Model the detailed information about any function or an
algorithm which is used inside the system.
 Model business processes and their workflows.
 Capture the dynamic behavior of a system.
 Generate high-level flowcharts to represent the workflow of
any application.
 Model high-level view of an object-oriented or a distributed
system.

Package diagrams
Package diagrams are structural diagrams used to show the
organization and arrangement of various model elements in the form of
packages.
 A package is a grouping of related UML elements, such as diagrams,
documents, classes, or even other packages.
Each element is nested within the package, which is depicted as a file
folder within the diagram, then arranged hierarchically within the
diagram.
Package diagrams are most commonly used to provide a visual
organization of the layered architecture within any UML classifier, such
as a software system.

Benefits of a package diagram
 A well-designed package diagram provides numerous benefits to those
looking to create a visualization of their UML system or project.
 They provide a clear view of the hierarchical structure of the various UML
elements within a given system.
 These diagrams can simplify complex class diagrams into well-ordered
visuals.
 They offer valuable high-level visibility into large-scale projects and
systems.
 Package diagrams can be used to visually clarify a wide variety of projects
and systems.
 These visuals can be easily updated as systems and projects evolve.

Basic Notations of a Package Diagram

Basic Components of a Package Diagram
• Package: A namespace used to group together logically related elements within a system. Each element
contained within the package should be a packageable element and have a unique name.
• Packageable element: A named element, possibly owned directly by a package. These can include events,
components, use cases, and packages themselves. Packageable elements can also be rendered as a rectangle
within a package, labelled with the appropriate name.
• Dependencies: A visual representation of how one element (or set of elements) depends on or influences
another. Dependencies are divided into two groups: access and import dependencies. (See next section for
more info.)
• Element import: A directed relationship between an importing namespace and an imported packageable
element. This is used to import select individual elements without resorting to a package import and without
making it public within the namespace.
• Package import: A directed relationship between and importing namespace and an imported package. This
type of directed relationship adds the names of the members of the imported package to its own namespace
• Package merge: A directed relationship in which the contents of one package are extended by the contents
of another. Essentially, the content of two packages are combined to produce a new package.

Dependency

Guidelines for Packages
1. Gather model elements with strong cohesion in one
package.
2. Keep model elements with low coupling in different
packages.
3. Minimize relationships, especially associations, between
model elements in different packages.
4. Namespace implication: an element imported into a
package does not "know" how it is used in the imported
package.

Steps
Step 1 - Identify the packages present in the system.
Step 2 - Identify the dependencies.
Step 3 - Finally, dependency to UI Framework is also mapped in
to the diagram which completes the Package Diagram.

Package Diagram Example