Software Engineering

By
[Link] Venkat Reddy
SOT-School of Technology Woxsen
University
 Unit –III Design Engineering

Content
Architecutare Design
s
Design Process and Design Conceptual Model Of
Quality Uml
Basic Structural
Design Concepts
Modelling
The Design Model
Class Diagram
Creating an Architectural
Design Sequence Diagram
Software Architecture
Data Design Collaboration Diagram
Architectural Styles And
Pattern Use Case Diagram
Component Diagram
Design Engineering

What is UML?
Unified Modeling Language (UML) is a standardized visual modeling language used in
software engineering to provide a general-purpose, developmental, and intuitive way to
visualize the design of a system. UML helps in specifying, visualizing, constructing, and
documenting the artifacts of software systems

Why do we need
UML?
Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.

Much time is saved down the line when teams can visualize processes, user interactions,
and the static structure of the system
Different Types of UML Diagrams
 Structural UML Diagrams

Class
Diagram
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system
i.e. used to construct and visualize object-oriented systems.
In these diagrams, classes are depicted as boxes, each containing three compartments for
the class name, attributes, and methods. Lines connecting classes illustrate associations,
showing relationships such as one-to-one or one-to-many.
Structural UML Diagrams

Relation Between
Classes
In class diagrams, relationships between classes describe how classes are connected or
interact with each other within a system. There are several types of relationships in
object-oriented modeling, each serving a specific purpose. Here are some common types
of relationships in class diagrams
 Structural UML Diagrams
Association Direct Association
An association represents a bi-directional A directed association in a UML class diagram
relationship between two classes. It represents a relationship between two classes
indicates that instances of one class are where the association has a direction,
connected to instances of another class. indicating that one class is associated with
another in a specific way
 Structural UML Diagrams
Aggregation Composition
Aggregation is a specialized form of Composition is a stronger form of
association that represents a “whole-part” aggregation, indicating a more significant
relationship. It denotes a stronger ownership or dependency relationship. In
relationship where one class (the whole) composition, the part class cannot exist
contains or is composed of another class independently of the whole class.
(the part). Aggregation is represented by a Composition is represented by a filled
diamond shape on the side of the whole diamond shape on the side of the whole class
class
 Structural UML Diagrams
Generalizati Realizaation
Inheritance
on represents an “is-a” relationship Realization indicates that a class implements
between classes, where one class (the the features of an interface. It is often used
subclass or child) inherits the properties and in cases where a class realizes the
behaviors of another class (the superclass or operations defined by an interface.
parent). Inheritance is depicted by a solid line Realization is depicted by a dashed line with
with a closed, hollow arrowhead pointing from an open arrowhead pointing from the
the subclass to the superclass implementing class to the interface
 Structural UML Diagrams

Dependency Relation
Ship
A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance. It represents a more loosely
coupled connection between classes. Dependencies are often depicted as a dashed arrow.
 Structural UML Diagrams
Usage (Dependency)
Relation Ship
A usage dependency relationship in a UML class diagram indicates that one class (the client)
utilizes or depends on another class (the supplier) to perform certain tasks or access certain
functionality. The client class relies on the services provided by the supplier class but does
not own or create instances of it
 Structural UML Diagrams
Composite Structure
We use composite structure diagrams to represent the internal structure of
Diagram
a class and its interaction points with other parts of the system.

•A composite structure diagram represents the relationship between parts

and their configuration, which determines how the classifier (class, a
component, or a deployment node) behaves.

•They represent the internal structure of a structured classifier using parts,

ports, and connectors.

•We can also model collaborations using composite structure diagrams.

•They are like class diagrams except they represent individual parts in detail
as compared to the entire class
 Structural UML Diagrams

Object Diagram
What are Object
Diagrams
An Object Diagram can be referred to as a screenshot of a system's
instances and the relationship between them.

•An object diagram in UML is useful because it provides a clear and visual
representation of specific instances of classes and their relationships at a
particular point in time, aiding in understanding and communicating the
structure and interactions within a system.

•In other words, “An object diagram in the Unified Modeling Language (UML),
is a diagram that shows a complete or partial view of the structure of a
modeled system at a specific time
 Structural UML Diagrams

Object Diagram
What is an
object
An object refers to a specific instance of a class within a system. A class is a
blueprint or template that defines the common attributes and behaviors
shared by a group of objects. An object, on the other hand, is a concrete
and individual occurrence of that class, possessing unique values for its
attributes.
What is a Classifier
In UML a classifier refers to a group of elements that have some common
features like methods, attributes, and operations. A classifier can be
thought of as an abstract metaclass which draws a boundary for a group of
instances having common static and dynamic features.
 Structural UML Diagrams
What Diagram Object Diagram
Notations
The object diagram in UML uses specific notations to represent instances of
classes and their relationships at a particular moment in time
 Structural UML Diagrams
Link of Object Object Diagram
We use a link to represent a relationship between two objects. The term link
Diagram
is used to specify a relationship between two instance specifications or
objects. We use a solid line to represent a link between two objects
 Structural UML Diagrams
Composition
Diagram
Composition is a type of association where the child cannot exist
independent of the other. We use a filled diamond on the containing object
with a line which joins it to the contained object. Composition is also a
special type of association. It is also a kind of parent child relationship, but it
is not an inheritance
 Structural UML Diagrams
Component
Diagram diagrams are used to represent how the physical components in
Component
a system have been organized. We use them for modeling implementation
details.
•Component Diagrams depict the •Components
•Interfaces
structural relationship between software •Relationships
system elements and help us in •Ports
understanding if functional •Artifacts
•Nodes
requirements have been covered by
planned development.
•Component Diagrams become
essential to use when we design and
build complex systems.

•Interfaces are used by components of

 Structural UML Diagrams
Component
•Diagram
Components
•Interfaces
•Relationships
•Ports
•Artifacts
•Nodes
 Structural UML Diagrams

Deployment Diagram
Deployment Diagrams are used to represent system hardware and its
software. It tells us what hardware components exist and what software
components run on them
•We illustrate system architecture as the distribution of software artifacts
over distributed targets.

•An artifact is the information that is generated by system software.

•They are primarily used when software is being used, distributed, or

deployed over multiple machines with different configurations.
 Structural UML Diagrams
Key Elements of Deployment
Diagram
1. Nodes: These represent the physical hardware entities where software components are
deployed, such as servers, workstations, routers, etc.
2. Components: Represent software modules or artifacts that are deployed onto nodes,
including executable files, libraries, databases, and configuration files.
3. Artifacts: Physical files deployed onto nodes, embodying the actual implementation of
software components, such as executables, scripts, databases, etc.
4. Dependencies: Reflect relationships or connections between nodes and components,
indicating communication paths, deployment constraints, or other dependencies.
5. Associations:Show relationships between nodes and components, signifying that a
component is deployed on a particular node, thus mapping software components to physical
nodes.
6. Deployment Specification:Describes the configuration and properties of nodes and
components,
7. encompassing
Communication hardware channels
Paths:Represent specifications, software configurations,
or connections facilitating communication
communication
between protocols,
nodes and etc.
components, including network connections, communication protocols,
 Structural UML Diagrams
Steps for Creating a Deployment
Diagram
•Step1: Identify Components: List all software parts and hardware devices that will be
in the deployment diagram.

•Step 2: Understand Relationships: Figure out how these parts connect and work
together.

•Step 3: Gather Requirements: Collect details about hardware, network setups, and
any special rules for deployment.

•Step 4: Draw Nodes and Components: Start by drawing the hardware devices (nodes)
and software parts (components) using standard symbols roughly at first improvise it and
draw the final one.

•Step 5: Connect Nodes and Components: Use lines or arrows to show how nodes and
components are linked, indicating how they talk to each other.
•Step 6: Add Details: Label everything clearly and include any extra info, like hardware
Structural UML Diagrams

Examplle 1:Deployment
Diagram
Structural UML Diagrams

Examplle 1:Deployment
Diagram
 Structural UML Diagrams

Example 1:Deployement Diagram For Mobile Banking Android

Services
 Structural UML Diagrams

Example 2:Deployement Diagram For Online Exam Registration

System.
 Structural UML Diagrams

Package
Diagram
We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies
between different packages and the internal composition of packages.

•Packages help us to organize UML diagrams into meaningful groups and

make the diagram easy to understand.

•They are primarily used to organise class and use case diagrams.
 Structural UML Diagrams

Basic Elements of Package

Diagram
 Structural UML Diagrams
Notations of Package Diagram
 Behavioural UML
Diagrams
Behavioral UML diagrams focus on illustrating the dynamic aspects of a
software system, showcasing how it behaves, responds to stimuli, and
undergoes state changes during runtime.
Different Types of Behavioural UML
Diagrams
 Behavioural UML
Diagrams
State Machine
Diagram
A state diagram is used to represent the condition of the system or part of
the system at finite instances of time. It’s a behavioral diagram and it
represents the behavior using finite state transitions.

•State diagrams are also referred to as State machines and State-chart

Diagrams.

•These terms are often used interchangeably. So simply, a state diagram is

used to model the dynamic behavior of a class in response to time and
changing external stimuli
 Behavioural UML
Diagrams
State Machine
Diagram
A state diagram is used to represent the condition of the system or part of
the system at finite instances of time. It’s a behavioral diagram and it
represents the behavior using finite state transitions.

•State diagrams are also referred to as State machines and State-chart

Diagrams.

•These terms are often used interchangeably. So simply, a state diagram is

used to model the dynamic behavior of a class in response to time and
changing external stimuli
 Behavioural UML
Diagrams
State Machine
Diagram
A state diagram is used to represent
the condition of the system or part of
the system at finite instances of time.
It’s a behavioral diagram and it
represents the behavior using finite
state transitions.
•State diagrams are also referred to
as State machines and State-chart
Diagrams.
•These terms are often used
interchangeably. So simply, a state
diagram is used to model the dynamic
behavior of a class in response to time
 Behavioural UML
Diagrams
State Machine
Basic
Diagram components and notations of a State
Machine diagram
1. Initial state
We use a black-filled circle to represent the initial state of a System
or a Class

2. Transition
We use a solid arrow to represent the transition or change of control
from one state to another. The arrow is labeled with the event which
causes the state change.

3. State
We use a rounded rectangle to represent a state. A state represents
the conditions or circumstances of an object of a class at an instant
of time.
 Behavioural UML
Diagrams
State Machine
Diagram
4. Fork
We use a rounded solid rectangular bar to represent a Fork notation with
an incoming arrow from the parent state and outgoing arrows towards
the newly created states. We use the fork notation to represent a state
splitting into two or more concurrent states.

5. Join
We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrows towards
the common goal state. We use the join notation when two or more
states concurrently converge into one on the occurrence of an event or
events.
 Behavioral UML Diagrams
State Machine
Diagram
6. Self transition
We use a solid arrow pointing back to the state itself to represent a
self-transition. There might be scenarios when the state of the
object does not change upon the occurrence of an event. We use
self-transitions to represent such cases.

7. Composite state
We use a rounded rectangle to represent a composite state. We
represent a state with internal activities using a composite state.

.8. Final State

We use a filled circle within a circle notation to represent the final
state in a state machine diagram.
Behavioral UML Diagrams

3. How to draw a State Machine diagram in

UML?
Behavioral UML Diagrams
 Behavioral UML Diagrams
State Machine
Diagram
 Behavioral UML DiagramsActivity
Diagram
What is an Activity Diagram?
Activity Diagrams are used to illustrate the flow of control in a system and refer to the
steps involved in the execution of a use case. We can depict both sequential processing
and concurrent processing of activities using an activity diagram ie an activity diagram
focuses on the condition of flow and the sequence in which it happens.

•We describe what causes a particular event using an activity diagram.

•An activity diagram portrays the control flow from a start point to a finish point showing
the various decision paths that exist while the activity is being executed.

•They are used in business and process modeling where their primary use is to depict the
dynamic aspects of a system.
 Behavioral UML DiagramsActivity
Diagram
Activity Diagram Notations
Behavioral UML DiagramsActivity
Diagram
1. Initial State
The starting state before an activity
takes place is depicted using the initial
state.
2.2. Action or Activity State
An activity represents the execution of an
action on objects or by objects. We
describe an activity using a rectangle
with rounded corners. Any action or event
that takes place is represented using an
activity.
2.3. Action Flow or Control flows
Action flows or Control flows are also referred
to as paths and edges. They are used to show
the transition from one activity state to
another activity state.
 Behavioral UML DiagramsActivity
Diagram
2.4. Decision node and Branching
When we need to make a decision before
deciding the flow of control, we use the decision
node. The outgoing arrows from the decision
node can be labelled with conditions or guard
expressions. It always includes two or more
output arrows.
2.5. Guard
A Guard refers to a statement written next to a
decision node on an arrow sometimes within
square brackets.
2.6. Fork
Fork nodes are used to support concurrent
activities. When we use a fork node when both
the activities get executed concurrently i.e. no
decision is made before splitting the activity into
two parts. Both parts need to be executed in case
 Behavioral UML DiagramsActivity
Diagram
2.. Join
Join nodes are used to support concurrent activities converging
into one. For join notations we have two or more incoming
edges and one outgoing edge.
2. Merge or Merge Event
Scenarios arise when activities which
are not being executed concurrently
have to be merged. We use the merge
notation for such scenarios. We can
merge two or more activities into one
if the control proceeds onto the next
activity irrespective of the path
chosen.
Behavioral UML DiagramsActivity
Diagram
2. Swimlanes
We use Swimlanes for grouping related activities in one column. Swimlanes group related
activities into one column or one row. Swimlanes can be vertical and horizontal.
Swimlanes are used to add modularity to the activity diagram. It is not mandatory to use
swimlanes. They usually give more clarity to the activity diagram. It’s similar to creating a
function in a program. It’s not mandatory to do so, but, it is a recommended practice.
 Behavioral UML DiagramsActivity
Diagram
2.. Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it. We can
have a scenario where an event takes some time to completed.
 Behavioral UML DiagramsActivity
Diagram
2. Final State or End State
The state which the system reaches when a particular process or activity ends is known as
a Final State or End State. We use a filled circle within a circle notation to represent the
final state in a state machine diagram. A system or a process can have multiple final states
 Behavioral UML DiagramsActivity
Diagram
How to Draw an Activity Diagram in UML?
 Behavioural UML
Diagrams
Use Case
1. What is a Use Case Diagram in UML?
Diagram
A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents
the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system’s
functionality by illustrating the various ways users can interact with it.
Behavioural UML
Diagrams
2. Use Case Diagram Notations Use Case
1.1. Actors Diagram
Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices. In the context of a Use Case Diagram, actors
initiate use cases and receive the outcomes
1.2. Use Cases
Use cases are like scenes in the play. They represent specific things your system can do.
In the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Ovals represent use cases.
1.3. System Boundary
The system boundary is a visual representation of the scope or limits of the system you
are modeling. It defines what is inside the system and what is outside. The boundary
helps to establish a clear distinction between the elements that are part of the system
and those that are external to it. A rectangular box that surrounds all the system’s use
cases typically represents the system boundary.
 Behavioural UML
Diagrams
Ex:Vehicle Rental
System
Behavioural UML
Diagrams
Use Case
Diagram
 Behavioural UML
Diagrams
Sequence
Diagram
A sequence diagram is the most commonly used interaction diagram.
 Behavioural UML
Diagrams
Sequence
Interaction diagram
Diagram
An interaction diagram is used to show the interactive behavior of a system. Since
visualizing the interactions in a system can be difficult, we use different types of
interaction diagrams to capture various features and aspects of interaction in a system.

•A sequence diagram simply depicts the interaction between the objects in a sequential
order i.e. the order in which these interactions occur.

•We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.

•Sequence diagrams describe how and in what order the objects in a system function.

•These diagrams are widely used by businessmen and software developers to document
and understand requirements for new and existing systems.
 Behavioural UML
Diagrams
Sequence Diagram Notation
• Actors
• Lifelines
• Messages
• Create message
• Delete Message
• Self Message
• Reply Message
• Found Message
• Lost Message
• Guards
 Behavioural UML
Diagrams
1.1. Actors
An actor in a UML diagram represents a type of role where it interacts with the system
and its objects. It is important to note here that an actor is always outside the scope of
the system we aim to model using the UML diagram.
We use actors to depict various roles including human users and other external subjects. We
represent an actor in a UML diagram using a stick person notation. We can have multiple actors in
a sequence diagram.
Here the user in seat reservation system is shown as
an actor where it exists outside the system and is not
a part of the system.
 Behavioural UML
Diagrams
1.2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence
diagram. So basically, each instance in a sequence diagram is represented by a lifeline.
Lifeline elements are located at the top in a sequence diagram. The standard in UML for
naming a lifeline follows the following format:
 Behavioural UML
Diagrams
1.3. Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.
•We represent messages using arrows.
•Lifelines and messages form the core of a sequence diagram.
 Behavioural UML
Diagrams
Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The
sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e. it
receives a reply message.
•A large number of calls in object-oriented programming are synchronous.
•We use a solid arrowhead to represent a synchronous message.
 Behavioural UML
Diagrams
Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction
moves forward irrespective of the receiver processing the previous message or not. We
use a lined arrowhead to represent an asynchronous message.
 Behavioural UML
Diagrams
1.4. Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is
represented with a dotted arrow and create word labelled on it to specify that it is the
create Message symbol.

The creation of a new

order on a e-
commerce website
would require a new
object of Order class
to be created.
 Behavioural UML
Diagrams
1.5. Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence
of the object in the [Link] is represented by an arrow terminating with a x.

In the scenario below

when the order is
received by the user, the
object of order class can
be destroyed.
 Behavioural UML
Diagrams
1.6. Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
Consider a scenario where the device
wants to access its webcam. Such a
scenario is represented using a self
message.
 Behavioural UML
Diagrams
1.7. Reply Message
Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line. The
interaction moves forward only when a reply message is sent by the receiver.
Consider the scenario where the device requests a photo
from the user. Here the message that shows the photo
being sent is a reply message.
 Behavioural UML
Diagrams
8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an
endpoint.
 Behavioural UML
Diagrams
1.9. 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 endpoint from a lifeline.

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.
 Behavioural UML
Diagrams
1.10. Guards
To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role in
letting software developers know the constraints attached to a system or a particular
process
To be able to withdraw cash, having a balance greater than zero is a condition that must be met as
shown below.
 Behavioural UML
Diagrams
How to create Sequence Diagrams?
Creating a sequence diagram involves several steps, and it’s typically done during the
design phase of software development to illustrate how different components or objects
interact over time. Here’s a step-by-step guide on how to create sequence diagrams:
[Link] the Scenario:
1. Understand the specific scenario or use case that you want to represent in the
sequence diagram. This could be a specific interaction between objects or the flow
of messages in a particular process.
[Link] the Participants:
2. Identify the participants (objects or actors) involved in the scenario. Participants can
be users, systems, or external entities.
[Link] Lifelines:
3. Draw a vertical dashed line for each participant, representing the lifeline of each
object over time. The lifeline represents the existence of an object during the
interaction.
[Link] Lifelines:
4. Position the lifelines horizontally in the order of their involvement in the
interaction. This helps in visualizing the flow of messages between participants .
Behavioural UML
Diagrams
[Link] Activation Bars:
5. For each message, draw an activation bar on the lifeline of the sending participant.
The activation bar represents the duration of time during which the participant is
actively processing the message.

[Link] Messages:
6. Use arrows to represent messages between participants. Messages flow
horizontally between lifelines, indicating the communication between objects.
Different types of messages include synchronous (solid arrow), asynchronous
(dashed arrow), and self-messages.

[Link] Return Messages:

7. If a participant sends a response message, draw a dashed arrow returning to the
original sender to represent the return message.

[Link] Timing and Order:

8. Use numbers to indicate the order of messages in the sequence. You can also use
Behavioural UML
Diagrams

[Link] Conditions and Loops:

9. Use combined fragments to represent conditions (like if statements) and loops in
the interaction. This adds complexity to the sequence diagram and helps in
detailing the control flow.
[Link] Parallel Execution:
[Link] parallel activities are happening, represent them by drawing parallel vertical
dashed lines and placing the messages accordingly.
[Link] and Refine:
[Link] the sequence diagram for clarity and correctness. Ensure that it
accurately represents the intended interaction. Refine as needed.
[Link] Annotations and Comments:
[Link] any additional information, annotations, or comments that provide
context or clarification for elements in the diagram.
 Behavioural UML
Diagrams

[Link] Assumptions and Constraints:

[Link] there are any assumptions or constraints related to the interaction, document them
alongside the diagram.

[Link]:
[Link] a UML modeling tool or diagramming software to create a neat and professional-looking
sequence diagram. These tools often provide features for easy editing, collaboration, and
documentation.
 Behavioural UML
Diagrams
Communication
Diagram
A Communication diagram models the interactions between objects or parts in terms of
sequenced messages. Communication diagrams represent a combination of information
taken from Class, Sequence, and Use Case Diagrams describing both the static structure
and dynamic behavior of a system.
However, communication diagrams use the free-form arrangement of objects and links as
used in Object diagrams. To maintain the ordering of messages in such a free-form
diagram, messages are labeled with a chronological number and placed near the link the
message is sent over. Reading a communication diagram involves starting at message 1.0,
and following the messages from object to object.
 Behavioural UML
Diagrams
Timing Diagram
Timing Diagram are a special form of Sequence diagrams which are used to depict the
behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
 Behavioural UML
Diagrams
8. Steps to create UML Diagrams
 Software Design
Process
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language. The software design process can be divided into the following three
levels or phases of design:

[Link] Design
[Link] Design
[Link] Design
Software Design
Process
Elements of a System
[Link]: This is the conceptual model that defines a system's structure,
behavior, and views. We can use flowcharts to represent and illustrate the architecture.

[Link]: These components handle one specific task in a system. The system is
made up of a combination of modules.

[Link]: This provides a particular function or group of related functions. They

are made up of modules.

[Link]: This is the shared boundary across which the components of a system
exchange information and relate.

[Link]: This is the management of the information and data flow.

Software Design
Process
 Software Design
Process
Interface Design

Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the inner
workings of the system i.e, during interface design, the internal of the systems are
completely ignored, and the system is treated as a black box. Attention is focused on the
dialogue between the target system and the users, devices, and other systems with which
it interacts. The design problem statement produced during the problem analysis step
should identify the people, other systems, and devices which are collectively called agents.
Interface design should include the following details:

[Link] description of events in the environment, or messages from agents to which the
system must respond.
[Link] description of the events or messages that the system must produce.
[Link] of the data, and the formats of the data coming into and going out of the
system.
[Link] of the ordering and timing relationships between incoming events or
 Software Design
Process
Architectural Design

Architectural design specifies a system’s major components, responsibilities, properties,

interfaces, and the relationships and interactions between them. In architectural design,
the system’s overall structure is chosen, but the internal details of major components are
ignored. Issues in architectural design include:

[Link] decomposition of the systems into major components.

[Link] of functional responsibilities to components.

[Link] Interfaces.

[Link] scaling and performance properties, resource consumption properties,

reliability properties, and so forth.

[Link] and interaction between components.

 Software Design
Process
Detailed Design
Detailed design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and
data structures. The detailed design may include:

[Link] of major system components into program units.

[Link] of functional responsibilities to units.

[Link] interfaces.

[Link] states and state changes.

[Link] and control interaction between units.

[Link] packaging and implementation, including issues of scope and visibility of

program elements.
 Software Design
Quality
Traditionally, a high-quality product is outlined in terms of its fitness of purpose. That is, a
high-quality product will specifically be what the users need to try. For code merchandise,
the fitness of purpose is typically taken in terms of satisfaction of the wants arranged down
within the SRS document.

What is Software Quality?

Software Quality shows how good and reliable a product is. To convey an associate
degree example, think about functionally correct software. It performs all functions as laid
out in the SRS document. But it has an associate degree virtually unusable program.
even though it should be functionally correct, we tend not to think about it to be a high-
quality product.
 Software Design
Quality
Factors of Software Quality
The modern read of high-quality associates with software many quality factors like the
following:
 Software Design
Quality
[Link]: A software is claimed to be transportable, if it may be simply created to
figure in several package environments, in several machines, with alternative code
merchandise, etc.

[Link]: A software has smart usability if completely different classes of users (i.e.
knowledgeable and novice users) will simply invoke the functions of the merchandise.

[Link]: A software has smart reusability if completely different modules of the

merchandise will simply be reused to develop new merchandise.

[Link]: Software is correct if completely different needs as laid out in the SRS
document are properly enforced.
 Software Design
Quality
[Link]: A software is reparable, if errors may be simply corrected as and once,
they show up, new functions may be simply added to the merchandise, and therefore the
functionalities of the merchandise may be simply changed, etc

[Link]: Software is more reliable if it has fewer failures. Since software engineers do
not deliberately plan for their software to fail, reliability depends on the number and type of
mistakes they make. Designers can improve reliability by ensuring the software is easy to
implement and change, by testing it thoroughly, and also by ensuring that if failures occur,
the system can handle them or can recover easily.

[Link]. The more efficient software is, the less it uses of CPU-time, memory, disk
space, network bandwidth, and other resources. This is important to customers in order to
reduce their costs of running the software, although with today’s powerful computers, CPU
time, memory and disk usage are less of a concern than in years gone by.
 Software Design
Quality
Software Quality Management System

Software Quality Management System contains the methods that are used by the
authorities to develop products having the desired quality.
Some of the methods are:

•Managerial Structure: Quality System is responsible for managing the structure as a

whole. Every Organization has a managerial structure.

•Individual Responsibilities: Each individual present in the organization must have some
responsibilities that should be reviewed by the top management and each individual
present in the system must take this seriously.

•Quality System Activities: The activities which each quality system must have been
• Project Auditing.
• Review of the quality system.
• It helps in the development of methods and guidelines
Software Design
Quality
 Architectural Design

The software needs an architectural design to represent the design of the

software. IEEE defines architectural design as “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.” The
software that is built for computer-based systems can exhibit one of these
many architectural styles.
 Architectural Design

System Category Consists of

•A set of components(eg: a database, computational modules) that will perform a function

required by the system.

•The set of connectors will help in coordination, communication, and cooperation between
the components.

•Conditions that defines how components can be integrated to form the system.

•Semantic models that help the designer to understand the overall properties of the
system.
 Architectural Design
Taxonomy of Architectural Styles

1] Data centered architectures:

•A data store will reside at the center of this architecture and is accessed frequently by
the other components that update, add, delete, or modify the data present within the
store.

•The figure illustrates a typical data-centered style. The client software accesses a
central repository. Variations of this approach are used to transform the repository into a
blackboard when data related to the client or data of interest for the client change the
notifications to client software.

•This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the
architecture without the permission or concern of other clients.
Architectural Design
Advantages of Data centered
architecture:

•Repository of data is independent of

clients

• Clients work independently of each

other

•It may be simple to add additional

clients.

•Modification can be very easy

 Architectural Design

2] Data flow architectures:

•This kind of architecture is used when input data is transformed into output data through a
series of computational manipulative components.

•The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has
a set of components called filters connected by lines.

•Pipes are used to transmit data from one

•component to the next.
•Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.

•If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.
Architectural Design
Advantages of Data Flow
architecture:
• It encourages upkeep, repurposing,
and modification.

•With this design, concurrent execution

is supported.

Disadvantage of Data Flow

architecture:
•It frequently degenerates to batch
sequential system

•Data flow architecture does not allow

applications that require greater user
engagement.
 Architectural Design
3] Call and Return architectures
It is used to create a program that is easy to scale and modify. Many sub-styles exist within
this category. Two of them are explained below.
•Remote procedure call architecture: This component is used to present in a main
program or sub-program architecture distributed among multiple computers on a network.
•Main program or Subprogram architectures: The main program structure
decomposes into several subprograms or functions into a control hierarchy. The main
program contains several subprograms that can invoke other components
 Architectural Design
4] Object Oriented architecture
The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message-passing
.
Characteristics of Object-Oriented Architecture:

•Object protects the system’s integrity.

•An object is unaware of the depiction of other items.

Advantages of Object Oriented Architecture:

•It enables the designer to separate a challenge into a collection of autonomous objects.
•Other objects are aware of the implementation details of the object, allowing changes to be
made without having an impact on other objects.
 Architectural Design
5] Layered architecture

• Several different layers are defined with each layer

performing a well-defined set of operations. Each layer will do
some operations that become closer to the machine instruction
set progressively.

•At the outer layer, components will receive the user interface
operations and at the inner layers, components will perform the
operating system interfacing(communication and coordination
with OS)

•Intermediate layers to utility services and application software

functions
•.
•One common example of this architectural style is the OSI-ISO
(Open Systems Interconnection-International Organization for
 Architectural Patterns

Design patterns and architectural styles play a crucial role in shaping the structure and
behavior of software systems. Let’s explore several architectural patterns and styles, each
with its characteristics, using examples and suitable diagrams.

Important Topics for Design Patterns

Architecture
•Layered Architecture (N-Tier Architecture)
•Microservices Architecture
•Service-Oriented Architecture (SOA)
•Event-Driven Architecture (EDA)
•Hexagonal Architecture (Ports and Adapters)
•Component-Based Architecture
•Blackboard Architecture
•Space-Based Architecture
 Architectural Patterns

Layered Architecture (N-Tier Architecture)

Layered architecture divides an application into distinct layers, with each layer responsible
for a specific set of functionality. This promotes the separation of concerns and modularity.

•Presentation Layer (UI) : This is where the

user interacts with the application. It handles user
input and displays information.
•Application Layer (Business Logic) : This layer
contains the core logic of the application, such as
processing user requests and managing business
rules.
• Data Access Layer (Data Base) : Data is
retrieved and [Link] interact with the
database, ensuring the separation of data
concern.
 Architectural Patterns

Microservices Architecture
Microservices architecture decomposes an application into small, independently deployable
services that communicate via APIs. This promotes scalability and flexibility.

•User Management Microservice handles user

authentication and profiles.

•Product Catalog Microservice manages product

information.
•Order Processing Microservice deals with order
creation and tracking.

•Payment Processing Microservice handles

payments.
This architecture promotes scalability and flexibility by
allowing services to evolve independently.
 Architectural Patterns

Service-Oriented Architecture (SOA)

SOA is an architectural style that structures an application as a collection of loosely
coupled services, often with standardized communication protocols.
Example:In an enterprise system, you might have services
for customer management, inventory control, and order
processing.
•Customer Management Service manages
customer data.

•Inventory Control Service tracks product

availability.

•Order Processing Service handles order creation

and fulfillment.

SOA promotes reusability and interoperability by

separating functionality into distinct services.
 Architectural Patterns
Event-Driven Architecture (EDA)
EDA involves components that communicate through events. Events trigger actions in
response, making systems highly decoupled and responsive to changes.

Example:A stock trading system where price updates trigger buy/sell

orders.
•Price Update Events trigger buy/sell orders.

•Order Execution Events update order status.

EDA makes systems highly responsive and decoupled,

allowing for real-time reactions to changes.
 Architectural Patterns
Hexagonal Architecture (Ports and Adapters)
Hexagonal architecture emphasizes the separation of the core business logic from
external dependencies, making it easy to test and adapt.

Example:A banking application where the core

business logic is isolated from database and
user interface.
•Core Business Logic is at the center.

•Adapters connect to external resources like

databases and UI.

This separation simplifies testing and makes

the application adaptable to changes.
 Architectural Patterns

Component-Based Architecture
Component-based architecture involves building software from reusable, self-contained
components.
Example: A content management system (CMS)
where components handle rendering,
authentication, and content storage.

•Rendering Component handles page rendering.

•Authentication Component manages user

access.

•Content Storage Component stores and

retrieves content.
Components can be reused across different parts of
the application.
 Architectural Patterns
Blackboard Architecture
In this architecture, different specialized modules work together on a common data
structure (the blackboard) to solve complex problems.

Example:An AI system for image recognition

where modules collaborate to identify
objects.

•Image Recognition Module processes

images.

•Object Identification Module identifies

objects.

•Decision Module makes decisions based on

recognized objects.
Modules share information on the blackboard,
Architectural Patterns