Software Engineering

Dr. Bharat Singh

CSE Department
Outline
Object oriented analysis
Modeling and Design: UML introduction
Use cases, use case driven analysis
Structural modeling classes, relationships, interfaces
class diagrams, and object diagrams in UML
Behavioral/Functional modeling use case diagrams, sequence diagrams, in UML
Modeling
 Modeling
• In the engineering of software, ‘model’ is used in many different contexts.
But in essence, a model is an abstraction.
• It abstracts away all kinds of details that are not relevant. The quality of the
model is judged from the purpose of the model.
• There are different model like ‘system model’, ‘process model’,
‘mathematical model’, ‘platform models’, ‘meta model’ etc used in
software engineering for different purpose.
• A system model is a presentation of particular aspects of (software) systems
and their application context that is defined by predefined description
techniques based on text, graphics and tables.
OO Design Methodologies
OO Design
Object-Oriented Analysis (OOA)

• If everything we do in these languages is object-oriented, it means,

we are oriented or focused around objects.
• each object contains its own data and its own logic, and they
communicate between themselves.
• They represent things like employees, images, bank accounts,
spaceships, asteroids, video segments, audio files, or whatever exists
in your program.
Object-Oriented Analysis and
Design (OOAD)
• It is a technical approach for analyzing and designing an application,
system, or business by applying object-oriented programming, as well
as using visual modeling throughout the software development
process to guide stakeholder communication and product quality.
• OOAD in modern software engineering is typically conducted in an
iterative and incremental way.
• The outputs of OOAD activities are analysis models (for OOA) and
design models (for OOD) respectively.
• The intention is for these to be continuously refined and evolved,
driven by key factors like risks and business value.
Object-Oriented Analysis
• It’s a structured method for analyzing, designing a system by applying the
object-orientated concepts, and developing a set of graphical system
models during the development life cycle of the software.
• Grady Booch has defined OOA as, “Object-oriented analysis is a method
of analysis that examines requirements from the perspective of the
classes and objects found in the vocabulary of the problem domain”.
• Object oriented analysis contains the following activities
• Finding the objects
• Organizing the objects
• Describing how the objects interact
• Defining the operations of the objects
• Defining the objects internally
Object-Oriented Design
• Object–Oriented Design (OOD) involves implementation of the
conceptual model produced during object-oriented analysis.
• Grady Booch has defined object-oriented design as “a method of design
encompassing the process of object-oriented decomposition and a
notation for depicting both logical and physical as well as static and
dynamic models of the system under design”.
• 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.
 Functional Requirement
• “Any Requirement Which Specifies What The System Should Do.”

• In other words, a functional requirement will describe a particular

behavior of function of the system when certain conditions are met, for
example: “Send email when a new customer signs up” or “Open a new
account”.

• A functional requirement for an everyday object like a cup would be:

“ability to contain tea or coffee without leaking”.
 Non-functional Requirement
• “Any Requirement That Specifies How The System Performs A Certain
Function.”
• In other words, a non-functional requirement will describe how a system
should behave and what limits there are on its functionality.
• A non-functional requirement for the cup mentioned previously would
be: “contain hot liquid without heating up to more than 45°C”.
• Non-functional requirements when defined and executed well will help to
make the system easy to use and enhance the performance.
• Non-functional requirements focus on user expectations, as they are
product properties.
 UML (Unified Modelling Language)
• UML stands for Unified Modeling Language. It’s a rich language to model software
solutions, application structures, system behavior and business processes.
• There are two main categories; structure diagrams and behavioral diagrams.

• Structure diagrams show the things in the modeled system.

• Behavioral diagrams show what should happen in a system.

• They describe how the objects interact with each other to create a functioning
system.
• UML offers many diagram types, and sometimes two diagrams can explain the
same thing using different notations.
UML (Unified Modelling Language)
UML (Unified Modelling Language)
UML (Unified Modelling Language)
Interaction diagrams in UML
• Interaction diagram is nothing but a subset of behavioral diagrams.
• It is used to visualize the flow between various use case elements of
a system.
• To show an interaction between two entities and how data flows
within them.
• Following are the various interaction diagrams in UML:
• Timing diagram
• Sequence diagram
• Collaboration diagram
 UML (Unified Modelling Language): Structural Diagrams

• Structure diagrams depict the static structure of the elements

in your system. i.e., how one object relates to another.
• It shows the things in the system – classes, objects, packages
or modules, physical nodes, components, and interfaces.
• For example, just as the static aspects of a house encompass
the existence and placement of such things as walls, doors,
windows, pipes, wires, and vents.
• The Seven UML structural diagrams are roughly organized
around the major groups of things you’ll find when modeling
a system.
 UML (Unified Modelling Language): Structural Diagrams

Structural Diagram Brief Description

Composite Structure It shows the internal structure of a classifier, classifier interactions
Diagram with the environment through ports, or behavior of a collaboration.
It shows a set of nodes and their relationships that illustrates the
Deployment Diagram
static deployment view of an architecture.
It groups related UML elements into a collection of logically related
Package Diagram
UML structure.
It shows a set of classes, interfaces, and collaborations and their
Class Diagram
relationships, typically, found in modeling object-oriented systems.
It shows a set of objects and their relationships, which is the static
Object Diagram
snapshots of instances of the things found in class diagrams.
It shows a set of components and their relationships that
Component Diagram
illustrates the static implementation view of a system.
 UML (Unified Modelling Language)
• Class Diagram
• Class diagrams are the main building block of any object-oriented
solution.
• Used for describing structure and behavior in the use cases.
• It shows the classes in a system, attributes, and operations of each
class and the relationship/association between each class.
• Provides a conceptual model of the system in terms of entities and
their relationships.
• Used for requirement capture, end-user interaction
• Detailed class diagrams are used for developers
 UML (Unified Modelling Language)
• Class Diagram
• A class has three parts. Name at the top, attributes in the
middle and operations or methods at the bottom.
• In a large system with many related classes, classes are grouped
together to create class diagrams.
• Different relationships between classes are shown by different
types of arrows.
• Modifiers are used to indicate visibility of attributes and
operations.
• ‘+’ is used to denote Public visibility (everyone)
• ‘#’ is used to denote Protected visibility (friends and derived)
• ‘-’ is used to denote Private visibility (no one)
• By default, attributes are hidden and operations are visible.
 UML (Unified Modelling Language)
• Links – We use a link to represent a relationship between two objects.

• Dependency Relationships – We use a dependency relationship to show

when one element depends on another element. ……………..>
• Association – Association is a reference relationship between two
objects (or classes)
• Aggregation – Aggregation represents a “has a” relationship.

• Composition- Composition is a type of association where the child

cannot exist independent of the other.
 UML (Unified Modelling Language)
• The three types of association connectors: association, aggregation, and
composition
 UML (Unified Modelling Language)
• Interface Notation
• Interface is represented by a circle as shown in the following figure. It has
a name which is generally written below the circle.

• Interface is used to describe the functionality without implementation.

Interface is just like a template where you define different functions, not
the implementation. When a class implements the interface, it also
implements the functionality as per requirement.
 UML (Unified Modelling Language)
• Class Diagram
 UML (Unified Modelling Language)
• Object Oriented Relationship

• There are two kinds of Relationships

• Generalization (parent-child relationship)
• Association (student enrolls in course)
• Associations can be further classified as
• Aggregation
• Composition
UML (Unified Modelling Language)
 UML (Unified Modelling Language)

• owners feed pets, pets please

owners (association)
• a tail is a part of both dogs and
cats(aggregation / composition)
• a cat is a kind of pet
(inheritance / generalization)
 UML (Unified Modelling Language)
• Object Oriented Relationship: Generalization
 UML (Unified Modelling Language)
• Object Oriented Relationship: Association
• If two classes in a model need to communicate with each other,
there must be a link between them, and that can be represented by
an association

• Represent relationship between instances of classes

• Student enrolls in a course
• Courses have students
• Courses have exams
UML (Unified Modelling Language)
 UML (Unified Modelling Language)
• Object Oriented Relationship: Association

A single student can associate with multiple teachers:

The example indicates that every Instructor has one or more Students:

We can also indicate the behavior of an object in an association (i.e., the role of an
object) using role names.
 UML (Unified Modelling Language)
Object Oriented Relationship: Composition

• There's a strong lifecycle

dependency between the
two, meaning that when
Class A is deleted then
Class B is also deleted as a
result.
 UML (Unified Modelling Language)
Object Oriented Relationship: Aggregation
• In general, when parent
deleted all its child's are
being deleted as a result.
• The aggregation link is
usually used to stress the
point that Class A instance
is not the exclusive
container of Class B
instance.
 UML (Unified Modelling Language)
Class Diagram Relationships
• Classes are interrelated to each other in specific ways. In particular, relationships in class
diagrams include different types of logical connections.

• Association : any logical connection or relationship between classes

• Directed Association: a directional relationship represented by a line with an arrowhead.
• Reflexive Association: when a class may have multiple functions or responsibilities.
• Multiplicity: when the cardinality of a class in relation to another is being depicted.
• Aggregation
• Composition
• Inheritance/Generalization:
• Realization: Realization denotes the implementation of the functionality defined in one
class by another class.
UML (Unified Modelling Language)
Class Diagram Relationships
 UML (Unified Modelling Language)
• Object Diagram
• Object Diagrams, sometimes referred
to as Instance diagrams are very
similar to class diagrams.
• Like class diagrams, they also show
the relationship between objects but
they use real-world examples.
• They show what a system will look
like at a given time.
• Object Diagrams use real world
examples to depict the nature and
structure of the system at a
particular point in time.
 UML (Unified Modelling Language)
• Object Diagram
• There are three key elements used in
object diagram notation
• Object Name
• Attributes
• Links
• Usage of Object Diagram
• Object diagrams show users a static view
of a system - a snapshot in time of a class
diagram;
• Object diagrams can be used to show the
relationships and behavior between
objects;
• Object diagrams can be used as test cases
to judge the accuracy of class diagrams.
 UML (Unified Modelling Language)
• Object vs Class
 UML (Unified Modelling Language)
• Package Diagram
• Shows the arrangement and
organization of model elements in
middle to large scale project.
• Package diagram can show both
structure and dependencies between
sub-systems or modules, showing
different views of a system, for example,
as multi-layered application
• A package diagram shows the
dependencies between different
packages in a system.
 UML (Unified Modelling Language)
• Package Diagram
• Purpose of Package Diagrams
• Package Diagram can be used to simplify complex class diagrams, it
can group classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any of the
UML diagrams.
 UML (Unified Modelling Language)
• Package Diagram

• 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.
 UML (Unified Modelling Language)
• Package Diagram
• Fully qualified name of a package has the following syntax.
UML (Unified Modelling Language)
• Package Diagram - Dependency Notation
• There are two sub-types involved in dependency.
• They are <<import>> & <<access>>. Though there are two stereotypes
users can use their own stereotype to represent the type of dependency
between two packages.
• <<import>> - one package imports the functionality of other package
• <<access>> - one package requires help from functions of other package.
 UML (Unified Modelling Language)
Component Diagram
• A component diagram displays the structural relationship of different
components of a software system.
• used to only demonstrate the behavior as well as the structure of a
system.
• The term "component" refers to a module of classes that represent
independent systems or subsystems with the ability to interface with the
rest of the system.
• It depicts the relationships and organization of components.
• Component Diagrams show the types of software components in the
system, their interfaces and dependencies.
 UML (Unified Modelling Language)
Component Diagram
• Each component in UML is responsible for only a single clear aim in
the entire system, and it interacts with only other essential elements
• These are mostly used when working with complex systems with
many components.
• Components communicate with each other using interfaces.
• The interfaces are linked using connectors.
 UML (Unified Modelling Language)
• Component Diagram
 UML (Unified Modelling Language)
• Component Diagram
Provided interfaces: A straight line from the component box
with an attached circle. These symbols represent the interfaces
where a component produces information used by the required
interface of another component.

Required interfaces: A straight line from the component box

with an attached half circle (also represented as a dashed arrow
with an open arrow). These symbols represent the interfaces
where a component requires information in order to perform its
proper function.
 UML (Unified Modelling Language)
• Component Diagram
 UML (Unified Modelling Language)
• Component Diagram
 UML (Unified Modelling Language)
• Component Diagram
 UML (Unified Modelling Language)
Deployment Diagram
• A deployment diagram shows the
hardware of your system and the
software in that hardware.
• The deployment diagram describes
the physical deployment of
information generated by the
software program on hardware
components.
• The information that the software
generates is called an artifact.
 UML (Unified Modelling Language)
Deployment Diagram
• Deployment diagrams are
useful when your software
solution is deployed across
multiple machines with each
having a unique configuration.
 UML (Unified Modelling Language)

• Deployment diagram elements

• Artifact: A product developed by the software, symbolized by a
rectangle with the name and the word “artifact” enclosed by
double arrows.
• Node: A hardware or software object, shown by a three-
dimensional box.
• Association: A line that indicates a message or other type of
communication between nodes.
• Component: A rectangle with two tabs that indicates a software
element.
• Dependency: A dashed line that ends in an arrow, which
indicates that one node or component is dependent on another.
• Interface: A circle that indicates a contractual relationship. Those
objects that realize the interface must complete some sort of
obligation.
• Node as container: A node that contains another node inside of
it—such as in the example below, where the nodes contain
 UML (Unified Modelling Language)
• Deployment diagram elements

There is a web server, a database

server, and the machine where the
user views the website.
 UML (Unified Modelling Language)
• Deployment Diagram
• Deployment diagrams have several valuable applications.
• Show which software elements are deployed by which hardware elements.
• Illustrate the runtime processing for hardware.
• Provide a view of the hardware system’s topology.

• Deployment diagram guidelines

• Have you identified the scope of your system?
• What are the limitations of your physical hardware?
• Which distribution architecture are you using?
• Do you have all the nodes you need? Do you know how they are all connected?
• Do you know which components are going to be on which nodes?
 UML (Unified Modelling Language)
Profile Diagram
• Profile diagram is a new diagram type introduced in UML 2.
• provides a generic extension mechanism for customizing UML
models for particular domains and platforms.
• A Profile is a collection of such extensions that collectively
customize UML for a particular domain (e.g., aerospace,
healthcare, financial).
UML (Unified Modelling Language)
Profile Diagram
• Profiles are defined using
• stereotypes,
• tagged value definitions, and
• constraints
• which are applied to specific model elements,
like Classes, Attributes, Operations, and
Activities.
 UML (Unified Modelling Language)
Profile Diagram
• Stereotypes: Stereotypes allow you to increase
vocabulary of UML. Stereotypes are used to
introduce new building blocks that speak the
language of your domain and look primitive. It
allows you to introduce new graphical symbols.
• Tagged Values
• Tagged values are used to extend the properties
of UML so that you can add additional information
in the specification of a model element. It allows
you to specify keyword value pairs of a model
where keywords are the attributes. Tagged values
are graphically rendered as string enclose in
brackets.
 UML (Unified Modelling Language)
Profile Diagram
• Constraints
• They are the properties for specifying
conditions that must be held true at all the
time. Graphically a constraint is rendered as
string enclose in brackets placed near
associated element.
 UML (Unified Modelling Language)
• Composite Structure Diagram
• Composite structure diagrams are used to show the internal structure of a class.
• 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.
• You can graphically represent inner classes and parts and show associations both
between and within classes.
UML (Unified Modelling Language):
Behavioral Diagrams
 UML (Unified Modelling Language):
Behavioral Diagrams
• UML’s behavioral diagrams are used to visualize, specify, construct, and
document the dynamic aspects of a system.
• It shows how the system behaves and interacts with itself and other
entities (users, other systems).
• how data moves through the system,
• how objects communicate with each other,
• how the passage of time affects the system, or
• what events cause the system to change internal states.
• Since behavior diagrams illustrate the behavior of a system, they are
used extensively to describe the functionality of software systems.
 UML (Unified Modelling Language):
Behavioral Diagrams

• A behavioral diagram shows how the system works ‘in

motion’, that is
• how the system interacts with external entities and users,
• how it responds to input or event and
• what constraints it operates under.

• There are several behavioral diagrams that you can

model the dynamics of a system.
UML (Unified Modelling Language):
Behavioral Diagrams
Behavioral Diagram Brief Description
It is a graphical representations of workflows of stepwise activities
Activity Diagram
and actions with support for choice, iteration and concurrency

It describes a system’s functional requirements in terms of use

Use Case Diagram cases that enable you to relate what you need from a system to how
the system delivers on those needs.
It shows the discrete behavior of a part of a designed system
State Machine Diagram
through finite state transitions.
It shows the sequence of messages exchanged between the objects
Sequence Diagram
needed to carry out the functionality of the scenario.

It shows interactions between objects and/or parts (represented as

Communication Diagram
lifelines) using sequenced messages in a free-form arrangement.

Interaction Overview It depicts a control flow with nodes that can

Diagram contain other interaction diagrams.

It shows interactions when the primary purpose of the diagram is to

Timing Diagram reason about time by focusing on conditions changing within and
among lifelines along a linear time axis.
 UML (Unified Modelling Language)
(Behavioral UML types)
Use Case Diagram
• A Use-case diagram models the actors, the system, and their interaction.
• A Use Case diagram models the dynamic behavior of the system when it is
operating.
• It is modeled to represent the outside view of the system. The use-case diagram
explains the various use-cases in which an end-user can interact with the system.
• Use case diagrams give a graphic overview of the actors involved in a system,
different functions needed by those actors and how these different functions
interact.
• It’s a great starting point for any project discussion because you can easily
identify the main actors involved and the main processes of the system.
 UML (Unified Modelling Language)
(Behavioral UML types)
• A use case diagram at its
simplest is a representation
of a user's interaction with
the system that shows the
relationship between the
user and the different use
cases in which the user is
involved.
 UML (Unified Modelling Language)
(Behavioral UML types)
Example: Airline ticket booking system
• Some of the use cases in this example could be-
• A person logs in to search for flights.
• A person books a flight.
• A person views his previous flight bookings.
• A person web-checks in his flight.
• A person cancels his flight.
 UML (Unified Modelling Language)
(Behavioral UML types)
Use Case Diagram basic elements
 UML (Unified Modelling Language)
(Behavioral UML types)
Use case diagram
• Actor:
 UML (Unified Modelling Language)
(Behavioral UML types)
• Use case diagram
• How to find actors

• Supply/use/remove information
• Use the functionality.
• Will be interested in any requirement.
• Will support/maintain the system.
• The system’s external resources.
• The other systems will need to interact with this one.
 UML (Unified Modelling Language)
(Use case diagram)
• Documenting Actor Characteristics
 UML (Unified Modelling Language)
(Use case diagram)
• How to Find Use Cases
• What are the system tasks for each actor you have identified?
• Does the actor need to be informed about certain occurrences in the system?
• Will the actor need to inform the system about sudden, external changes?
• Does the system supply the business with the correct behavior?
• Can all features be performed by the use cases you have identified?
• What use cases will support and maintain the system?
• What information must be modified or created in the system?
UML (Unified Modelling Language)
(Use case diagram)
• Terminology
UML (Unified Modelling Language)
(Use case diagram)
• Terminology
 UML (Unified Modelling Language)
(Use case diagram)
• Example: Library
management System
• A generalized description of
how a system will be used.
• Provides an overview of the
intended functionality of the
system
 UML (Unified Modelling Language)
(Use case diagram)
• Example: Airline Ticket
booking system
 UML (Unified Modelling Language)
(Use case diagram)
• Example: To write and
publish a book
 UML (Unified Modelling Language)
(Use case diagram)
• Pay Bill is a parent use case and Bill
Insurance is the child use case.
(generalization)
• Both Make Appointment and
Request Medication include Check
Patient Record as a subtask.
(include)
• The extension point is written
inside the base case
• Pay bill; the extending class Defer
payment adds the behavior of this
extension point. (extend)
 UML (Unified Modelling Language)
Activity Diagram
• Activity diagrams are the perfect
UML solution for visualizing process
flows.
• Activity diagrams represent
workflows in a graphical way.
• They can be used to describe the
business workflow or the
operational workflow of any
component in a system.
• Sometimes activity diagrams are
used as an alternative to State
machine diagrams.
 UML (Unified Modelling Language)
Activity Diagram
• Activity diagrams in UML are a
great solution to visualize the
actions, outcomes, and flows
within a specific process and
the behaviors that pair with
them.
 UML (Unified Modelling Language)
• Basic components of an activity diagram
• Action: A step in the activity wherein the users or software perform a given
task. In Lucidchart, actions are symbolized with round-edged rectangles.
• Decision node: A conditional branch in the flow that is represented by a
diamond. It includes a single input and two or more outputs.
• Control flows: Another name for the connectors that show the flow between
steps in the diagram.
• Start node: Symbolizes the beginning of the activity. The start node is
represented by a black circle.
• End node: Represents the final step in the activity. The end node is
represented by an outlined black circle.
 UML (Unified Modelling Language)
Activity diagram
• Diagram show, the process of
either withdrawing money
from or depositing money into
a bank account.
 UML (Unified Modelling Language)
State Machine Diagram
• State machine diagrams are similar to
activity diagrams, although notations and
usage change a bit.
• They are sometimes known as state
diagrams or state chart diagrams as well.
• These are very useful to describe the
behavior of objects that act differently
according to the state they are in at the
moment.
• The State machine diagram below shows the
basic states and actions.
 UML (Unified Modelling Language)
Interaction Diagrams
 UML (Unified Modelling Language)
Sequence Diagram
• Sequence diagrams are a popular dynamic modeling
solution in UML because they specifically focus
on lifelines, or the processes and objects that live
simultaneously, and the messages exchanged between
them to perform a function before the lifeline ends.
 UML (Unified Modelling Language)
Sequence Diagram
• Sequence diagrams in UML show
how objects interact with each
other and the order those
interactions occur.
• It’s important to note that they
show the interactions for a
particular scenario.
• The processes are represented
vertically and
• interactions are shown as arrows.
 UML (Unified Modelling Language)
Sequence Diagram
•
 UML (Unified Modelling Language)
Sequence Diagram
• Example: ATM systems
 UML (Unified Modelling Language)
Communication Diagram
• In UML 1 they were called collaboration diagrams.
• It is almost identical to sequence diagrams in UML, but they focus more on the
relationships of objects
• Also shows how objects interact.
• Instead of a timeline, the diagram shows the instantiation of associations
between classes at run-time.
• The ordering of a set of messages is captured by numbering them.
• Communication diagrams are similar to sequence diagrams, but the focus is on
messages passed between objects.
• The same information can be represented using a sequence diagram and
different objects.
 UML (Unified Modelling Language)
Communication Diagram
• A communication diagram offers the same information as
a sequence diagram, but while
• a sequence diagram emphasizes the time and order of events,
• a communication diagram emphasizes the messages
exchanged between objects in an application
• It will offer a better understanding of how components communicate and
interact with each other rather than solely emphasizing the sequence of
events.
 UML (Unified Modelling Language)
Communication Diagram
 UML (Unified Modelling Language)
Communication Diagram
• The communication
diagram explains the
process to add an event
to a calendar.
• The numbers on each
line represent the order
and options in which
they are activated.
Examples
 Restaurant Example
• Initial Class
Restaurant Example
• Initial Class
Restaurant Example
• Sequence Diagram
 Generalization vs Specialization
• Generalization:
• combining similar classes of objects into a single, more general class.
• identifies commonalities among a set of entities.
• The commonality may be of attributes, behavior, or both.
• A superclass has the most general attributes, operations, and relationships that may be
shared with subclasses.
• A subclass may have more specialized attributes and operations.
• Specialization is the reverse process of Generalization means creating new sub-
classes from an existing class.