SEPM Unit 2 - Final

Software Design
UNIT II
S.Y. Semester IV
Software Engineering and Project Management- UNIT II 1

Syllabus – Unit II
SOFTWARE DESIGN
Abstraction, Modularity, Cohesion & Coupling, Scenario based modeling, SSAD ( ER
diagram, Data Flow Diagram DFD), OOAD (Unified Modeling Language UML). .
Static modeling
Class diagrams- Finding analysis and Design Classes, Object diagrams, Composite
structure diagrams, Package diagrams, Interfaces and Components, Deployment
Diagram,
Dynamic Modeling
Use case diagram, Activity diagram- Interaction & Interaction overview diagram,
sequence diagram, Timing diagram, Communication diagram, Advance state machine
diagram

SOFTWARE DESIGN
SOFTWARE DESIGN
• Abstraction, Modularity, Cohesion & Coupling,
• Scenario based modeling : it identifies the primary use cases for the proposed
software system or application, to which later stages of requirements modeling will
refer.
• SSAD ( ER diagram, Control Flow Diagram CFD , Data Flow Diagram DFD),
• OOAD (Unified Modeling Language UML)- Modeling Language (UML)- Introduction
to all Diagrams.

Software Design
• Software design is a process to transform user requirements into some
suitable form, which helps the programmer in software coding and
implementation.
• Software design usually involves problem solving and planning
a software solution. This includes both a low-level component
and algorithm design and a high-level, architecture design.
• It’s the next step after RE

Good design and Bad Design

What is a good design?
• A good design is focused.
• A good design is effective and efficient in fulfilling its purpose.
• It relies on as few external factors and inputs as possible, and
these are easy to measure and manipulate to achieve an
expected other output.
• A good design is always the simplest possible working solution.

Good Design vs Bad Design
Good Design Bad Design

1. Meets all technical 1. Meets only some technical
requirements requirements
2. Works all the time 2. Works initially but stops
working after a short time
3. Meets cost requirements 3. Costs more than it should
4. Requires little or no 4. Requires frequent
maintenance maintenance
5. Is safe 5. Poses a hazard to users
6. Creates no ethical dilemma 6. Raises ethical questions
Software Design Levels
• Software design yields three levels of results:
1. Architectural Design -
i. is the highest abstract version of the system and identifies the software as a
system with many components interacting with each other.
ii. “the process of defining a collection of hardware and software components and
their interfaces to establish the framework for the development of a computer
system.”
2. High-level Design-
i. Breaks the Architectural Design into less-abstracted view of sub-systems and
modules and depicts their interaction with each other.
3. Detailed Design-
i. deals with the implementation part of what is seen as a system and its sub-
systems
ii.It defines logical structure of each module and their interfaces to communicate
with other modules.

Architectural Design
• first level of the designing.
• is the greatest summarize edition of the system.
• Generally, this is a designing level where the designers obtain the idea
or thought of a suggested clarification domain or province.
High Level Design

• is the second level of the designing.
• splits the component into modules and subsystems.
• also represents their cooperation with each.
• Low Level Design
Low Level Design

• here the data structures and algorithms are designed for different modules.
• includes principal modules and sub modules relationships between them, and how the data
structures and algorithms are connected.
• The outcome in thisSoftware
stage Engineering and Project
is also known asManagement-
the moduleUNIT II
specification document. 10
Abstraction
• The principle of abstraction requires:
– lower-level modules do not invoke functions of higher level modules.
– Also known as layered design.
• High Level Design: High-level design maps functions into modules such that:
– Each module has high cohesion
– Coupling among modules is as low as possible
– Modules are organized in a neat hierarchy

Modularity
• Modularity is a fundamental attributes of any good design.
– Decomposition of a problem cleanly into modules:
– Modules are almost independent of each other
– Divide and conquer principle.
• If modules are independent:
– Modules can be understood separately,
– Reduces the complexity greatly.
– To understand why this is so,
– Remember that it is very difficult to break a bunch of sticks but very easy to break
the sticks individually.

Modularity
• A module ideally should have high cohesion and low coupling:
• Functionally independent of other modules to have minimal interaction with other
modules.
• Improves understandability and good design:
• Complexity of design is reduced as different modules are understood in isolation:
• A functionally independent module:
– Can be easily taken out and reused in a different program.
– Each module does some well-defined and precise function
– The interfaces of a module with other modules is simple and minimal.

Modularity
• In technical terms, modules should display:
– high cohesion
– low coupling.
• Cohesion is a measure of:
– Functional strength of a module.
– A cohesive module performs a single task or function.
• Coupling between two modules:
– A measure of the degree of interdependence or interaction between the two
modules.

Cohesion and Coupling

Cohesion and Coupling
Ideally good Software Design

will promote
Tight cohesion and Low
coupling
- Changes in the system

Transition from Analysis to Design
• Analysis: A process of extracting and organizing user
requirements and establishing an accurate model of the
problem domain.(WHAT)
• Design: Process of mapping requirements to a system

implementation that conforms to desired cost, performance,
and quality parameters.(HOW)

Transition from Analysis to Design
• Blurred line between analysis & design
• Process of design leads to better understanding of requirements
• Can be performed iteratively
• No direct & obvious mapping exists between structured analysis
and structured design.

Two Approaches for Analysis & Design
• Traditional Approach: SSAD(System Structured Analysis and Design)
• Structured Analysis (SA), resulting in a logical design, drawn as a set of data
flow diagrams
• Structured Design (SD) transforming the logical design into a program structure
drawn as a set of structure charts
• OOAD(Object Oriented Analysis and Design)

• Designing systems using self-contained objects and object classes

Structured Analysis
• Is a development method to understand the system and its activities in a logical way.
• It is a systematic approach that analyze and refine objectives of an system
• It has following attributes −
– It is graphic which specifies the presentation of application.
– It divides the processes so that it gives a clear picture of system flow.
– It is logical rather than physical
– It is an approach that works from high-level overviews to lower-level details.
• Structured Analysis Tools and techniques used for system development:
– Data Flow Diagrams
– Entity Relation Diagram
– Data Dictionary
– Decision Trees
– Structured English
– Pseudocode

Structured Analysis

Structured Analysis
• Data design transforms ERD (Entity
Relationship Diagram) in to data structures
• Architectural design - higher-level structure of
the system that depicts the relationship
between the modules of the system
• Interface design defines interaction of people
with the system
• Procedural design transforms the modules of
the system architecture in to
Pseudo-code or Flow Chart

SSAD Phases

Data Flow Diagrams
• The DFD (also known as a bubble chart) is a hierarchical graphical model of a system
that shows the different processing activities or functions that the system performs
and the data interchange among these functions.
• Each function is considered as a processing station (or process) that consumes some
input data and produces some output data.
• The system is represented in terms of the input data to the system, various
processing carried out on these data, and the output data generated by the system.

DFD Notations
S.N Name Description Notation Gane and Sarson
Yourdon and Coad
o
1 External An outside system that sends or receives data,
Entity communicating with the system being diagrammed.
They are the sources and destinations of information
entering or leaving the system eg. an outside organization or
person, a computer system or a business system. They are
also known as terminators, sources and sinks or actors.
They are typically drawn on the edges of the diagram.
2 Process Any process that changes the data, producing an output. It

might perform computations, or sort data based on logic, or
direct the data flow based on business rules
3 Data Files or repositories that hold information for later use, such
store as a database table or a membership form.
4 Data The route that data takes between the external entities,
flow processes and dataSoftware
stores.
Engineering and Project Management- UNIT II 25
Data-processing models
• Data flow diagrams are used to model the system’s data processing
• These show the processing steps as data flows through a system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can understand
• Show end-to-end processing of data

DFD
• A data flow diagram can dive into progressively more detail by
using levels and layers, zeroing in on a particular piece. DFD
levels are numbered 0, 1 or 2, and occasionally go to even
Level 3 or beyond.
– Level 0
– Level 1
– Level 2

DFD Levels
• Level 0: Context Diagram : high-level system processes or functions
and the data sources that flow to or from them. These are designed to
be simple, straightforward overviews of a process or system.
• Level 1: Process Decomposition : They are more detailed — they break
down the system’s single process node into subprocesses.
• Level 2: Deeper Dives :The next level of DFDs dive even deeper into
detail by breaking down each level 1 process into granular
subprocesses.
• Level3: Increasing Complexity : Level 3 and higher-numbered DFDs are
uncommon.
DFD- Level 0
• DFD Level 0 is also called a Context

Diagram.
• It’s a basic overview of the whole
system or process being analyzed or
modeled.
• It’s designed to be an at-a-glance view,
showing the system as a single high-
level process, with its relationship to
external entities.
• It should be easily understood by a
wide audience, including stakeholders,
business analysts, data analysts and
developers.

DFD- Level 1
• DFD Level 1 provides a
more detailed breakout of
pieces of the Context Level
Diagram.
• You will highlight the main
functions carried out by the
system, as you break down
the high-level process of the
Context Diagram into its
subprocesses.
DFD- Level 2
• DFD Level 2 then goes one step
deeper into parts of Level 1. It may
require more text to reach the
necessary level of detail about the
system’s functioning.

DFD rules, guidelines, and tips:
• Each process has at least one outgoing
data flow and at least one ingoing data
flow.
• Each process can go to any other symbol

(other processes, data store, and
entities).

• Each data store should
have at least one incoming
and at least one outgoing
data flow.
• Entities must be
connected to a process by
a data flow.
• Data flows cannot cross with each other.
• Data stores cannot be connected to external entities.
Otherwise, it means you’re allowing an external entity access to
your data files and stores.
• The labels of processes can be verb phrases. Data stores are
displayed by nouns.
• Data flows cannot run between two external entities without
going through a process (as you will see in the data flow
diagram examples below).
Example 1: Securities Trading Platform
• Level 0 : This Level 0 DFD provides a contextual map of a securities trading
platform. Data flows in one direction from the customer service assistant and the
broker to the platform, and in two directions from customers to the platform and
back again.
Securities Trading
Platform

Level 1 DFD 1. Open
Account
• This Level 1 DFD breaks

2. Check
down the customer Transacti
process in more detail, on
expanding it to include
account creation by CSA.
3.
Customer then do cash Deposit
withdrawals, deposit, Cash
check transaction, order
placing. It even accounts
for a third-party stock 4.Withdra
exchange center where w Cash
transaction details are
forwarded after an order
is placed. 5. Place
Order

Level 2 DFD
5.1 Place
Order
Level 2 DFD Online
decomposes the “Place

Order” process to
contextualize the steps
required to place an
order — either by a
customer or by a
broker. It even accounts
for a third-party stock
5.2 Place
exchange center where Order
transaction details are Phone
forwarded after an
order is placed.

Creating DFD

Example 2 : Safe home

Level 1

Level 2

Example 3: Payroll System
Time Keeping Cards Payroll Payment

machine System Employees
DFD Level 0

Example 3: Level 1 :Payroll System

Level 2 :Payroll System

What are the advantages of DFD ?
• A graphical technique that is relatively easy to understand for
stakeholders and other users.
• Provides a detailed view of the system components and
boundaries.
• Provide clear and detailed information about the processes
within a system.
• Shows the logic of the data flow.
• Presents a functional breakdown of the system.
• Used as a part of the system documentation.
Entity Relationship Diagrams
• An ERD shows the relationships of entity sets stored in a database.
– An entity in this context is an object, a component of data.
– An entity set is a collection of similar entities.
– These entities can have attributes that define its properties.
• ER diagram illustrates the logical structure of databases.
• ER diagrams are used to sketch out the design of a database.

ER Diagram Notations
• Entities : is an object or concept about which you want to store information.
• Actions, which are represented by diamond shapes, show how two entities
share information in the database.
• Attributes, which are represented by ovals. A key attribute is the unique,

distinguishing characteristic of the entity.
– A multivalued attribute can have more than one value. For example, an employee
entity can have multiple skill values.
– A derived attribute is based on another attribute. For example, an employee's
monthly salary is based on the employee's annual salary.
• Connecting lines, solid lines that connect attributes to show the relationships
of entities in the diagram.

Example 1
• Draw an ER diagram to show that shopper buys items.

Example 2
• Draw an ER diagram to show that a student registers for a
course. The course is taught by an Professor.

Example 2
• Draw an ER diagram to show that a student registers for a
course. The course is taught by Professor.

Example 3
• Draw ER diagram for : A student attends classes. Each class has many sections. The
student takes up a subject.

Example 3
• Draw ER diagram for : A student attends classes. Each class has many sections. The
student takes up a subject.

Object-Oriented Approach
• Views information system as collection of interacting objects that work
together to accomplish tasks
• OOA
• OOD
• OOP

OOAD : Object Oriented Analysis and Design
• Object-Oriented Analysis : Is the procedure of identifying requirements and developing
specifications by using interacting objects.
• It groups items that interact with one another, typically by class, data or behavior, to
create a model that accurately represents the system
• The focus is on capturing the structure and behavior of systems into small modules that
combines both data and process
• The primary tasks in object-oriented analysis (OOA) are −

– Identifying objects
– Organizing the objects by creating object model diagram
– Defining the internals of the objects, or object attributes
– Defining the behavior of the objects, i.e., object actions
– Describing how the objects interact
OOAD
• Object-Oriented Design: Involves implementation of the
conceptual model produced during object-oriented analysis
• The implementation details generally include −
– Restructuring the class data (if necessary),
– Implementation of methods, i.e., internal data structures and
algorithms,
– Implementation of control, and
– Implementation of associations.

OOAD methods
Three major steps:
1. Identify the objects
2. Determine their attributes and services
3. Determine the relationships between objects

4+1 View Model of Architecture
class diagrams, and state diagrams. Package diagram and Component diagram.
Programmer
End user Implementation
Logical view s
view & software
managers
Scenarios
Deployment
Process View
View
Integrator System deployment diagram.

sequence diagram, communication diagram, activity diagram. Engineer

Logical View
• The logical view, which is the object model of the design (when an object-oriented
design method is used)
Viewer: End-user
considers: Functional requirements- What are the services must be provided by the
system to the users.

Process View
The process view, which captures the concurrency and synchronization aspects of the
design (The process decomposition).
viewer: Integrators
considers: Non - functional requirements (scalability, concurrency, and performance)
• process view of a system encompasses the threads and processes that form the
system's concurrency and synchronization mechanisms.
• This view primarily addresses the performance, scalability, and throughput of the
system.
• With the UML, the static and dynamic aspects of this view are captured in the same
kinds of diagrams as for the design view, but with a focus on the active classes that
represent these threads and processes.
Implementation View
• The Implementation view/ Development View, which describes the static organization of the
software in its development environment. implementation view of a system encompasses the
components and files that are used to assemble and release the physical system.
• This view primarily addresses the configuration management of the system's releases, made
up of somewhat independent components and files that can be assembled in various ways to
produce a running system.
• With the UML, the static aspects of this view are captured in component diagrams;
• the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams,
and activity diagrams.
Viewer: Programmers and Software Managers

considers: software module organization.
(Hierarchy of layers, software management, reuse, constraints of tools).

Deployment View
• The Deployment view/ Physical view , which describes the mapping(s) of the software
onto the hardware and reflects its distributed aspect. deployment view of a system
encompasses the nodes that form the system's hardware topology on which the system
executes.
• This view primarily addresses the distribution, delivery, and installation of the parts that
make up the physical system.
• With the UML, the static aspects of this view are captured in deployment diagrams;
• the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams,
and activity diagrams.
Viewer: System Engineers

Considers: concerned with the topology of software components as well as the physical
connections between these components.
Scenarios
(Putting all “4 views” together +1 )
use case view
• encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and
testers.
• With the UML, the static aspects of this view are captured in use case diagrams;
• the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity
diagrams.
Viewer: All users and Evaluators.

Considers: description of architecture.
• Sequences of interactions between objects and processes are described in the scenarios.
• They are used to identify architectural aspects as well as to demonstrate and assess the design of the
architecture.
• They can also be used as a starting point for architecture prototype testing. The use case view is another
name for this view.
General Advantages
• Understandable
– maps the “real-world” objects more directly
– manages complexity via abstraction and encapsulation
• Practical
– successful in real applications
– suitable to many, but not all, domains
• Productive
– experience shows increased productivity over life-cycle
– encourages reuse of model, design, and code
• Stable
– changes minimally perturb objects
Unified Modeling Language (UML)
• UML (Unified Modeling Language) is a modeling language used by
software developers.
• UML can be used to develop diagrams and provide users with ready-
to-use, expressive modeling examples.
• Some UML tools generate program language code from UML.
• It's a rich language to model software solutions, application
structures, system behavior and business processes
• UML can be used for modeling a system independent of a platform
language.

What is UML?
• UML (Unified Modeling Language)
– An emerging standard for modeling object-oriented software.
– Resulted from the convergence of notations from three leading object-oriented
methods:
• OMT (James Rumbaugh)
• OOSE (Ivar Jacobson)
• Booch (Grady Booch)
• Reference: “The Unified Modeling Language User Guide”, Addison Wesley, 1999.
• Supported by several CASE tools
• Rational ROSE
• TogetherJ

What is UML contd…
• Unified modeling language (UML) for visualizing, specifying,

constructing, documenting of artifact of a software system
• The blueprint of a system is written in it
• UML is also used for modeling non-software system
• It is standard for building object oriented and component based
software system
• UML is a notation system though which we can visualize a model
of a system
• It describe only design or structure of system

Systems, Models and Views
• A model is an abstraction describing a subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting views
• Views and models of a single system may overlap each other
Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system

UML Concepts
• UML can be used to support your entire life cycle
– UML can be described as a general purpose visual modeling language
to visualize, specify, construct, and document software system.
– The interaction of your application with the outside world (use case
diagram)
– Visualize object interaction (sequence & collaboration diagrams)
– The structure of your system (class diagram)
– View the system architecture by looking at the defined package.
– The components in your system (component diagram)

UML 2.0 Diagrams
• UML is divided in to two General set of Diagrams
• Structured modeling diagrams
– It depicts the static view of the model
• Behavioral modeling diagram
– Behavior diagrams depicts the varieties of interaction within a model as it
'executes' over time

INTRODUCTION TO UML DIAGRAM.
•UML stands for Unified Modelling Language.
•UML is a standard language for specifying, visualizing, constructing, and
documenting a system in which software represents the most significant part.
•UML is different from the other common programming languages like C++, Java,
COBOL etc.
•UML is a pictorial language used to make software blue prints.
•UML can serve as a central notation for software development process. Using UML
helps project teams communicate, explore potential designs, and validate the
architectural designs of software.
•UML diagrams are made using notation of things and relationships.

INTRODUCTION TO UML DIAGRAM.
Analysis Design
Documentation UML Prototyping
Refactoring Code
Generation
Automated Tests

Structural Modeling Diagram(Static Design)
• Class Diagram
• Object Diagram
• Component Diagram
• Package Diagram
• Composite Structure
• Deployment Diagram
04/10/2024 Software Engineering and Project Management- UNIT II 74

Behavioral Modeling Diagram(Dynamic Design)
• Use Case Diagram
• Activity Diagram
• Sequence Diagram
• Timing Diagram
• Interaction Overview Diagram
• Communication Diagram
• State Machine Diagram

A CONCEPTUAL MODEL OF UML
Conceptual model: A conceptual model can be defined as a model which is made of
concepts and their relationships.
As UML describes the real time systems it is very important to make a conceptual model and
then proceed gradually. Conceptual model of UML can be better understood by learning the
following three major elements :
UML building blocks
Rules to connect the building
blocks Common mechanisms of
UML

STRUCTURAL THINGS
The Structural things define the static part of the model. They represent physical
and conceptual elements. Following are the brief descriptions of the structural things.
•Class: Class represents set of objects having similar responsibilities.
•Interface: Interface defines a set of operations which specify the responsibility of a
class.
• Collaboration: Collaboration defines interaction between things
•Use case: Use case represents a set of actions performed by a system for a
specific goal.
•Component: Component describes physical part of a system.
•Node: A node can be defined as a physical element that exists at run time.

Structural things

BEHAVIORAL THING
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.

RELATIONSHIP
Relationship is another most important building block of UML. It
shows how elements are associated with each other and this
association describes the functionality of an application.

Continued
• Dependency: Dependency is a relationship between two things in which change in
one element also affects the other one.
• Association: Association is basically a set of links that connects elements of an
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 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.

Why an extension mechanism?
• Although UML is very well-defined, there are situations in which it needs to

be customized to specific problem domains
• UML extension mechanisms are used to extend UML by:

- adding new model elements,
- creating new properties,
- and specifying new semantics
• There are three extension mechanisms:

- stereotypes, tagged values, constraints and notes
Stereotypes
• Stereotypes are used to extend UML to create new model
elements that can be used in specific domains
• E.g. when modeling an elevator control system, we may need to
represent some classes, states etc. as
– «hardware»
– «software»
• Stereotypes should always be applied in a consistent way

Stereotypes (cont.)
• Ways of representing a stereotype:
- Place the name of the stereotype above the name of an existing
UML element (if any)
• The name of the stereotype needs to be between «» (e.g. «node»)
• Don’t use double ‘<‘ or ‘>’ symbols, there are special characters called
open and close
- Create new icons Stereotyp
Stereotype
e
«button» in form of
CancelButton icon

state CancelButton
Tagged Values
• Tagged values
– Define additional properties for any kind of model elements
– Can be defined for existing model elements and for stereotypes
– Are shown as a tag-value pair where the tag represent the property and
the value represent the value of the property
• Tagged values can be useful for adding properties about
- code generation
- version control
- configuration management
- authorship

Tagged Values (cont.)
• A tagged value is shown as a string that is enclosed by
brackets {} and which consists of:
- the tag, a separator (the symbol =), and a value
Two tagged values

{author = “Bob”,
Version = 2.5}
Employee
name
address
Comments
• Comments are used to help clarify the models that are being created
- e.g. comments may be used for explaining the rationale behind some
design decisions
• A comment is shown as a text string within a note icon.
• A note icon can also contain an OCL expression Abstraction-occurrence

pattern
1..
Title * Copy

Static Modeling( static Design)
● Class diagrams
● Object diagrams
● Composite structure diagrams
● Package diagrams
● Component Diagram - Interfaces and Components
● Deployment Diagram

Class Diagram
• A class diagram depicts classes and their
interrelationships
• Used for describing structure and

behavior in the use cases
• Provide a conceptual model of the system

in terms of entities and their relationships
• Used for requirement capture, end-user

interaction
• Detailed class diagrams are useful for

software developers
Class Diagram
• Class diagrams are one of the most fundamental diagram types in UML.
• They are used to capture the static relationships of your software; in other
words, how things are put together
• A class represents a group of things that have common state and behavior.

Class Diagram
S.No Name Description Notation
1 Classes and They are used to show the different objects
interface in a system, their attributes, their
operations and the relationships among
them.
2 Object An object is an instance or occurrence of a Object: Class
class
3 Aggregation An aggregation describes a group of
objects and how you interact with them.
4 Composition Composition represents whole-part

relationships and is a form of aggregation.
5 Dependency Dependency relationship is a relationship

in which one element, the client, uses or
depends on another element, the supplier.
Class Diagram
3 Generalization Generalization is a relationship in which one
model element (the child) is based on another
model element (the parent).
4 Association Association is a relationship between two
classifiers, such as classes or use cases, that
describes the reasons for the relationship and the
rules that govern the relationship.
5 Multiplicity

Drawing a Class Diagram ?
• Identify and model classes—Which classes do we need?
• Identify and model associations—How are the classes
connected?
• Define attributes—What do we want to know about the
objects?

Depicting Classes
• When drawing a class, you needn’t show attributes and operation in every diagram.
Person
Person
Person
name : String
birthdate : Date
ssn : Id
Person
Person
name eat()
address sleep()
birthdate work()
eat
play play()

Class Diagram : Hotel Management System

Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.
There are four kinds of relationships in Class Diagram:
• Association
• Generalizations Window <<Interface>
• Dependency + open() : void >
AbstractWindow
Realization
• Realization + close() : void + open() : void
+ handleEvent(e: Event) : void + close() : void
Dependency
Generalizations
Event
Association
ConsoleWindow DialogBox Control

Association Relationships
• If two classes in a model need to communicate with each
other, there must be link between them.
• An association denotes that link.
Student Instructor

Association Relationships (Cont’d)
• Navigability of the association.
• Here, a Router object requests services from a DNS object by sending messages to
(invoking the operations of) the server.
• The direction of the association indicates that the server has no knowledge of the
Router.
Router DomainNameServer

• We can indicate the multiplicity of an association by adding multiplicity adornments to the line
denoting the association.
• Instance of one class interacting with the instance of another class
• The example
Student
indicates that a Student has one or more Instructors:1..* Instructor
The example indicates that every Instructor has one or more Students:
Student Instructor
1..*
⮲ Optional (0 or 1) 0..1
⮲ Exactly one 1 = 1..1
⮲ Zero or more 0..* = *
⮲ One or more 1..*
⮲ A range of values 2..6
• We can also indicate the behavior of an object in an association (i.e., the role of an object) using
rolenames.
learns from teaches
Student Instructor
1..* 1..*
We can also name the association.
membership
Student Team
1..* 1..*

• We can specify dual associations.
member of
1..* 1..*
Student Team
1 president of 1..*

• A class can have a self association.
next
LinkedListNode
previous

Association examples

103
Association: Model to Implementation
* 4
Student Course
has enrolls
Class Student {
Course enrolls[4];
}
Class Course {
Student have[];
}
Association - Aggregation
• A special form of association that models a whole-part relationship between an
aggregate (the whole) and its parts.
• Aggregation implies a relationship where the child can exist independently of the
parent. Example: Class (parent) and Student (child). Delete the Class and the Students
still exist.
• A hollow diamond is attached to the end of an association path on the side of the
aggregate (the whole) to indicate aggregation.
Eg.
1. An object is physically composed of other objects (e.g. car being physically
composed of an engine and four wheels).
2. An object is a logical collection of other objects (e.g., a family is a collection of
parents and children).
3. An object physically contains other objects (e.g., an airplane physically contains a
pilot). Software Engineering and Project Management- UNIT II 105
Association - Aggregation
Aggregation
⮲ This is the “Has-a” or “Whole/part” relationship
aggregation
Club Member
* *
:Car :Train
0..1 :Person 0..1
0..*
driver 1 passengers
aggregation
106
Association - Composition
● Composition
• Strong form of aggregation that implies ownership:
• if the whole is removed from the model, so is the part.
• the whole is responsible for the disposition of its parts

107
Association - Composition
• A form of aggregation with strong ownership and coincident lifetimes

⚫ The parts cannot survive the whole/aggregate
Composition implies a relationship where the child cannot exist independent of
the parent.
Whole Part
Schedule
Student
Composition
Aggregation and Composition
1 :Engine
composition <<part-of>>
:Locomotive 1..*
1 0..1
:Car :Train
0..1 :Person 0..1
0..*
driver 1 passengers
aggregation
<<has>>

109
Aggregation Composition
It exhibits a kind of weak relationship. It exhibits a strong type of relationship.
In an aggregation relationship, the In a composition relationship, the
associated objects exist independently even associated objects cannot exist
beyond the scope of the system. independently beyond the scope of the
system.
In this, the linked objects are independent Here the linked objects are dependent on
of each other. each other.
Deleting one element in the aggregation It affects the other element if one of its
relationship does not affect other associated associated element is deleted.
elements.
Example: A car needs a wheel for its proper Example: If a file is placed in a folder and
functioning, but it may not require the that is folder is deleted. The file residing
same wheel. It may function with another inside that folder will also get deleted at the
wheel as well. time of folder deletion.

Example
has 0..1
School Department
1 1..n 1..n
1..n 1..n
assignedTo
member
-chairperson
n 1..n 1..n 0..1
Student attends Course teaches Instructor

n n n 1..n

Generalization Relationships
Person
• A generalization connects a subclass

to its superclass.
It denotes an
• Inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
Student
of the more general superclass.

Generalization Relationships (Cont’d)
• UML permits a class to inherit from multiple superclasses, although some
programming languages (e.g., Java) do not permit multiple inheritance.
Student Employee
TeachingAssistant

Generalization/Specialization
• Generalization hierarchies may be created by generalizing from specific things or by
• specializing from general things.
More general element
“is a kind of”
More specific element

Inheritance
⮲ Class inheritance is implicit in a generalization relationship between classes.
⮲ Subclasses inherit attributes, associations, & operations from the superclass

Another Example

Example
• Draw a UML Class Diagram representing the following elements
from the problem domain for a hockey league.
• A hockey league is made up of at least four hockey teams.
• Each hockey team is composed of six to twelve players, and one
player captains the team.
• A team has a name and a record. Players have a number and a
position. Hockey teams play games against each other. Each game
has a score and a location. Teams are sometimes lead by a coach.
• A coach has a level of accreditation and a number of years of
experience, and can coach multiple teams. Coaches and players are
people, and people have names and addresses.
Example : Order Details

Benefits of class diagrams
• To understand the general overview of plan of an application.
• Illustrate data models for information systems, no matter how
simple or complex.
• Visually express any specific needs of a system
• Create detailed charts that highlight any specific code needed to be
programmed and implemented to the described structure.
• Provide an implementation-independent description of types used
in a system that are later passed between its components.

Object Diagram
• Derived from class diagram
• Shows a set of objects & their
relationship
• Represents a static view of the
system
• An object diagram is a diagram that
shows a set of objects and their
relationships at a point in time.
• Object diagrams help you capture
the logical view of your model
Object Diagrams
• An object is shown with a rectangle and the title is underlined
• Format is
– Instance name : Class name
– Attributes and Values
instantiated entry object is an

object instance of the
BlogEntry class
Links
• To show how objects work together, links shows
that two objects can communicate with each other
• There must be corresponding association between
the classes in the class diagram
• Can add label that indicates the purpose of the link,

Links and Constraints
• Links must keep to the rules (constraints) given in class
diagram.
Both diagrams are valid.

Eg. 2
• Draw Object diagram for the Order management
system . It has the following objects
» Customer
» Order
» SpecialOrder
» NormalOrder
• Customer object (C) is associated with three order

objects (O1, O2 and O3). These order objects are
associated with special order and normal order objects
(S1, S2 and N1). The customer is having the following
three orders with different numbers (12, 32 and 40) for
the particular time considered.
Example contd..

Example (contd..)

Example contd..

Reflexive / Self associations
subdirectory
0..* 1 0..*
Directory File
0..1
parent
reflexive association
autoexec
C
config
Windows My Documents Corel To John
Command
directories files
Multiplicity exercise
• How many Company
– Employees can a Company have? 1 employer
– Employers can a Person have?
– Owners can a BankAccount have? 7 employee
– Operators can a BankAccount have?

Person
– BankAccounts can a Person have?
owner 1 1..* operator
– BankAccounts can a Person operate?
0..* 0..*
BankAccount
Exercise
• Model a computer file system. Here are
the minimal facts you need:
– The basic unit of storage is the file
– Files live in directories
– Directories can contain other directories
• Use your own knowledge of a specific file
system (e.g. Windows 95 or UNIX) to
build a model
Hint: a class can have an association to itself!

Composite Structure Diagrams
• A composite structure diagram is a UML
structural diagram that contains classes,
interfaces, packages, and their relationships,
and that provides a logical view of all, or
part of a software system.
• It shows the internal structure (including
parts and connectors) of a structured
classifier or collaboration.
• A composite structure diagram performs a
similar role to a class diagram, but allows
you to go into further detail in describing the
internal structure of multiple classes and
showing the interactions between them.

Representation
• Composite Structure Diagrams show the internal parts of a class.
• Parts are named: partName:partType[multiplicity]
• Aggregated classes are parts of a class but parts are not necessarily
classes
• A part is any element that is used to make up the containing class.

Example- Car
• Below figure shows ,the composite structure diagram identifies the containing classifier,
Car.
• The diagram frame shows four internal composite parts of the containing classifier, which
represent the four wheels of the car and are of the type Wheel.
• A communication link connects the front wheels and the rear wheels with connectors
named frontaxle and rearaxle.

Part
• A part is an element that represents a set of one or more instances which are owned
by a containing classifier instance.
• If a diagram instance owned a set of graphical elements, then the graphical elements
could be represented as parts.
• A part is shown as an unadorned rectangle contained within the body of a class or
component element.
• Parts are owned by composition and the composite structure diagram models how
the parts are connected in the containing classifier. Each part is a specific usage of a
type.
Example : slide no.143

Port
• A port is a typed element that represents an externally visible part of a containing
classifier instance.
• Ports define the interaction between a classifier and its environment.
• A port can appear on the boundary of a contained part, a class or a composite
structure.
• A port may specify the services a classifier provides as well as the services that it
requires of its environment.
• A port is shown as a named rectangle on the boundary edge of its owning classifier.
140
Software Engineering and Project Management- UNIT II
Composite Structure Diagram
Part+port+interface

Example (CAR) contd.. .
• Two parts are typed with the classifier Wheel and the third is
typed by the classifier Engine. A straight line named Delegate
connector links the internal part named e:Engine to a port
on the external border of the composite structure diagram.
• The external port is typed with the classifier Car and is
named Port:Car. The connector has an open arrowhead that
points toward the external port.
• The two Wheel parts, named front:Wheel[2] and
rear:Wheel[2], are connected by straight lines named
Assembly connectors to the internal port named
Port:Engine.
• A port can interact in both directions and you can add required and
provided interfaces to specify the types of interactions that can occur
between a classifier and its environment.

Interfaces
All interface operations are public and abstract, and do not provide any default
implementation.
• All interface attributes must be constants.
• An interface, when standing alone in a diagram, is either shown as a class element
rectangle with the «interface» keyword and with its name italicized to denote it is
abstract, or it is shown as a circle.

Interfaces contd…
• An interface can be defined as either provided or required.
• A provided interface is shown as a "ball on a

stick" attached to the edge of a classifier
element.
• A required interface is shown as a "cup on a
stick" attached to the edge of a classifier
element.

Example (CAR) contd.. .
• The diagram displays a Car classifier that has one part,

named carSeat:Seat, and two ports.
• A port, named DriverSeatbelt:Seatbelt, appears on the
part and there is a circle connected to the top of the port
by a small straight line.
• The circle represents a provide interface named
SafetyDevice that the Car class offers to the driver to
operate the car.
• On the border of the composite structure diagram, a port,
named Engine:PowerGenerator, is attached by a solid line
to a half circle.
• The half circle represents a required interface named
Gasoline that the Car class needs to operate the car.
Example- Online Store
• Class Diagram • A class for Item
which may be
aggregated by the
Order class, which
is composed by
the Customer
class which itself is
composed by the
StoreManager
class.
• Here a lot of
objects that end
up within other
objects. 146
Example (contd..)
• Composite structure diagram for store
manager- StoreManager from its own
perspective, instead of the system as a
whole.
• StoreManager directly contains two
types of objects (Customer and Item)
as is indicated by the two composition
arrows on the class diagram(Previous
slide no. 150).
• Order is not directly contained within
the StoreManager class but we can
show relations to parts nested within
the objects it aggregates. Software Engineering and Project Management- UNIT II 147
References to External parts contd..
• The referencing an external object with Composite Structure Diagram.

• References to external objects are shown as a part with a dashed rectangle.
• Even though they reference object is outside of the class, the reference itself
is within the modeled class and is an important step in showing its
implementation.

Quiz 1
Identify Parts/ ports/

interfaces/
relationships of
composite structure
diagram

Example about interfaces
• Sort something:
Assuming that we have a set of albums, we want to sort them by title.
In Java, we have two ways to sort a set of albums.
1 .Each album or element of the list of items have to implement Comparable interface.
public class Album implements
Comparable<Album>
{ private String title;
public Album(String title)
{ this.title = title; }
Code public String getTitle()
{ return title; }
@Override
public int compareTo(Album o)
{ return
this.sortKey().compareTo(o.sortKey());
}
150
}
Example contd..
2. If we want to change sort functions dynamically, we can use Comparator interface.
public class Album { // ... }

public class SortByTitle implements
Comparator<Album>
{ @Override
public int compare(Album a1, Album a2)
Code { return a1.getTitle().compareTo(a2.getTitle());
}}
public static void main(String[] args)
{ String[ ] prefixes = {"an", "a", "the"};
Arrays.sort(prefixes, new SortByTitle());
}

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.
• Packages are depicted as file folders
and can be used on any of the UML
diagrams.

Package diagrams
• Package diagram is used to simplify complex class diagrams,
you can group classes into packages.
• A package is a collection of logically related UML elements.
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other
could possibly force changes in the first.
Package Notation
• Nested Packages can be represented shown
below:

Dependency Relationship
• Two stereotypes are used in dependency: <<import>> & <<access>>.
• <<import>> - one package imports the functionality of other package
• <<access>> - one package requires help from functions of other
package.

Package generalisation
• The more specialised child packages
Product
inherit the public and protected +Price
parent
elements in their parent package +Market
+Item
• Child packages may override -MicroMarket
elements in the parent package.

Both Hotels and CarHire packages Hotels CarHire
override Product::Item +Product::Price +Product::Price
+Product::Market +Product::Market
• Child packages may add new +Item +Item
+Hotel +Car
elements. Hotels adds Hotel and +RoomType
RoomType, CarHire adds Car

children
Finding Packages
• These are often discovered as the model matures
• We can use the natural groupings in the use case model to help
identify packages:
– One or more use cases that support a particular business process
or actor
– Related use cases
• Analysis classes that realise these groupings will often be part of the
same analysis package
Packages: guidelines
• A cohesive group of closely related classes
• Minimise dependencies between packages
• Minimise nesting of packages
• Refine package structure as analysis progresses
• 5 to 10 classes per package
Package Diagram Example - Layered Application

Package Diagram Example - Order Subsystem

• Order Processing System - The Problem Description

We are going to design package diagram for "Track Order" scenario for an online shopping store. Track
Order module is responsible for providing tracking information for the products ordered by customers.
Customer types in the tracking serial number, Track Order modules refers the system and updates the
current shipping status to the customer.
Steps
 Identify the packages of the system
o There is a track order module, it has to talk
with other module to know about the order
details, let us call it "Order processing".
o Next after fetching Order Details it has to know
about shipping details, let us call that as
"Shipping".
o Finally if knows the status of the order it has to
update the information to the user, let us call
this module as "UI Framework". Software Engineering and Project Management- UNIT II 161
Identify the dependencies in the System

• Track order should get order details from
"Order processing " and "Order processing
" has to know the tracking info given by
the customer.
• Two modules are accessing each other
which suffices <<access>> dual
dependency
• To know shipping information, "Shipping"
can <<import>> "Track Order" to make the
navigation easier.
• Finally, Track Order dependency to UI Framework is also mapped which completes our Package Diagram for Order
Processing subsystem. • <<access>> - one package requires help from functions of other package.
• <<import>> - one package imports the functionality of other package,

Component Diagram
• Component diagrams are used to model the physical
aspects of a system.
• Physical aspects are the elements such as executables,
libraries, files, documents, etc. which reside in a node.
• Component diagrams are used to visualize the
organization and relationships among components in a
system.
• Component diagrams can also be described as a static
implementation view of a system.
• Static implementation represents the organization of the
components at a particular moment.
• They show the organization and dependencies between
a set of components.
• It represents the software layout of the system

Basic Component Diagram Notations
• A component is a logical unit block of the system, a slightly higher abstraction than
classes.
• Dependencies

Basic Component Diagram Symbols and Notations
• An interface (small circle or semi-circle on a stick) describes a group of operations

used (required) or created (provided) by components.
• A full circle represents an interface created or provided by the component. A semi-
circle represents a required interface, like a person's input.
Software Engineering
Software Engineering and
andProject
ProjectManagement-
Management-UNIT II II
UNIT 166
Component Views
• UML uses two views of components, a black-box view and a white-

box view.
• The black-box view shows a component from an outside

perspective;
• The white-box view shows how a component realizes the

functionality specified by its provided interfaces.

Black-Box View
• The black-box view of a component shows its required interfaces, its provided
interfaces, and how it relates to other components.
• It does not specify anything about the internal implementation of the component.

White Box view
• In order to provide details about

the implementation of a
component, UML defines a white
box view.
• The white-box view shows exactly
how a component realizes the
interfaces it provides.
• This is typically done using
classes ,interfaces, and other
components help a component
achieve its functionality.Software Engineering and Project Management- UNIT II 169
Detailed Realization

Component Diagram - Order Processing System
• The Figure below is a much larger view of what is involved in a online store.
• By using a component diagram we see the system as a group of nearly independent
component or subsystems that interact with each other in a specifically defined way.
• Each component is responsible for the action for which it is named and interface(s) it provides.
• As long as those requirements are maintained changes to one component will not percolate to
other components.

Component diagram – Ticket selling system
• There is a ticket seller component that sequentializes requests from both ticket
selling system and clerks.
• A component that processes credit card charges; and the database containing the
ticket information.

Component diagrams vs Composite structure diagrams
• Component diagrams show components and their

relationships. A component is a special kind of class.
• A component diagram shows the components like car,
wheel, and engine and their relationships - Car has a
composition association Wheel and another composition
association with Engine.
• Car has a 1:4 composition association with Wheel and 1:1
composition association with Engine and engine has a 1:2
association with Wheel.
• The engine has an association with Wheel (since an engine
drives the two front wheels). To specify that the engine is
connected to the two front wheels, you will need to write
OCL constraints

Component diagrams vs Composite structure diagrams
• A composite structure diagram shows the parts
contained within another part and the links
between these parts.
• This diagram shows the Engine and the four
Wheels as separate blocks inside the Car
component.
• Now it is easy to show how the Engine is
connected to the front Wheels of the same car.
.

Deployment Diagram
• Deployment diagrams are used for

modeling configuration of run-time
processing nodes and the
components that live on them.
• Deployment diagrams are used to
model the static deployment view
of a system.
• This involves modeling the topology
of the hardware on which the
system executes.

Deployment Diagram
• Deployment diagrams Show the physical relationship between hardware and software in
a system
o Hardware elements
o Computers (clients, servers)
o Embedded processors
o Devices (sensors, peripherals)
are used to show the nodes where software components reside in the run-time system

Deployment diagram of embeded system

Deployment diagram of TCP/IP

Example:

Deployment Diagram
server:HostMachine <<database>>
meetingsDB
:Scheduler reservations
<<direct channel>>
clientMachine:PC
:Planner
Deployment diagram of a client-server system.

Sample Communication Links

Example: Client-Server System
• Human resource system client
• 2 pkgs: client, server

• Client: 2 nodes console
– console and kiosk
– stereotyped, distinguishable kiosk
• Server: 2 nodes server

– caching server and server 4..*
2..*
– Multiplicities are used <<processor>> <<processor>>
Caching server server
Deploys
Deploys
dbadmin.exe
Http.exe tktmstr.exe
rting.exe logexc.exe

Deployment diagram
• Purpose of Deployment Diagrams
✔ They show the structure of the run-time system
✔ They capture the hardware that will be used to implement the system and the links
between different items of hardware.
✔ They model physical hardware elements and the communication paths
between them
✔ They can be used to plan the architecture of a system.
✔ They are also useful for Document the deployment of software components
or nodes
Software Engineering and Project Management- UNIT

II
Dynamic Modeling ( Behavioral Diagrams)
● Use case diagram

● Activity diagram
● Interaction : sequence diagram, Timing diagram , Interaction
overview diagram
● Communication diagram
● State machine diagram

Use Case Diagram
• A use case diagram describes how a system
interacts with outside actors
• It is a graphical representation of the
interaction among the elements and system
• Each use case represents a piece of
functionality that a system provides
• The use case diagram allows for the
specification of higher level user goals
• A use case diagram contains four components
– The boundary
– The actor
– The use case
– The relationship between and among the actors and
the use cases

Use Case Diagram
• Use case is one way of representing system functionality.
• Use case refers to

• A system’s behavior (functionality)
• A set of activities that produce some output.
• Think in terms of main processes happening in the system.
In the simplest form, use case is a list of functions for a user;
• Use verbs for naming use cases.

Use Case Diagram
1 System Boundary The scope of a system can be represented
by a system boundary
2 Use case A sequences of actions (it must be a verb)

PurchaseTicket
3 Actor User (or) someone / something outside the

system that interacts with the system (it
must be a noun)
4 Association It corresponds to a sequence of actions

between the actor and use case
5 Generalization Inheritance relationship between model

elements of same type

Use Case Diagram
6 Include It specifies how the behavior of the <<include>>
inclusion use case is inserted into the
behavior defined for the base use case
7 Extend How the behavior of the extension use <<extend>>

case can be inserted into the behavior
defined for the base use case
9 Note Note is generally used to write comment in

use case diagram

Actors

Actors
Use cases
• Identifying use cases

- List all the actors
- Consider how each actor is going to use the system & obtain
list of use cases
- Each use case must be given a verb phrase
Use Case Diagram for ATM

Use case diagram
Actor generalization
Actor generalization factors out behavior common to two or more actors into
a parent actor
Use case generalization
• Factors out behavior common to one or more use cases into
a parent use case
Use of Extend stereotype between Use Cases
• Extends – linking an optional use case to a standard use case.
• Example: Register Course (standard use case) may have Register for Special
Class (extend use case).
• Standard use case can execute without the extend case i.e. loose coupling

University Registration System
Careful: Arrows between Use Cases

Software Engineering and Projectare NOT data
Management- UNIT II flows! 198
Use of Include stereotype between Use Cases
• Include stereotype – a standard case linked to an mandatory use case.

Example: to Authorize Car Loan (standard use case), a clerk must run Check
Client’s Credit History (include use case).
• Standard use case can not execute without the include case i.e
tight coupling

Extend Relation between Use Cases
• Credit Card Processing
Careful: Arrows between Use Cases

Software Engineering and Projectare NOT data
Management- UNIT II flows! 200
Extend and Include(Stereotype)

Use Case Example
• Login:
– Captcha
– Password
– Answer Secret Questions
• Log out

Example : Login

Use Case Diagram for Website Use Case
• Consider the User and Webmaster
• User can login, browse and search document.
– Download is also possible
– User can view event only if he is logged in
• Webmaster is responsible for adding user, uploading
documents and posting events .
– Uploaded documents have to be put in folders
– When a User is added , the Company is also added

Use Case Diagram for Website Use Case
<<include>>

Hints & tips for writing use cases
• Keep use cases short and simple

– Verb or verb phrases
– Short & descriptive
– Words of the use case name run together & each starts
with an uppercase letter eg. PaySalesTax
• Focus on the what not the how

• Avoid functional decomposition
Avoid functional decomposition
• Common error is to create set of high level use cases & then
break these down into a set of lower level use cases detailed
enough to implement
Activity Diagram
• It shows the structure of a process
• Supplements the use-case by
providing a diagrammatic
representation of procedural flow
• Shows flow of control from activity to
activity
• Main Components of activity diagram
– Action
– Activity Node
– Branching
– Forking & Joining

Activity Diagram
• Describes how activities are coordinated.
• Is particularly useful when you know that an operation has to achieve a
number of different things, and you want to model what the essential
dependencies between them are, before you decide in what order to do
them.
• Records the dependencies between activities, such as which things can
happen in parallel and what must be finished before something else can
start.
• Represents the workflow of the process.

Activity Diagrams
• Normally employed in business process modelling.
• An activity diagram visually presents a series of actions or flow
of control in a system similar to a flowchart or a data flow
diagram.
• Activity diagrams are often used in business process modeling.
• They can also describe the steps in a use case diagram.
• Activities modeled can be sequential and concurrent.
• In both cases an activity diagram will have a beginning (an
initial state) and an end (a final state).
Activity diagram Notations

Transitions
• When the action or activity of a state completes, flow of control

passes immediately to the next action or activity state
• A flow of control has to start and end someplace
– initial state -- a solid ball
– stop state -- a solid ball inside a circle

Branching
• A branch specifies alternate paths

taken based on some Boolean
expression
• A branch may have one incoming
transition and two or more outgoing
ones

Activity Diagram (Contd..)
• Forking & Joining:
• Fork: Splitting of single flow of control into 2 or concurrent
flow of control
• Join: Synchronization of 2 or more concurrent flow of control

Activity Diagram Example
- To show concurrent activity, Fork/Branch
activity diagrams allow

branches and joins.
- You can also reference or

include other activity
diagrams
Join

Example 1 :

Swimlanes
• A swimlane specifies a locus of activities
• To partition the activity states on an activity diagram into groups
– each group representing the business organization responsible for those
activities
– each group is called a swimlane
• Each swimlane is divided from its neighbor by a vertical solid line.Each
swimlane has a name unique within its diagram
• Each swimlane may represent some real-world entity
• Each swimlane may be implemented by one or more classes
• Every activity belongs to exactly one swimlane, but transitions may cross lanes
Swimlane Diagrams

Example 2 : Food Ordering
Processing with Swimlanes

Bank
Example 3: ABC Bank with

swimlanes

State Machine Diagram
• A state diagram describes the behavior of a
system, some part of a system, or an individual
object.
• At any given point in time, the system or object is

in a certain state.
—Being in a state means that it will behave in a
specific way in response to any events that occur.
• Some events will cause the system to change state.

—In the new state, the system will behave in a
different way to events.
State diagrams are good for modeling the lifetime of an object or actor, also for modeling business processes which
involve many states.
04/10/2024 223
State Machine Diagrams
• Classes can have interesting dynamic behavior - state machines can be used to model this
behaviour
• A state machine models dynamic behavior of a reactive object
• A state machine models the life cycle history of a single reactive object as a finite state machine –
a machine that can exist in finite number of states
• The machine makes transitions between these states in response to events
• 3 key elements:
– State – a condition or situation during life of an object during which it satisfies some condition
, performs some activity or waits for some event
– Event – specification of a noteworthy occurrence that causes transition
– Transition – the movement from one state to another in response to an event
State machine diagrams
light bulb
state = off turnOn
Off On
turnOff
burnOut
Off On  We begin with the light

bulb in the state off
Light bulb turnOn
light bulb
State = off turnOn
Off On
turnOff
burnOut
Event =
turnOn
Off On • We throw the switch to

On and the event turnOn
is sent to the lightbulb
Light bulb On
light bulb
State = on turnOn
Off On
turnOff
burnOut
Off On  The light bulb turns on

Light bulb turnOff
light bulb
State = on turnOn
Off On
turnOff
burnOut
Event =
turnOff
Off On  We turn the switch to Off. The event turnOff is

sent to the light bulb
Light bulb Off
light bulb
state = off turnOn
Off On
turnOff
burnOut
Off On  The light bulb turns off

States
• "A condition or situation during the life
of an object during which it satisfies
some condition, performs some activity How many states?
or waits for some event“ Color
• The state of an object at any point in red : int

green : int
time is determined by: blue : int
– The values of its attributes
– The relationships it has to other objects
– The activities it is performing
States
• Incase of bulb every change to any one of the atoms or
subatomic particles constitutes a new state
• This gives us infinite number of states which are virtually
identical
• Identify the states that make a difference to the system for
successful state modeling
A state has several parts.
1. Name -A textual string that distinguishes the state from other states; a state
may be anonymous, meaning that it has no name
2. Entry action - Upon each entry to a state, a specified action is automatically
executed.
.
• Syntax (to be placed inside the state symbol): entry / action
3. Exit action - Just prior to leaving a state, a specified action is automatically
executed.
• Syntax (to be placed inside the state symbol): exit / action
4. Internal Transitions - The handling of an event without leaving the current
state.
• Used to avoid a states entry and exit actions.
• Syntax (to be placed inside the state symbol): event / action
5. Activities - Ongoing work that an object performs while in a particular state.
The work automatically terminates when the state is exited.
• Syntax (to be placed inside the state symbol): do / activity
operations
6. Deferred Event - An event whose occurrence is responded to at a later time.
• Syntax (to be placed inside the state symbol): event / defer
04/10/2024 232
State syntax
• Actions are instantaneous and
uninterruptible state name EnteringPassword
– Entry actions occur
immediately on entry to the entry/display password dialog
entry and exit
state actions exit/validate password
– Exit actions occur
immediately on leaving the internal
keypress/ echo "*"
state transitions help/display help
• Internal transitions occur internal do/get password
within the state. They do not activity
transition to a new state
• Activities take a finite amount
of time and are interruptible
Transitions
behavioral state machine
event1, event2 [guard condition] / act1, act2

A B
events Boolean actions
guard condition
On (event1 OR event2) if (guardCondition is true) then

perform anAction and immediately enter state B.”
Branching – the choice pseudo state
• The choice Loan
pseudo state
directs its single Unpaid
incoming choice
acceptPayment
transition to one pseudo-state
of its outgoing [payment = balance] [payment < balance]
transitions acceptPayment
[payment > balance]
• Each outgoing makeRefund
FullyPaid OverPaid PartiallyPaid
transition must
have a mutually
exclusive guard
condition
State Machine Diagram Elements
1. A State
Represents the state of object at an instant of time
Situation during the life of an object in which it satisfies some condition, performs some activity,
or waits for some event.
A state may include:
• Name
• Entry/exit actions
• Internal transitions
• Activities
• Substates
2. Initial state - indicates the initial starting state for the

state machine or a substate.
3. Final state - indicates the state machine’s execution has

completed.
04/10/2024 236
4. Transitions
• 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 conditions are satisfied.
• On such a change of state, the transition is said to fire.
• Until the transition fires, the object is said to be in the source state; after it fires, it is said to be in the
target state.
5. Event /Trigger
• Trigger" is the cause of the transition, which could be a signal, an event, a change in some condition, or
the passage of time.
• "Guard" is a condition which must be true in order for the trigger to cause the transition.
• "Effect" is an action which will be invoked directly on the object that owns the state machine as a result
of the transition.
04/10/2024 237
Advanced States
1. Simple state - A state that contains
no substates.
2. Composite state - A state that
contains substates.
3. Substate - A state that is nested
inside another state.
• Substates allow state diagrams to
show different levels of abstraction.
• Substates may be sequential or
concurrent.
• Substates may be nested to any
level.
04/10/2024 238
• Compound States - A state machine diagram may include sub-machine diagrams, as in the
example below.
Alternative way to show the same information
indicates that details of

the Check PIN sub-
machine are shown in
a separate diagram.
04/10/2024 239
• Choice Pseudo-State - A choice pseudo-state is shown as a diamond with one transition arriving and two
or more transitions leaving.
The following diagram shows that whichever state is arrived at, after the choice pseudo-state, is
dependent on the message format selected during execution of the previous state.
04/10/2024 240
• Junction Pseudo-State - Junction pseudo-states are used to chain together multiple transitions.
A single junction can have one or more incoming, and one or more outgoing, transitions;
a guard can be applied to each transition.
A junction which splits an incoming transition into multiple outgoing transitions realizes a static
conditional branch
04/10/2024 241
• Concurrent Regions - A state may be divided into regions containing substates that exist and execute
concurrently.
• Terminate Pseudo-State - Entering a terminate pseudo-state indicates that the lifeline of the state machine
has ended. A terminate pseudo-state is notated as a cross.
04/10/2024 242
Example to Understand
The state machine diagram shows the states that a door goes through during its lifetime.
• The door can be in one of three states: "Opened", "Closed" or "Locked".
• Notice that not all events are valid in all states;
Example: if a door is opened, you cannot lock it until you close it.
• Also notice that a state transition can have a guard condition attached
Example: if the door is Opened, it can only respond to the Close event if the condition
04/10/2024
doorWay->isEmpty is fulfilled. 243
Example: Stages of a Patient
04/10/2024 244
Example with conditions
04/10/2024 245
Example with conditional transitions
04/10/2024 246
Example with entry/exit actions
04/10/2024 247
Example: Concurrent Regions
04/10/2024 248
Example: Bank ATM
04/10/2024 249
Example: Purchase Order
04/10/2024 250
Example: Drive Vehicle
04/10/2024 251
State Machine Diagrams- Example of Transition of states

Terms and Concepts
• Advanced States and Transitions
– History States - Allows an object to remember which substate was last active when the
containing state was exited.
• Upon re-entry to the containing state, the substate that was last active will be re-
entered directly.
253
Advance State Diagram – Example Phone Call
254
State Machine Diagram VS Activity Diagram
• State machines can be used to map out the various states and
transitions within a system.
• Activity diagrams can illustrate how these states and
transitions tie into the overall process flow.
• This complementary use of state machines and activity
diagrams can help visualize complex workflows in different
stages of software development or process design, enabling a
more thorough understanding and control of the system's
behavior.
Interaction diagram
• Interaction diagrams
– Sequence Diagram:
• Dynamic behavior of a set of objects
arranged in time sequence, new objects
added to the right
• Good for real-time specifications and
complex scenarios
• Derived from use case scenario
– Collaboration/Communication
Diagram :
• Shows the relationship among objects.
Does not show time
• Objects are arranged in a graph or
network format
UML Sequence Diagrams
• Sequence diagrams model the dynamic
aspects of a software system
• The emphasis is on the “sequence” of
messages rather than relationship
between objects
• Sequence diagrams provide more detail
and show the messages exchanged
among a set of objects over time.
• The main purpose of this diagram is to
represent how different business
object interacts

• Used during requirements analysis
– To refine use case descriptions
– to find additional objects (“participating objects”)
• Used during system design
– to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
• Lifelines are represented by dashed lines

1 Class Roles or Class roles describe the way

Participants an object will behave in
context
2 Activation or Activation boxes represent

Execution the time an object needs to
Occurrence/ complete a task.
Scope
3 Diagram
Boundry

3 Messages Messages are arrows that

represent communication
between objects.
4 Lifelines Lifelines represent either

roles or object instances that
participate in the sequence
being modeled.

UML Sequence Diagrams- Types of Messages in Sequence Diagrams
5 Synchronous Message A synchronous message requires a
response before the interaction can
continue.
6 Asynchronous Asynchronous messages don't need
Message a reply for interaction to continue.
7 Reply or Return A reply message is drawn with a

Message dotted line and an open arrowhead
pointing back to the original lifeline.
8 Self Message A message an object sends to itself,

usually shown as a U shaped arrow
pointing back to itself.

Importance of Sequence Diagrams
• Depict object interactions in a given scenario identified for a given Use
Case
• Specify the messages passed between objects using horizontal arrows
including messages to/from external actors
• Time increases from Top to bottom
• Sequence diagrams are good at showing which objects communicate
with which other objects and what messages trigger those
communications.
• Sequence diagrams are not intended for showing complex procedural
logic..
Sequence Diagram of sale scenario
Process Sale Scenario

: Cashier :System
makeNewSale
Simple cash-only Process Sale scenario:
loop [ more items ]
1. Customer arrives at a POS checkout enterItem(itemID, quantity)
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier. description, total
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done. endSale
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and total with taxes
asks for payment.
7. Customer pays and System handles
payment. makePayment(amount)
...
change due, receipt

Sequence Diagram Lifelines
• A lifeline represents an individual participant in a sequence diagram. A
lifeline will usually have a rectangle containing its object name.
• If its name is self then that indicates
that the lifeline represents the
classifier which owns the
Sequence diagram..

Sequence Diagram Messages
• Messages are displayed as arrows. Messages can be complete, lost or found;
synchronous or asynchronous; call or signal.
• In the following diagram, the first message is a synchronous message (denoted by
the solid arrowhead) complete with an implicit
return message; the
• second message is asynchronous
(denoted by line arrowhead) and the
• third is the asynchronous return message
(denoted by the dashed line).

Sequence Diagram Execution Occurrence
• A thin rectangle running down the lifeline denotes the
execution occurrence or activation of a focus of control.
• In the previous diagram, there are three execution
occurrences. The first is the source object sending two
messages and receiving two replies;
• The second is the target object receiving a synchronous
message and returning a reply; and the third is the target
object receiving an asynchronous message and returning a
reply.
Diff types of messages in Sequence diagram
• Synchronous msg
• Asynchronous msg
• Lost
• Found msg
• Return
• Self msg
• Create msg
• Destroy msg
Sequence Diagram :Found Messages
• Found messages are those that arrive

from an unknown sender, or from a
sender not shown on the current
diagram.
• They are denoted going to or coming
from an endpoint element.

Example
• Consider the scenario of a hardware failure.

Sequence Diagram :Lost message
• A Lost message is used to represent a
scenario where the recipient is not known
to the system.
• It is represented using an arrow directed
towards an end point from a lifeline
• Consider a scenario where a warning is
generated.
• The warning might be generated for the
user or other software/object that the
lifeline is interacting with.
• Since the destination is not known before
hand, we use the Lost Message symbol.

Sequence Diagram: Self Message
• A self message can represent a
recursive call of an operation, or
one method calling another
method belonging to the same
object.
• It is shown as creating a
nested focus of control in
the lifeline’s execution
occurrence.

Sequence Diagram: Create Message
Typically we use the language independent create message, instance creation :

Sequence Diagram: Destroy Message
Object Lifelines and Object Destruction We may show the explicit destruction of an object .

Sequence Diagram Combined Fragments
• A combined fragment is one or more processing sequence
enclosed in a frame and executed under specific named
circumstances.
• They are also known as Frames in UML Sequence Diagrams
• It allows the visualization of complex algorithms, sequence
diagrams support the notion of frames

Sequence Diagram Example

Typical frame operators are:
Interaction Semantics
Operator
alt Alternative fragment for mutual exclusion conditional logic expressed in the
guards. if…then…else
opt Optional fragment that executes if guard is true. switch constructs.
loop Loop fragment while guard is true. loop(n) to indicate looping n times.
region Critical region within which only one thread can run.
par Parallel fragments that execute in parallel. concurrent processing
Break break represents a breaking or exceptional scenario that is performed
Consider consider defines which messages should be considered within this combined
fragment
Ignore Ignore message types can be considered insignificant and are implicitly ignored if
they appear in a corresponding execution.

Alternative
• The interaction operator alt means that the combined fragment
represents a choice or alternatives of behavior.
• At most one of the operands will be chosen.
• The chosen operand must have an explicit or implicit guard
expression that evaluates to true at this point in the interaction.
• An implicit true guard is implied if the operand has no guard.
• An operand guarded by else means a guard that is the negation
of the disjunction of all other guards.

Alternative : example
Call accept() if balance > 0, call reject() otherwise.

Optional
• The interaction operator opt means that the combined
fragment represents a choice of behaviour where either the
(sole) operand happens or nothing happens (Switch- case)
• An optional is semantically equivalent to an alternative
combined fragment where there is one operand with non-
empty content and the second operand is empty.

optional : example
Post comments if there were no errors.

Loop
• The interaction operator loop means that the combined fragment
represents a loop.
• The loop operand will be repeated a number of times. The loop construct
represents a recursive application of the seq operator where the loop
operand is sequenced after the result of earlier iterations.
• Loop could be controlled by either or both iteration bounds and a guard.
• Loop operand could have iteration bounds which may include a lower
and an upper number of iterations of the loop.
• If loop has no bounds specified, it means potentially infinite loop with
zero as lower bound and infinite upper bound.
Loop: Example 1

282
Example 2

Break
• The interaction operator break represents
a breaking or exceptional scenario that is
performed instead of the remainder of the
enclosing interaction fragment.
• A break operator with a guard is chosen
when the guard is true.
• When the guard of the break operand is
false, the break operand is ignored and the
rest of the enclosing interaction fragment
proceeds.
Parallel
• The interaction operator par defines
potentially parallel execution of
behaviour of the operands of the
combined fragment.
• Different operands can be interleaved
in any way as long as the ordering
imposed by each operand is
preserved.

Strict sequencing
• The interaction operator strict requires a
strict sequencing (order) of the operands
on the first level within the combined
fragment.
• Operands of lower levels within the
contained combined fragment will not
directly be compared with other
occurrence specifications of the enclosing
combined fragment.
Search Google, Bing and Yahoo in the strict
sequential order.

Weak Sequencing
• The interaction operator seq means that the combined
fragment represents a weak sequencing between the
behaviors of the operands.
• The ordering of occurrence specifications within each
of the operands is maintained.
• Occurrence specifications on different lifelines from
different operands may come in any order.
• Occurrence specifications on the same lifeline from
different operands are ordered such that an occurrence
specification of the first operand comes before that of
the second operand. Search Google possibly parallel with
Bing and Yahoo, but search Bing
before Yahoo.
Critical
The interaction operator critical defines
that the combined fragment represents
a critical region.
Add() or remove() could be called in parallel,

but each one should run as a critical region.

Ignore
• There are some message types that are
not shown within this combined fragment.
• These message types can be considered
insignificant and are implicitly ignored if
they appear in a corresponding execution.
• The list of ignored messages follows the
operand enclosed in a pair of curly braces
"{" and "}". Ignore operation is typically Ignore get() and set() messages, if any.
combined with other operations such as
"assert ignore {m, s}."

Consider
• The interaction operator consider defines
which messages should be considered
within this combined fragment, meaning
that any other message will be ignored.
• The list of considered messages follows
the operand enclosed in a pair of curly
braces "{" and "}". Consider operation is
Consider only add() or remove() messages, ignore any other.
typically combined with other operations
such as "assert consider {m, s}."

Vending Machine System Sequence Diagram for
Deposit Money Use Case

System Sequence Diagram
for Make Selection Use Case

Order System

ATM System

Sequence diagram : example
• Order management
system

Sequence diagrams
• It help create an overview of how a system works.
• Sequence diagrams show how all the different parts interact
with each other over time, carry out the required actions, and
complete processes.
• A sequence diagram descends from top to bottom showing a
sequence of interactions and sequence diagram notations.

Timing diagrams
• UML 2 Timing diagrams shows the behavior of the

objects in a given period of time. Timing diagram is a
special form of a sequence diagram.
• The differences between timing diagram and

sequence diagram are that the axes are reversed so
that the time are increase from left to right and the
lifelines are shown in separate compartments
arranged vertically.
• Timing diagrams focus on conditions changing within

and among lifelines along a linear time axis.

Basics
• A lifeline in a Timing diagram • Multiple lifelines may be stacked
forms a rectangular space within within the same frame to model the
the content area of a frame. interaction between them.
Lifeline is a named element which
represents an individual
participant in the interaction.
• It is typically aligned horizontally
to read from left to right.

Timing diagrams
• Changes from one state to another are

represented by a change in the level of the
lifeline.
• For the period of time when the object is a
given state, the timeline runs parallel to that
state.
• A change in state appears as a vertical
change from one level to another.
• The cause of the change, as is the case in a
state or sequence diagram, is the receipt of
a message, an event that causes a change, a
condition within the system, or even just
the passage of time.

Timing diagram
• The timing diagram
focusing attention
on time of occurrence of
events causing changes in
the modeled conditions
of the Lifelines.

Example
• A state or condition timeline

represents the set of valid states and
time.
• The states are stacked on the left
margin of the lifeline from top to
bottom.
• The cause of the change, as is the case
in a state or sequence diagram, is the
receipt of a message, an event that
causes a change, a condition within the
system, or even just the passage of
time.
Example: Multiple Compartments
• It is possible to stack several life

lines of different objects in the
same timing diagram.
• One life line above the other.
Messages sent from one object to
another can be depicted using
simple arrows.
• The start and the end points of
each arrow indicate when each
message was sent and when it was
received.
Timing diagram: Web site
30
3
Timing diagram :Value lifeline Representation
• The figure shows an alternative

notation of UML Timing diagram.
• It shows the state of the object
between two horizontal lines that
cross with each other each time
the state changes.

State and Value Lifeline Side-by-Side
• State and Value Lifelines can be put one after the other in any combination.
Messages can be passed from one lifeline to another.
• Each state or value transition can have a defined event, a time constraint
which indicates when an event must occur, and a duration constraint which
indicates how long a state or value must be in effect for.

Specifying Timing Requirements

Interaction overview diagram
• Interaction overview diagrams
focuses on the overview of the
flow of control of the interactions.
• It is a variant of the Activity
Diagram where the nodes are the
interactions or interaction
occurrences.
• It describes the interactions where
messages and lifelines are hidden.

• The Interaction EstablishAccess
occurs first with argument"Illegal PIN"
followed by an interaction with the
message CardOut which is shown in an
inline Interaction.
• Then there is an alternative as we
find a decision node with an
InteractionConstraint on one of the
branches.
• Along that control flow we find
another inline Interaction and an
InteractionUse in the sequence.
Interaction overview diagram- Scheduling System

310
[ invalid room type]

Room not av. error

Communication Diagram
• A kind of interaction diagram, shows
how objects interact.
• An extension of object diagram that
shows the objects along with the
messages that travel from one to
another.
• Shows the messages the objects send
each other.
04/10/2024 312
Communication diagrams
•UML Communication diagrams used to model the dynamic behaviour.
•When compare to Sequence Diagram, the Communication Diagram is more focused on
showing the collaboration of objects rather than the time sequence.
•Components of the communication process include a sender, encoding of a message,
selecting of a channel of communication, receipt of the message by the receiver and
decoding of the message.
•It show the network and sequence of messages or communications between objects at
run-time during a collaboration instance

Purpose of Communication Diagram
• Model message passing between objects or roles that deliver the functionalities of
use cases and operations
• Model mechanisms within the architectural design of the system
• Model alternative scenarios within use cases or operations that involve the
collaboration of different objects and interactions
• Support the identification of objects (hence classes), and their attributes
(parameters of message) and operations (messages) that participate in use cases
04/10/2024 314
Communication Diagram Elements
1. Actor
• external to the system
• Participates in the collaboration by sending and/or receiving messages
2. Object
• Instances of a class
• Supplier objects are the objects that supply the method that is being called, and therefore receive
the message.
• Client objects call methods on supplier objects, and therefore send messages.
3.Links
• The connecting lines drawn between objects in a communication diagram are links.
• Each link represents a relationship between objects and symbolizes the ability of objects to send
messages to each other.
• If an object sends messages to itself, the link carrying these messages is represented as a loop icon.
04/10/2024 315
Communication Diagram Elements
4. Messages
Shown as arrows pointing from the Client object to the Supplier object.
Represent a client invoking an operation on a supplier object. They can be modeled along with the
objects in the following manner:
• Message icons have one or more messages associated with them.
• Messages are composed of message text prefixed by a sequence number.
• This sequence number indicates the time-ordering of the message.
• The first message in a communication diagram is always numbered 1, the second is 2, and so on.
• You can indicate that a message is nested under a parent message by adding a decimal point and
incremental digits to the parent's sequence number.
Guard Condition
• Represent a test that must be met for the message to be sent
04/10/2024 316
04/10/2024 317
04/10/2024 318
Communication Diagram at a Glance
• The objects are Object1, Object2, …, ObjectN.
• Messages passed between objects are represented by labeled
arrows that start with the sending object (actor) and end with
the receiving object.
• The sample messages passed between objects are labeled 1:
message1, 2: message2, 3: message3, etc., where the numerical
prefix to the message name indicates its order in the sequence.
• Object1 first sends Object2 the message message1, Object2 in
turn sends ObjectN-1 the message message2, and so on.
• Messages that objects send to themselves are indicated as
loops (e.g., message message5).
• Each message in a communication diagram has a sequence
number.
• Messages sent during the same call have the same decimal
prefix, but suffixes of 1, 2, etc. according to when they occur.
04/10/2024 319
From Sequence Diagram to Communication
Diagram
04/10/2024 320
Example: Scenario (Course Registration )
04/10/2024 321
Example: Scenario (Withdraw Cash from
ATM)
04/10/2024 322
Example: Scenario (Book Doctor’s Appointment)
04/10/2024 323
Example: Scenario(Library Book Overdue)
04/10/2024 324
Example: Scenario(Checkout from a shop)
04/10/2024 325
Process Order Control Communication diagram

Communication diagram
• Focus is on object organization.
• In the communication diagram, the method call
sequence is indicated by some numbering technique.
• We have taken the same order management system in
previous slide to describe the communication diagram.
• Method calls are similar to that of a sequence
diagram.
• However, difference being the sequence diagram does
not describe the object organization, whereas the
communication diagram shows the object
organization.
• To choose between these two diagrams, emphasis is
placed on the type of requirement.
• If the time sequence is important, then the sequence
diagram is used. If organization is required, then
communication diagram is used. Software Engineering and Project Management- UNIT II 327
Sequence Diagrams vs Communication Diagrams
• Sequence diagrams :
– Strength: clearly show sequence or time ordering of events, simple notation
– Weakness: forced to extend to the right when adding new objects
• Communication diagrams :
– Strength: space economical flexibility to add new objects in two dimensions,
better to illustrate complex branching, iteration and concurrent behavior
– Weakness: difficult to see sequence of messages, more complex notation

References
• UML 2.0 in nutshell, by Dan Pilone & Neil Pitman,O’Reilly .
• Roger S Pressman, Software Engineering: A Practitioner’s Approach, Mcgraw-Hill, ISBN:
0073375977, Seventh Edition, 2014
• Grady Booch, James Rambaugh, Ivar Jacobson, ―The unified modeling language user guide,
Pearson Education, Second edition, 2008, ISBN 0-321-24562-8
• Website: https://www.visual-paradigm.com/guide
• .

SEPM Unit 2 - Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SEPM Unit 2 - Final

Uploaded by

Copyright:

Available Formats

Software Design

Software Engineering and Project Management- UNIT II 1

Software Engineering and Project Management- UNIT II 2

Software Engineering and Project Management- UNIT II 3

Software Engineering and Project Management- UNIT II 4

Software Engineering and Project Management- UNIT II 5

Software Engineering and Project Management- UNIT II 6

Good Design Bad Design

Software Engineering and Project Management- UNIT II 9

High Level Design

Low Level Design

Software Engineering and Project Management- UNIT II 11

Software Engineering and Project Management- UNIT II 12

Software Engineering and Project Management- UNIT II 13

Software Engineering and Project Management- UNIT II 14

Software Engineering and Project Management- UNIT II 15

Ideally good Software Design

Software Engineering and Project Management- UNIT II 16

• Design: Process of mapping requirements to a system

Software Engineering and Project Management- UNIT II 17

Software Engineering and Project Management- UNIT II 18

• OOAD(Object Oriented Analysis and Design)

Software Engineering and Project Management- UNIT II 19

Software Engineering and Project Management- UNIT II 20

Software Engineering and Project Management- UNIT II 21

Software Engineering and Project Management- UNIT II 22

Software Engineering and Project Management- UNIT II 23

Software Engineering and Project Management- UNIT II 24

2 Process Any process that changes the data, producing an output. It

Software Engineering and Project Management- UNIT II 26

Software Engineering and Project Management- UNIT II 27

• DFD Level 0 is also called a Context

Software Engineering and Project Management- UNIT II 29

Software Engineering and Project Management- UNIT II 31

• Each process can go to any other symbol

Software Engineering and Project Management- UNIT II 32

Software Engineering and Project Management- UNIT II 35

• This Level 1 DFD breaks

Software Engineering and Project Management- UNIT II 36

decomposes the “Place

Software Engineering and Project Management- UNIT II 37

Software Engineering and Project Management- UNIT II 38

Software Engineering and Project Management- UNIT II 39

Software Engineering and Project Management- UNIT II 41

Software Engineering and Project Management- UNIT II 42

Time Keeping Cards Payroll Payment

Software Engineering and Project Management- UNIT II 43

Software Engineering and Project Management- UNIT II 44

Software Engineering and Project Management- UNIT II 45

Software Engineering and Project Management- UNIT II 47

• Attributes, which are represented by ovals. A key attribute is the unique,

Software Engineering and Project Management- UNIT II 48

Software Engineering and Project Management- UNIT II 50

Software Engineering and Project Management- UNIT II 51

Software Engineering and Project Management- UNIT II 52

Software Engineering and Project Management- UNIT II 53

Software Engineering and Project Management- UNIT II 54

Software Engineering and Project Management- UNIT II 55

• The primary tasks in object-oriented analysis (OOA) are −

Software Engineering and Project Management- UNIT II 57

1. Identify the objects

2. Determine their attributes and services

3. Determine the relationships between objects