MODULE 4- SOFTWARE DESIGN

Design concepts and principles - Abstraction -

Refinement - Modularity Cohesion coupling,
Architectural design, Detailed Design
Transaction Transformation, Refactoring of
designs, Object oriented Design User-
Interface Design
Five Notable Design Quotes
"Questions about whether design is necessary or affordable are quite beside the point; design is
inevitable. The alternative to good design is bad design, [rather than] no design at all."
Douglas Martin
"You can use an eraser on the drafting table or a sledge hammer on the construction site."
Frank Lloyd Wright

"The public is more familiar with bad design than good design. If is, in effect, conditioned to prefer
bad design, because that is what it lives with; the new [design] becomes threatening, the old
reassuring."
Paul Rand

"A common mistake that people make when trying to design something completely foolproof was to
underestimate the ingenuity of complete fools."
Douglas Adams

"Every now and then go away, have a little relaxation, for when you come back to your work your
judgment will be surer. Go some distance away because then the work appears smaller and more of it
can be taken in at a glance and a lack of harmony and proportion is more readily seen."
Leonardo Da Vinci
Purpose of Design
• Design is where customer requirements, business needs, and technical
considerations all come together in the formulation of a product or system
• The design model provides detail about the software data structures,
architecture, interfaces, and components
• The design model can be assessed for quality and be improved before code is
generated and tests are conducted
– Does the design contain errors, inconsistencies, or omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints, schedule, and cost that have
been established?
Purpose of Design
• A designer must practice diversification and convergence
– The designer selects from design components, component solutions, and
knowledge available through catalogs, textbooks, and experience
– The designer then chooses the elements from this collection that meet the
requirements defined by requirements engineering and analysis modeling
– Convergence occurs as alternatives are considered and rejected until one particular
configuration of components is chosen
• Software design is an iterative process through which requirements are
translated into a blueprint for constructing the software
– Design begins at a high level of abstraction that can be directly traced back to the
data, functional, and behavioral requirements
– As design iteration occurs, subsequent refinement leads to design representations
at much lower levels of abstraction
From Analysis Model to Design Model

• Each element of the analysis model provides information that is necessary to

create the four design models
– The data/class design transforms analysis classes into design classes along with the
data structures required to implement the software
– The architectural design defines the relationship between major structural elements
of the software; architectural styles and design patterns help achieve the
requirements defined for the system
– The interface design describes how the software communicates with systems that
interoperate with it and with humans that use it
– The component-level design transforms structural elements of the software
architecture into a procedural description of software components
Analysis Model
From Analysis Model to Design Model
SOFTWARE DESIGN

Software Design is a process of

transforming user requirements
into suitable form, which helps
the programmer in software
coding and implementation.
Objectives of Software Design
1. Correctness: Software design should be correct as per requirement.
2. Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily maintainable by other
designers.
Software Design process

• The software design process can be divided into the following 3 levels of phases of design:

1. Interface Design: It focused on interaction between the system and the users devices. Scenario &
Behavioral based diagram used. Not focus on internal structure.
2. Architectural Design: It focused on major components of a system their responsibilities, properties,
interfaces, relationships and interactions between them. Class based & flow based diagram used.

3. Detailed Design: It focused on internal elements of all major system components, their properties,
relationships, processing, algorithms and data structures.
Task for Software Design
1) Examine the information domain model and design appropriate data structures for
data objects and their attributes
2) Using the analysis model, select an architectural style (and design patterns) that are
appropriate for the software
3) Partition the analysis model into design subsystems and allocate these subsystems
within the architecture
a) Design the subsystem interfaces
b) Allocate analysis classes or functions to each subsystem
4) Create a set of design classes or components
a) Translate each analysis class description into a design class
b) Check each design class against design criteria; consider inheritance issues
c) Define methods associated with each design class
d) Evaluate and select design patterns for a design class or subsystem
Task for Software Design
5) Design any interface required with external systems or devices
6) Design the user interface
7) Conduct component-level design
a) Specify all algorithms at a relatively low level of abstraction
b) Refine the interface of each component
c) Define component-level data structures
d) Review each component and correct all errors uncovered
8) Develop a deployment model
▪ Show a physical layout of the system, revealing which components will be
located where in the physical computing environment
DESIGN QUALITY
Quality's Role
• The importance of design is quality
• Design is the place where quality is fostered
– Provides representations of software that can be assessed for quality
– Accurately translates a customer's requirements into a finished software
product or system
– Serves as the foundation for all software engineering activities that follow
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test
– Cannot be assessed for quality later in the software process when time is
short and most of the budget has been spent
• The quality of the design is assessed through a series of formal technical reviews
or design walkthroughs
Goals of a Good Design
• The design must implement all of the explicit requirements contained in the
analysis model
– It must also accommodate all of the implicit requirements desired by the customer
• The design must be a readable and understandable guide for those who
generate code, and for those who test and support the software
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective

"Writing a clever piece of code that works is one thing; designing something
that can support a long-lasting business is quite another."
Design Quality Guidelines
1) A design should exhibit an architecture that
a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing
2) A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
3) A design should contain distinct representations of data, architecture,
interfaces, and components
4) A design should lead to data structures that are appropriate for the classes to
be implemented and are drawn from recognizable data patterns
 Design Quality Guidelines
5) A design should lead to components that exhibit independent functional
characteristics
6) A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment
7) A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis
8) A design should be represented using a notation that effectively
communicates its meaning

"Quality isn't something you lay on top of subjects and objects like tinsel on a
Christmas tree."
Software Quality Attributes
The attributes of design name as 'FURPS' are as follows:
1. Functionality: It evaluates the feature set and capabilities of the program.
2. Usability: It is accessed by considering the factors such as human factor, consistency and documentation.
3. Reliability: It is evaluated by measuring parameters like frequency and security of failure, output result
accuracy, recovery from failure and program predictability.
4. Performance: It is measured by considering processing speed, response time, resource consumption,
throughput and efficiency.
5. Supportability: It combines the ability to extend the program, adaptability, serviceability. Testability,
compatibility and configurability are the terms using which a system can be easily installed and found the
problem easily.
Supportability also consists of more attributes such as modularity, reusability, robustness, security, portability,
scalability.
DESIGN CONCEPTS
About Software Design Concepts
● The software design concept simply means the idea or principle
behind the design.
● It describes how you plan to solve the problem of designing
software.
● It also shows the logic or thinking behind how you will design
software.
● The software design concept for developing the right software
provides a supporting and essential structure or model.
Software Design concepts and principles
● Software design principles are concerned with providing means to
handle the complexity of the design process effectively.
● Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors
during design.
Principles of Software Design
Design Concepts
1. Abstraction
2. Architecture
3. Design Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Refactoring
9. Object-Oriented Design Concept
Abstraction
• Abstraction is used to hide background details or unnecessary implementation about the data.
• So that users see only required information.
Type 1: Procedural Abstraction:
There is collections of subprograms.
One is hidden group another is visible group of functionalities.
Example:
Private: Fuel_machine() Set_top_speed() Develop_engine()
Public: Turn_on(), Turn_off(), Accelerate(), Break()
Type 2: Data Abstraction:
Collections of data that describe data objects.
Show representation data & hide manipulation data.
Examples:
Data Structure Programs directly used Push(), Pop(), Top() and Empty() method
Architecture
The architecture is the structure of program modules where they interact with each other in
a specialized way.
● Structural Properties: Architectural design represent different types of components,
modules, objects & relationship between these.
● Extra-Functional Properties: How design architecture achieve requirements of
Performance, Capacity, Reliability, Security, Adaptability & other System
Characteristics.
● Families of related systems: The architectural design should draw repeatable patterns.
They have ability to reuse repeatable blocks.
Design patterns
The pattern
simply means a
repeated form or
design in which
the same shape is
repeated several
times to form a
pattern.
Modularity
● Modularity simply means dividing the
system or project into smaller parts to
reduce the complexity of the system or
project
● After developing the modules, they are
integrated together to meet the software
requirements.
● Modularizing a design helps to effective
development, accommodate changes easily,
conduct testing, debugging efficiently and
conduct maintenance work easily.
Information Hiding
● Modules should be specified and
designed in such a way that the data
structures and algorithm details of
one module are not accessible to
other modules.
● They pass only that much
information to each other, which is
required to accomplish the software
functions.
● The way of hiding unnecessary
details in modules is referred to as
information hiding.
Functional Independence
The functional independence is the concept of separation and related to
the concept of modularity, abstraction and information hiding.

● Criteria 1: Coupling

The degree in which module is "connected" to other module in the

system.

Low Coupling necessary in good software.

● Criteria 2: Cohesion

The degree in which module perform functions in inner module in the

system.

High Cohesion necessary in good software.

Refinement
● Refinement is a top-down design approach.
● It is a process of elaboration.
● A program is established for refining levels
of procedural details.
● A hierarchy is established by decomposing
a statement of function in a stepwise
manner till the programming language
statement are reached.
Refactoring
● Refactoring is the process of changing the internal software system in a way that it
does not change the external behavior of the code still improves its internal structure.
● When software is refactored the existing design is examined for redundancy, unused
design elements, unnecessary design algorithms, poorly constructed data,
inappropriate data structure or any other design failure that can be corrected for better
design.
Object Oriented Design Concepts

● Object Oriented is a popular

design approach for analyzing
and designing an application.
● Advantage is that faster, low
cost development and creates a
high quality software.
Points to be Considered While Designing Software
1. Abstraction (Hide Irrelevant data)

2. Modularity (subdivide the system)

3. Architecture (design a structure of something)

4. Refinement (removes impurities)

5. Pattern (a Repeated form)

6. Information Hiding (Hide the Information)

7. Refactoring (Reconstruct something)

 MODULARITY
(COHESION AND COUPLING)
Coupling
• In software engineering, the coupling is the degree of interdependence between software
modules. Two modules that are tightly coupled are strongly dependent on each other.
However, two modules that are loosely coupled are not dependent on each other.
Uncoupled modules have no interdependence at all within them.
Coupling
• A good design is the one that has low coupling. Coupling is measured by
the number of relations between the modules. That is, the coupling
increases as the number of calls between modules increase or the amount of
shared data is large. Thus, it can be said that a design with high coupling
will have more errors.
Types of Module Coupling
1. No Direct Coupling: There is no direct coupling between M1 and M2. In this case, modules
are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.
Types of Module Coupling
3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data
items such as structure, objects, etc. When the module passes non-global data structure or entire
structure to another module, they are said to be stamp coupled. For example, passing structure
variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is
used to direct the structure of instruction execution in another.
Types of Module Coupling
5. External Coupling: External Coupling arises when two modules share an externally imposed
data format, communication protocols, or device interface. This is related to communication to
external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a
branch from one module into another module.
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a module
belong together.
In other words, Cohesion refers to the degree to which elements within a module work together
to fulfill a single, well-defined purpose.
High cohesion means that elements are closely related and focused on a single purpose, while
low cohesion means that elements are loosely related and serve multiple purposes.

Thus, cohesion measures the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems, functionality is strongly related.

High coupling and low cohesion can make a system difficult to

change and test, while low coupling and high cohesion make a
system easier to maintain and improve.
Types of Module Cohesion
1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module, cooperate to
achieve a single function.
Example of functional cohesion includes reading transaction records because all the elements related to single
transaction are involved in it.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module form the
components of the sequence, where the output from one component of the sequence is input to the next.

3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the module
refer to or update the same data structure, e.g., the set of functions defined on an array or a stack.

4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module are all
parts of a procedure in which particular sequence of steps has to be carried out for achieving a goal, e.g., the
algorithm for decoding a message.
Types of Module Cohesion
5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the methods must
be executed in the same time, the module is said to exhibit temporal cohesion.

6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a similar
operation. For example Error handling, data input and data output, etc.

7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely.
Difference between Coupling and Cohesion
Coupling Cohesion
Coupling is also called Inter-Module Cohesion is also called Intra-Module
Binding. Binding.
Coupling shows the relationships between Cohesion shows the relationship within
modules. the module.
Coupling shows the relative Cohesion shows the module's relative
independence between the modules. functional strength.
While creating, you should aim for low While creating you should aim for high
coupling, i.e., cohesion, i.e., a cohesive component/
dependency among modules should be module focuses on a single function (i.e.,
less. single-mindedness) with little interaction
with other modules of the system.

In coupling, modules are linked to the In cohesion, the module focuses on a

other modules. single thing.
Example- Cohesion and Coupling in OOPS
https://www.enjoyalgorithms.com/blog/cohesion-and-coupling-in-oops
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:
1. Interface Design
2. Architectural Design
3. Detailed Design
Software Design Process
Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and views of a
system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A combination of
the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They are made
up of modules.
4. Interfaces: This is the shared boundary across which the components of a system exchange
information and relate.
5. Data: This is the management of the information and data flow.
Software Design Process
SOFTWARE ARCHITECTURE
DESIGN
1. The architecture of a system describes its major components, their relationships
(structures), and how they interact with each other.
2. Software architecture and design includes several contributory factors such as
Business strategy, quality attributes, human dynamics, design, and IT environment.
SOFTWARE ARCHITECTURE AND DESIGN
• Design Engineering divided into two distinct phases: Software Architecture and
Software Design.
SOFTWARE ARCHITECTURE
• In Architecture, nonfunctional decisions are cast and separated by the functional
requirements. In Design, functional requirements are accomplished.
1. Architecture serves as a blueprint for a system. It provides an
abstraction to manage the system complexity and establish a
communication and coordination mechanism among components.
2. It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like
performance and security.
SOFTWARE ARCHITECTURE AND DESIGN
3. Further, it involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the final product. These decisions
comprise of −
• Selection of structural elements and their interfaces by which the system is
composed.
• Behavior as specified in collaborations among those elements.
• Composition of these structural and behavioral elements into large subsystem.
• Architectural decisions align with business objectives.
• Architectural styles guide the organization.
SOFTWARE ARCHITECTURE AND DESIGN
SOFTWARE DESIGN
• Software design provides a design plan that describes the elements of a system, how they
fit, and work together to fulfill the requirement of the system. The objectives of having a
design plan are as follows −
● To negotiate system requirements, and to set expectations with
customers, marketing, and management personnel.
● Act as a blueprint during the development process.
● Guide the implementation tasks, including detailed design, coding,
integration, and testing.
● It comes before the detailed design, coding, integration, and testing
and after the domain analysis, requirements analysis, and risk analysis.
SOFTWARE ARCHITECTURE AND DESIGN
Goals of Architecture
• The primary goal of the architecture is to identify requirements that affect the
structure of the application. A well-laid architecture reduces the business risks
associated with building a technical solution and builds a bridge between business
and technical requirements.
Some of the other goals are as follows −
1. Expose the structure of the system, but hide its implementation details.
2. Realize all the use-cases and scenarios.
3. Try to address the requirements of various stakeholders.
4. Handle both functional and quality requirements.
5. Reduce the goal of ownership and improve the organization’s
market position.
6. Improve quality and functionality offered by the system.
7. Improve external confidence in either the organization or system.
Limitations
• Software architecture is still an emerging discipline within software
engineering. It has the following limitations −
a. Lack of tools and standardized ways to represent architecture.
b. Lackof analysis methods to predict whether architecture will result in an
implementation that meets the requirements.
c. Lack of awareness of the importance of architectural design to software
development.
d. Lackof understanding of the role of software architect and poor
communication among stakeholders.
e. Lack of understanding of the design process, design experience and evaluation of
design.
Role of Software Architect
• A Software Architect provides a solution that the technical team can create and design for
the entire application. A software architect should have expertise in the following areas −
• Design Expertise
1. Expert in software design, including diverse methods and approaches such as
object-oriented design, event-driven design, etc.
2. Lead the development team and coordinate the development efforts for the integrity
of the design.
3. Should be able to review design proposals and tradeoff among themselves.
• Domain Expertise
1. Expert on the system being developed and plan for software evolution.
2. Assist in the requirement investigation process, assuring completeness and
consistency.
3. Coordinate the definition of domain model for the system being developed.
Role of Software Architect
● Technology Expertise
1. Expert on available technologies that helps in the implementation of the system.
2. Coordinate the selection of programming language, framework, platforms,
databases, etc.
● Methodological Expertise
1. Expert on software development methodologies that may be adopted during SDLC
(Software Development Life Cycle).
2. Choose the appropriate approaches for development that helps the entire team.
Role of Software Architect
Hidden Role of Software Architect
Facilitates the technical work among team members and reinforcing the trust relationship
in the team.
Information specialist who shares knowledge and has vast experience.
Protect the team members from external forces that would distract them and bring less
value to the project.

Deliverables of the Architect

A clear, complete, consistent, and achievable set of functional goals
A functional description of the system, with at least two layers of decomposition
A concept for the system
A design in the form of the system, with at least two layers of decomposition
A notion of the timing, operator attributes, and the implementation and operation plans
A document or process which ensures functional decomposition is followed, and the form
of interfaces is controlled
Quality Attributes
• Quality is a measure of excellence or the state of being free from
deficiencies or defects. Quality attributes are the system properties that are
separate from the functionality of the system.
• Implementing quality attributes makes it easier to differentiate a good
system from a bad one.
• Attributes are overall factors that affect runtime behavior, system design,
and user experience.
Classification of Quality Attributes
Static Quality Attributes
● Reflect the structure of a system and organization, directly related to
architecture, design, and source code.
● They are invisible to end- user, but affect the development and
maintenance cost, e.g.: modularity, testability, maintainability, etc.
Dynamic Quality Attributes
● Reflect the behavior of the system during its execution.
● They are directly related to system’s architecture, design, source code,
configuration, deployment environment parameters and platform.
● They are visible to the end-user and exist at runtime,e.g.
throughput, robustness, scalability, etc.
Quality Scenarios
Quality scenarios specify how to prevent a fault from becoming a failure. They can
be divided into six parts based on their attribute specifications.
• Source − An internal or external entity such as people, hardware, software, or
physical infrastructure that generate the stimulus.
• Stimulus − A condition that needs to be considered when it arrives on a system.
• Environment − The stimulus occurs within certain conditions.
• Artifact − A whole system or some part of it suchas
processors, communication channels, persistent storage, processes etc.
• Response − An activity undertaken after the arrival of stimulus such as detect
faults, recover from fault, disable event source etc.
• Response measure − Should measure the occurred responses so that the
requirements can be tested.
Common Quality Attributes
Design Qualities

1. Conceptual Integrity- Defines the consistency and coherence of the overall design. This includes the way
components or modules are designed.
2. Maintainability- Ability of the system to undergo changes with a degree of ease.
3. Reusability- Defines the capability for components and subsystems to be suitable for use in other applications.

Run-time Qualities

1. Interoperability- Ability of a system or different systems to operate successfully by communicating and

exchanging information with other external systems written and run by external parties.
2. Manageability- Defines how easy it is for system administrators to manage the application.
3. Reliability- Ability of a system to remain operational over time.
4. Scalability- Ability of a system to either handle the load increase without impacting the performance of the
system or the ability to be readily enlarged.
5. Security- Capability of a system to prevent malicious or accidental actions outside of the designed usages.
6. Performance- Indication of the responsiveness of a system to execute any action within a given time interval.
7. Availability- Defines the proportion of time that the system is functional and working. It can be measured as a
percentage of the total system downtime over a predefined period.
Common Quality Attributes
System Qualities
1. Supportability- Ability of the system to provide information helpful for identifying and resolving
issues when it fails to work correctly.
2. Testability- Measure of how easy it is to create test criteria for the system and its components.
User Qualities
1. Usability- Defines how well the application meets the requirements of the user and consumer by being
intuitive.
Architecture Quality
1. Correctness- Accountability for satisfying all the requirements of the system.
Non-runtime Quality
1. Portability- Ability of the system to run under different computing environment.
2. Integrality- Ability to make separately developed components of the system work correctly together.
3. Modifiability- Ease with which each software system can accommodate changes to its software.
Business quality attributes
1. Cost and schedule- Cost of the system with respect to time to market, expected project lifetime &
utilization of legacy.
2. Marketability- Use of system with respect to market competition.
Architectural Style
❖ The architectural style, also called as architectural pattern, is a set of principles which
shapes an application.
❖ It defines an abstract framework for a family of system in terms of the pattern of
structural organization.
❖ The architectural style is responsible to −
Provide a lexicon of components and connectors with rules on how they can be
combined.
Improve partitioning and allow the reuse of design by giving solutions to
frequently occurring problems.
Describe a particular way to configure a collection of components (a module
with well-defined interfaces, reusable, and replaceable) and connectors
(communication link between modules).
Architectural Style
The software that is built for computer-based systems exhibit one of many
architectural styles. Each style describes a system category that encompasses −
❖ A set of component types which perform a required function by the system.
❖ A set of connectors (subroutine call, remote procedure call, data
stream, and socket) that enable communication, coordination, and
cooperation among different components.
❖ Semantic constraints which define how components can be
integrated to form the system.
❖ A topological layout of the components indicating their runtime
interrelationships.
Types of Architecture
❖ There are four types of architecture from the viewpoint of an enterprise and
collectively, these architectures are referred to as enterprise architecture.
1. Business architecture − Defines the strategy of business, governance, organization,
and key business processes within an enterprise and focuses on the analysis and
design of business processes.
2. Application (software) architecture − Serves as the blueprint for individual
application systems, their interactions, and their relationships to the business
processes of the organization.
3. Information architecture − Defines the logical and physical data assets and data
management resources.
4. Information technology (IT) architecture − Defines the hardware and software
building blocks that make up the overall information system of the organization.
Architecture Design Process
❖ The architecture design process focuses on the decomposition of a
system into different components and their interactions to satisfy
functional and nonfunctional requirements.
The key inputs to software architecture design are −
• The requirements produced by the analysis tasks.
• The hardware architecture (the software architect in turn provides
requirements to the system architect, who configures the hardware
architecture).
Architectural Description
• The result or output of the architecture design process is an
architectural description. The basic architecture design process is
composed of the following steps −
1. Understand the Problem
2. Identify Design Elements and their Relationships
3. Evaluate the Architecture Design
4. Transform the Architecture Design
 Key Architecture Principles
Following are the key principles to be considered while designing an architecture −

1. Build to Change Instead of Building to Last

2. Reduce Risk and Model to Analyze
3. Use Models and Visualizations as a Communication and Collaboration Tool
4. Use an Incremental and Iterative Approach
Key Design Principles
Following are the design principles to be considered for minimizing cost, maintenance requirements,
and maximizing extendibility, usability of architecture −

1. Separation of Concerns
2. Single Responsibility Principle
3. Principle of Least Knowledge
4. Minimize Large Design Upfront
5. Do not Repeat the Functionality
6. Prefer Composition over Inheritance while Reusing the Functionality
7. Identify Components and Group them in Logical Layers
8. Define the Communication Protocol between Layers
9. Define Data Format for a Layer
10. System Service Components should be Abstract
11. Design Exceptions and Exception Handling Mechanism
12. Naming Conventions
ARCHITECTURE MODELS
 Architecture Models
A software architecture must describe its group of components, their connections,
interactions among them and deployment configuration of all components.
A software architecture can be defined in many ways −
UML (Unified Modeling Language) − UML is one of object-oriented solutions
used in software modeling and design.
Architecture View Model (4+1 view model) − Architecture view model
represents the functional and non-functional requirements of software
application.
ADL (Architecture Description Language) − ADL defines the software
architecture formally and semantically.
UML
● UML stands for Unified Modeling Language. It is a pictorial language used to make software
blueprints. UML was created by Object Management Group (OMG). The UML 1.0 specification draft
was proposed to the OMG in January 1997. It serves as a standard for software requirement analysis
and design documents which are the basis for developing a software.
● UML can be described as a general purpose visual modeling language to visualize, specify, construct,
and document a software system. Although UML is generally used to model software system, it is not
limited within this boundary. It is also used to model non software systems such as process flows in a
manufacturing unit.
● The elements are like components which can be associated in different ways to make a complete UML
picture, which is known as a diagram. So, it is very important to understand the different diagrams to
implement the knowledge in real-life systems. We have two broad categories of diagrams and they are
further divided into sub-categories i.e. Structural Diagrams and Behavioral Diagrams.
Structural Diagrams
Structural diagrams represent the static aspects of a system. These static aspects
represent those parts of a diagram which forms the main structure and is therefore
stable.
These static parts are represented by classes, interfaces, objects, components and
nodes. Structural diagrams can be sub-divided as follows −
● Class diagram
● Object diagram
● Component diagram
● Deployment diagram
● Package diagram
● Composite structure
Brief Description of the diagrams
Class - Represents the object orientation of a system. Shows how classes are statically related.

Object - Represents a set of objects and their relationships at runtime and also represent the static view of
the system.

Component - Describes all the components, their interrelationship, interactions and interface of the system.

Composite structure - Describes inner structure of component including all classes, interfaces of the
component, etc.

Package - Describes the package structure and organization. Covers classes in the package and packages
within another package.

Deployment - Deployment diagrams are a set of nodes and their relationships. These nodes are physical
entities where the components are deployed.
Behavioral Diagrams
Behavioral diagrams basically capture the dynamic aspect of a system.
Dynamic aspects are basically the changing/moving parts of a system. UML
has the following types of behavioral diagrams −
● Use case diagram
● Sequence diagram
● Communication diagram
● State chart diagram
● Activity diagram
● Interaction overview
● Time sequence diagram
Brief Description of the diagrams
Use case - Describes the relationships among the functionalities and their internal/external controllers. These
controllers are known as actors.

Activity - Describes the flow of control in a system. It consists of activities and links. The flow can be sequential,
concurrent, or branched.

State Machine/state chart - Represents the event driven state change of a system. It basically describes the state
change of a class, interface, etc. Used to visualize the reaction of a system by internal/external factors.

Sequence - Visualizes the sequence of calls in a system to perform a specific functionality.

Interaction Overview - Combines activity and sequence diagrams to provide a control flow overview of system and
business process.

Communication - Same as sequence diagram, except that it focuses on the object’s role. Each communication is
associated with a sequence order, number plus the past messages.

Time Sequenced - Describes the changes by messages in state, condition and events.
UML Diagrams
UML Diagrams
● Behavioral diagrams ● Structural diagrams
depict a static view
portray a dynamic
or structure of a
view of a system or
system.
the behavior of a ● It is widely used in
system, which the documentation
describes the of software
functioning of the architecture.
system.

● Interaction diagrams are a subclass of behavioral diagrams that

give emphasis to object interactions and also depicts the flow
between various use case elements of a system.
● In simple words, it shows how objects interact with each other
and how the data flows within them.
Steps to create UML Diagrams
Use Case Diagrams
● A Use Case Diagram is a vital tool in system design, it provides a visual
representation of how users interact with a system.
● It serves as a blueprint for understanding the functional requirements of a system
from a user’s perspective, aiding in the communication between stakeholders and
guiding the development process.
● 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.
Use Case Diagrams
Use Case Diagram Notations
Actors
● 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.
● Proper identification and understanding
of actors are crucial for accurately
modeling system behavior.
Use Case Diagram Notations
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”.
● Use cases are represented by ovals.
Use Case Diagram Notations
● The system boundary is a visual representation of the scope or limits of the
System Boundary 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. The system boundary
is typically represented by a rectangular box that surrounds all the use cases of
the system.
● Purpose of System Boundary:
○ Scope Definition: It clearly outlines the boundaries of the system,
indicating which components are internal to the system and which are
external actors or entities interacting with the system.
○ Focus on Relevance: By delineating the system’s scope, the diagram can
focus on illustrating the essential functionalities provided by the system
without unnecessary details about external entities.
Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the interactions between
actors and use cases. These relationships provide a comprehensive view of the system’s
functionality and its various scenarios.

Association Relationship
The Association Relationship represents a communication or interaction between an actor and a
use case. It is depicted by a line connecting the actor to the use case. This relationship signifies
that the actor is involved in the functionality described by the use case.

Example: Online Banking System

● Actor: Customer
● Use Case: Transfer Funds
● Association: A line connecting the “Customer” actor to the “Transfer Funds” use case,
indicating the customer’s involvement in the funds transfer process.
Use Case Diagram Relationships- Association
Use Case Diagram Relationships- Include
The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included
use case. This relationship promotes modular and reusable design.
Example: Social Media Posting
● Use Cases: Compose Post, Add Image
● Include Relationship: The “Compose Post” use case includes the functionality of
“Add Image.” Therefore, composing a post includes the action of adding an image.
Use Case Diagram Relationships- Include
Use Case Diagram Relationships- Extend
The Extend Relationship illustrates that a use case can be extended by another use case
under specific conditions. It is represented by a dashed arrow with the keyword
“extend.” This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
● Use Cases: Book Flight, Select Seat
● Extend Relationship: The “Select Seat” use case may extend the “Book Flight”
use case when the user wants to choose a specific seat, but it is an optional step.
Use Case Diagram Relationships- Extend
Use Case Diagram Relationships- Generalization
The Generalization Relationship establishes an “is-a” connection between two use
cases, indicating that one use case is a specialized version of another. It is represented
by an arrow pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
● Use Cases: Rent Car, Rent Bike
● Generalization Relationship: Both “Rent Car” and “Rent Bike” are
specialized versions of the general use case “Rent Vehicle.”
Use Case Diagram Relationships- Generalization
How to draw a Use Case diagram in UML?
Step 1: Identify Actors Determine who or what interacts with the system. These are
your actors. They can be users, other systems, or external entities.
Step 2: Identify Use Cases Identify the main functionalities or actions the system must
perform. These are your use cases. Each use case should represent a specific piece of
functionality.
Step 3: Connect Actors and Use Cases Draw lines (associations) between actors and
the use cases they are involved in. This represents the interactions between actors and the
system.
Step 4: Add System Boundary Draw a box around the actors and use cases to represent
the system boundary. This defines the scope of your system.
Step 5: Define Relationships If certain use cases are related or if one use case is an
extension of another, you can indicate these relationships with appropriate notations.
Step 6: Review and Refine Step back and review your diagram. Ensure that it accurately
represents the interactions and relationships in your system. Refine as needed.
Step 7: Validate Share your use case diagram with stakeholders and gather feedback.
Ensure that it aligns with their understanding of the system’s functionality.
Let’s understand how to draw a Use Case diagram with
the help of an Online Shopping System:
1. Actors:
● Customer
● Admin
2. Use Cases:
● Browse Products
● Add to Cart
● Checkout
● Manage Inventory (Admin)
3. Relations:
● The Customer can browse products, add to the cart, and complete the checkout.
● The Admin can manage the inventory.
Example: Online Shopping
USE CASE DIAGRAM - STARUML
What are common Use Case Diagram Tools and
Platforms?
1. Lucidchart
2. draw.io
3. Microsoft Visio
4. SmartDraw
5. PlantUML
6. Visual Paradigm
7. Canva
What are Common Mistakes and Pitfalls while making
Use Case Diagram?
Over complication: Including excessive detail in the diagram.

Ambiguous Relationships: Unclear relationships between actors and use cases.

Inconsistent Naming Conventions: Inconsistent naming of actors and use cases.

Misuse of Generalization: Incorrect use of generalization relationships.

Overlooking System Boundaries: Not clearly defining the system boundary.

Lack of Iteration: Treating the diagram as a static artifact.

Class Diagrams
● 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.
● Class diagrams provide a high-level overview of a system’s design, helping to
communicate and document the structure of the software. They are a fundamental tool
in object-oriented design and play a crucial role in the software development
lifecycle.
Class Diagram
Class Diagram: What is a class?

● In object-oriented programming (OOP), a class is a blueprint or template for creating

objects.
● Objects are instances of classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the objects created from that
class will possess.
● The attributes represent the characteristics or properties of the object, while the
methods define the behaviors or actions that the object can perform.
UML Class Notation
UML Class Notation
1. Class Name:
● The name of the class is typically written in the top compartment of the class box and is
centered and bold.
2. Attributes:
● Attributes, also known as properties or fields, represent the data members of the class.
They are listed in the second compartment of the class box and often include the visibility
(e.g., public, private) and the data type of each attribute.
3. Methods:
● Methods, also known as functions or operations, represent the behavior or functionality of
the class. They are listed in the third compartment of the class box and include the
visibility (e.g., public, private), return type, and parameters of each method.
4. Visibility Notation:
● Visibility notations indicate the access level of attributes and methods. Common visibility
notations include:
● + for public (visible to all classes)
● - for private (visible only within the class)
● # for protected (visible to subclasses)
● ~ for package or default visibility (visible to classes in the same package)
 Class Diagram Relationships
● 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.
Class Diagram Relationships- Association
● An association represents a bi-directional relationship between two classes. It indicates
that instances of one class are connected to instances of another class. Associations are
typically depicted as a solid line connecting the classes, with optional arrows indicating
the direction of the relationship.
● Let’s understand association using an example:
Let’s consider a simple system for managing a library. In this system, we have two
main entities: Book and Library. Each Library contains multiple Books, and each Book
belongs to a specific Library. This relationship between Library and Book represents an
association.

● The “Library” class can be considered the source class because it contains a reference to
multiple instances of the “Book” class. The “Book” class would be considered the target
class because it belongs to a specific library.
Class Diagram Relationships- Association
Class Diagram Relationships- Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in a
specific way.
● In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the
association to the class that is being targeted or affected by the association.
● Directed associations are used when the association has a specific flow or directionality,
such as indicating which class is responsible for initiating the association or which class
has a dependency on another.
Class Diagram Relationships- Directed Association
Consider a scenario where a “Teacher” class is associated with a “Course”
class in a university system. The directed association arrow may point from the
“Teacher” class to the “Course” class, indicating that a teacher is associated
with or teaches a specific course.

● The source class is the “Teacher” class. The “Teacher” class initiates the
association by teaching a specific course.
● The target class is the “Course” class. The “Course” class is affected by the
association as it is being taught by a specific teacher.
Class Diagram Relationships- Directed Association
Class Diagram Relationships- Aggregation
Aggregation is a specialized form of association that represents a “whole-part”
relationship. It denotes a stronger relationship where one class (the whole) contains or
is composed of another class (the part). Aggregation is represented by a diamond
shape on the side of the whole class. In this kind of relationship, the child class can
exist independently of its parent class.
Let’s understand aggregation using an example:
The company can be considered as the whole, while the employees are the parts.
Employees belong to the company, and the company can have multiple
employees. However, if the company ceases to exist, the employees can still exist
independently.
Class Diagram Relationships- Aggregation
Class Diagram Relationships- Composition
Composition is a stronger form of aggregation, indicating a more significant
ownership or dependency relationship. In composition, the part class cannot
exist independently of the whole class. Composition is represented by a filled
diamond shape on the side of the whole class.
Let’s understand Composition using an example:
Imagine a digital contact book application. The contact book is the
whole, and each contact entry is a part. Each contact entry is fully owned
and managed by the contact book. If the contact book is deleted or
destroyed, all associated contact entries are also removed.
Class Diagram Relationships- Composition
Class Diagram Relationships- Generalization (Inheritance)
Inheritance represents an “is-a” relationship between classes, where
one class (the subclass or child) inherits the properties and
behaviors of another class (the superclass or parent). Inheritance is
depicted by a solid line with a closed, hollow arrowhead pointing
from the subclass to the superclass.
In the example of bank accounts, we can use generalization to
represent different types of accounts such as current accounts,
savings accounts, and credit accounts.
Class Diagram Relationships- Generalization (Inheritance)
Class Diagram Relationships- Realization (Interface)
Realization indicates that a class implements the features of an interface. It is often used in cases where a class
realizes the operations defined by an interface. Realization is depicted by a dashed line with an open arrowhead
pointing from the implementing class to the interface.
Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner” interface.
● Owner Interface: This interface now includes methods such as “acquire(property)” and
“dispose(property)” to represent actions related to acquiring and disposing of property.
● Person Class (Realization): The Person class implements the Owner interface, providing concrete
implementations for the “acquire(property)” and “dispose(property)” methods. For instance, a person can
acquire ownership of a house or dispose of a car.
● Corporation Class (Realization): Similarly, the Corporation class also implements the Owner interface,
offering specific implementations for the “acquire(property)” and “dispose(property)” methods. For
example, a corporation can acquire ownership of real estate properties or dispose of company vehicles.

Both the Person and Corporation classes realize the Owner interface, meaning they provide concrete
implementations for the “acquire(property)” and “dispose(property)” methods defined in the interface.
Class Diagram Relationships- Realization (Interface)
Class Diagram Relationships - Dependency
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.
Let’s consider a scenario where a Person depends on a Book.
● Person Class: Represents an individual who reads a book. The Person class
depends on the Book class to access and read the content.
● Book Class: Represents a book that contains content to be read by a person. The
Book class is independent and can exist without the Person class.

The Person class depends on the Book class because it requires access to a book to
read its content. However, the Book class does not depend on the Person class; it
can exist independently and does not rely on the Person class for its functionality.
Class Diagram Relationships - Dependency
 Class Diagram Relationships - Usage (Dependency)
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.
● Usage dependencies represent a form of dependency where one class depends on another class
to fulfill a specific need or requirement.
● The client class requires access to specific features or services provided by the supplier class.
● In UML class diagrams, usage dependencies are typically represented by a dashed arrowed line
pointing from the client class to the supplier class.
● The arrow indicates the direction of the dependency, showing that the client class depends on
the services provided by the supplier class.

Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.
Class Diagram Relationships - Usage (Dependency)
CLASS DIAGRAM- STARUML
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.
Activity Diagram Notations
Activity Diagram Notations
Initial State

The starting state before an activity takes place is depicted using the initial state.
● A process can have only one initial state unless we are depicting nested activities. We use a black filled
circle to depict the initial state of a system.
● For objects, this is the state when they are instantiated. The Initial State from the UML Activity Diagram
marks the entry point and the initial Activity State.
For example:
Here the initial state of the system before the application is opened.
Activity Diagram Notations
Action or Activity State

An activity represents execution of an action on objects or by objects.

We represent an activity using a rectangle with rounded corners. Basically any action or
event that takes place is represented using an activity.
For example:
Consider the previous example of opening an application, opening the application
is an activity state in the activity diagram.
Activity Diagram Notations
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.
An activity state can have multiple incoming and outgoing action flows. We use a line with an
arrow head to depict a Control Flow. If there is a constraint to be adhered to while making the
transition it is mentioned on the arrow.
For example:
Here both the states transit into one final state using action flow symbols i.e. arrows.
Activity Diagram Notations
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.

For example:
We apply the conditions on input number to display the result :

● If number is odd then display the number.

● If number if even then display the error.
Activity Diagram Notations
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 of a fork statement.
We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the parent
activity state and outgoing arrows towards the newly created activities.
For example:
In the example below, the activity of making coffee can be split into two concurrent activities and
hence we use the fork notation.
Activity Diagram Notations
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.
For example:
When both activities i.e. steaming the milk and adding coffee get completed, we converge them into
one final activity.
Activity Diagram Notations
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.
For example:
In the diagram below: we can’t have both sides executing concurrently, but they finally merge into one. A
number can’t be both odd and even at the same time.
Activity Diagram Notations
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.
We use a rectangular column to represent a swimlane as shown in the figure above.
For example:
Here different set of activities are executed based on if the number is odd or even. These activities
are grouped into a swimlane.
Activity Diagram Notations
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.
How to Draw an Activity Diagram in UML?
What are Activity Diagrams used for?
Activity diagrams are used in software development and system design to model and visualize the dynamic aspects of a
system. Here are some common uses of activity diagrams:
● Dynamic modelling of the system or a process.
● Illustrate the various steps involved in a UML use case.
● Model software elements like methods,operations and functions.
● We can use Activity diagrams to depict concurrent activities easily.
● Show the constraints, conditions and logic behind algorithms.
● During the requirements analysis phase, activity diagrams assist in capturing and documenting the dynamic aspects
of user interactions.
Activity Diagram - STARUML
Difference between Activity Diagram and Flow Chart
Activity Diagram Flow Chart

An activity diagram is associated with the A Flow Chart is associated with the
UML(Unified Modelling Language) programming.

An activity diagram is used to model the Depicts a diagrammatic representation

dynamic aspects of a system and also illustrates illustrating a solution model to a given problem
the workflow of activities within a use case or and a flow chart converges into being an activity
business process. diagram if complex decisions are being made.

Commonly used in software engineering within Widely used in software engineering for
the UML for modeling and designing software representing algorithms, decision structures, and
systems on high level. program flows.
Interaction Diagram - Sequence Diagram
Interaction 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.
Sequence Diagram Notations
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.

For example:

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.
Sequence Diagram Notations
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:
We display a lifeline in a rectangle called head with its name and type. The head is located on top of a
vertical dashed line (referred to as the stem) as shown above.
● If we want to model an unnamed instance, we follow the same pattern except now the portion
of lifeline’s name is left blank.
● Difference between a lifeline and an actor
● A lifeline always portrays an object internal to the system whereas actors are used
to depict objects external to the system.
Sequence Diagram Notations
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 from the core of a sequence diagram.
Messages can be broadly classified into the following categories:
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 arrow head to represent a synchronous message.
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
arrow head to represent an asynchronous message.
Sequence Diagram Notations
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.

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 system.It is
represented by an arrow terminating with a x.

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.

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 arrow head with a dotted line. The interaction moves forward only when
a reply message is sent by the receiver.
Sequence Diagram Notations
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 end point.

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.
Example: Sequence Diagram Notations
SEQUENCE DIAGRAM - STARUML
Collaboration Diagram
● Collaboration Diagram is a type of Interaction Diagram that visualizes the interactions and relationships
between objects in a system. It shows how objects collaborate to achieve a specific task or behavior.
● Collaboration diagrams are used to model the dynamic behavior of a system and illustrate the flow of
messages between objects during a particular scenario or use case.
● Collaboration Diagram is a behavioral diagram which is also referred to as a communication diagram, It
illustrates how objects or components interact with each other to achieve specific tasks or scenarios within a
system.
● In simpler terms, they visually represents the interactions between objects or components in a system, showing
how they collaborate to accomplish tasks or scenarios and depicts the interconnections among multiple objects
within a system, illustrating the system’s object architecture.
Collaboration Diagram
Difference between Sequence and Collaboration Diagram
● Sequence Diagrams ● Collaboration Diagrams

● The sequence diagram represents the UML, which

● The collaboration diagram also comes under the
is used to visualize the sequence of calls in a
UML representation which is used to visualize the
system that is used to perform a specific
organization of the objects and their interaction.
functionality.

● The sequence diagram are used to represent the ● The collaboration diagram are used to represent the
sequence of messages that are flowing from one structural organization of the system and the
object to another. messages that are sent and received.

● The sequence diagram is used when time sequence ● The collaboration diagram is used when object
is main focus. organization is main focus.

● The collaboration diagrams are better suited for

● The sequence diagrams are better suited of analysis
depicting simpler interactions of the smaller
activities.
number of objects.
Collaboration Diagram
Importance of Collaboration Diagrams

● Collaboration diagrams play a crucial role in system development by facilitating

understanding, communication, design, analysis, and documentation of the system’s
architecture and behavior.
● Visualizing Interactions
● Understanding System Behavior
● Facilitating Communication
● Supporting Design and Analysis
● Documentation Purposes
Collaboration Diagram
Collaboration Diagram ●
NOTATIONS
Objects
● Links
● Messages
Collaboration Diagram ● Associations specified in a class diagram
can be represented as links in a
collaboration diagram.
● Messages in collaboration diagrams are
shown as arrows pointing from the Client
object to the Supplier object.
● Typically, messages represent a client
invoking an operation on a supplier object.
● 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.
Collaboration Diagram - STARUML
Component Diagram
● Component Diagrams are used to show code modules of a system in Unified
Modeling Language (UML). They are generally used for modeling subsystems.
● It represents how each and every component acts during execution and running of
a system program. They are also used to show and represent structure and
organization of all components.
● The component diagrams represent implementation of view models. The
component diagrams are for representing interfaces and dependencies among
software architecture. The word component simply means modules of a class that
usually represents an independent subsystem.
● These components have ability to interface with rest of system. The component
diagram is used to explain working and behavior of various components of a
system and is static diagrams of UML. They are also used for subsystem
modeling. The main purpose of component diagram is simply to show relationship
among various components of a system.
Component Diagram
Component Diagram

Following is a component
diagram for the ‘On-line Course
Registration’ system. This
diagram shows conceptual view of
server-side components.
Component Diagram- Advantages

● Component diagrams are very simple, standardized, and very easy to understand.
● It is also useful in representing implementation of system.
● These are very useful when you want to make a design of some device that contains an
input-output socket.
● Use of reusable components also helps in reducing overall development cost.
● It is very easy to modify and update implementation without causing any other side
effects.
Component Diagram- Disadvantages
● They cannot be used for designing Software like web pages,
applications, etc.
● It also requires sponsoring equipment and actuators for each and every
component.
Component Diagram- STARUML
 Deployment Diagram
● A Deployment Diagram in software engineering is a type of Structural UML Diagram that shows the
physical deployment of software components on hardware nodes. It illustrates the mapping of software
components onto the physical resources of a system, such as servers, processors, storage devices, and
network infrastructure.

Notations in Deployment Diagram

 Deployment Diagram
Component:

A component represents a modular and reusable part of a system, typically implemented as a software module, class, or package.
It encapsulates its behavior and data and can be deployed independently.
Typically represented as a rectangle with two smaller rectangles protruding from its sides, indicating ports for
connections. The component’s name is written inside the rectangle.

Artifact:

An artifact represents a physical piece of information or data that is used or produced in the software development process. It can
include source code files, executables, documents, libraries, configuration files, or any other tangible item.
Typically represented as a rectangle with a folded corner, labeled with the artifact’s name. Artifacts may also include
additional information, such as file extensions or versions.
Deployment Diagram
Interface:

An interface defines a contract specifying the methods or operations that a component must implement. It represents
a point of interaction between different components or subsystems.

Represented as a circle or ellipse labeled with the interface’s name. Interfaces can also include provided and required
interfaces, denoted by “+” and “-” symbols, respectively.

Node

A node represents a physical or computational resource, such as a hardware device, server, workstation, or
computing resource, on which software components can be deployed or executed.

Represented as a box with rounded corners, usually labeled with the node’s name. Nodes can also include nested
nodes to represent hierarchical structures.
Deployment Diagram
Communication path:

A straight line that represents communication between two device nodes. Dashed lines in deployment diagrams often
signify relationships or dependencies between elements, indicating that one element is related to or dependent on
another.
Deployment Diagram
Real-World Examples For Deployment Diagram
Example 1 Deployment Diagram For Mobile Banking Andorid Services.
Deployment Diagram
Example 2
Deployment Diagram For Online Exam Registration System.
Deployment Diagram
Architecture Design Types
Architectural Design
The software needs the architectural design to represents the design of 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.
Each style will describe a system category that 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 how components can be integrated to form the system.
● Semantic models that help the designer to understand the overall properties of the system.
Taxonomy of Architectural styles:
1] Data centered architectures

2] Data flow architectures

3] Call and Return architectures

4] Object Oriented architecture

5] Layered architecture
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
access a central repository. Variation of this approach are used to transform
the repository into a blackboard when data related to 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.
● Data can be passed among clients using blackboard mechanism.
Advantage of Data centered architecture
● Repository of data is independent of clients
● Client work independent of each other
● It may be simple to add additional clients.
● Modification can be very easy
Data centered architectures
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 transmitting 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.
Data flow architectures
Advantages of Data Flow architecture
● It encourages upkeep, repurposing, and modification.
● With this design, concurrent execution is supported.
The disadvantage of Data Flow architecture
● It frequently degenerates to batch sequential system
● Data flow architecture does not allow applications that require greater
user engagement.
● It is not easy to coordinate two different but related streams
Data flow architectures
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 components 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 number of subprograms or
function into a control hierarchy. Main program contains
number of subprograms that can invoke other components.
Call and Return architectures
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 protect the system’s integrity.
● An object is unaware of the depiction of other items.
Advantage 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.
Layered architecture
● A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to 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 OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication
system.
Layered architecture
Data Flow Diagrams
A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where data
is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD is also called as a data
flow graph or bubble chart.
Observations to be done for DFD
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flowchart that represents the order of
events; arrows in DFD represents flowing data. A DFD does not involve any order of events.
3. No logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD,
suppress that urge! A diamond-shaped box is used in flow charts to represents decision
points with multiple exists paths of which the only one is taken. This implies an ordering of
events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until
the end of the analysis.
Notations used in DFD
Notations used in DFD
Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data
store indicates that the data is stored which can be used at a later stage or by the other
processes in a different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs
or sink of system outputs.
Levels in Data Flow Diagrams (DFD)
● The DFD may be used to perform a system or software at any level of abstraction.
● Infact, DFDs may be partitioned into levels that represent increasing information flow and
functional detail.
● Levels in DFD are numbered 0, 1, 2 or beyond.
● Here, we will see primarily three levels in the data flow diagram, which are: 0-level DFD,
1-level DFD, and 2-level DFD.
0-level DFDM
● It is also known as fundamental system model, or context diagram represents
the entire software requirement as a single bubble with input and output data
denoted by incoming and outgoing arrows.
● Then the system is decomposed and described as a DFD with multiple
bubbles. Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs.
● This process may be repeated at as many levels as necessary until the
program at hand is well understood.
● It is essential to preserve the number of inputs and outputs between levels,
this concept is called leveling by DeMacro.
0-level DFDM
If bubble "A" has two inputs x1 and x2 and one output y, then the expanded DFD, that represents "A" should
have exactly two external inputs and one external output as shown in fig:
0-level DFDM
1-level DFDM
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we highlight
the main objectives of the system and breakdown the high-level process of 0-level DFD into subprocesses.
2-level DFDM
2-level DFD goes one process deeper into parts of 1-level DFD. It can be
used to project or record the specific/necessary detail about the system's
functioning.
2-level DFDM
2-level DFDM
2-level DFDM
2-level DFDM
DETAILED DESIGN
TRANSACTION
TRANSFORMATION
TRANSACTION MAPPING
A STRUCTURED DESIGN PROVIDES A CONVENIENT TRANSITION
FROM A DATA FLOW DIAGRAM TO A SOFTWARE ARCHITECTURE.

● In many software applications, a single data item triggers one or a

number of information flows that affect a function implied by the
triggering data item.
● The data item, called a transaction, and its corresponding flow
characteristics . In this section we consider design steps used to treat
transaction flow.
Transaction / Architecture Mapping
Types of Information Flow

1. Transaction Flow - a single data triggers information flow along one of many paths
2. Transform Flow - the overall data flow is sequential and flows along a small number
of straight line paths
1) Incoming Flow
2) Transform Center
3) Outgoing Flow
Design Steps
•The design steps for transaction mapping are similar and in
some cases identical to steps for transform mapping . A major
difference lies in the mapping of DFD to software structure.
Step 1. Review the fundamental system model.
Step 2. Review and refine data flow diagrams for the
software.
Step 3. Determine whether the DFD has transform or
transaction flow characteristics.
Steps 1, 2, and 3 are identical to corresponding steps in
transform mapping.
Design Steps
Step 4. Identify the transaction center and the flow characteristics along each of the
action paths.
The location of the transaction center can be immediately discerned from the
DFD.The incoming path (i.e., the flow path along which a transaction is received)
and all action paths must also be isolated. Boundaries that define a reception path
and action paths are also shown in the figure.
Each action path must be evaluated for its individual flow characteristic.
Step 5. Perform “First Level Factoring”
Step 6. Perform “Second Level Factoring”
Step 7. Refine the first iteration program structure using design heuristics.
An Example
Transaction mapping will be illustrated by considering the user interaction subsystem of the
SafeHome software.

Step 1. Review the fundamental system model.

The fundamental system model or context diagram depicts the security function as a single transformation, representing the
external producers and consumers of data that flow into and out of the function. The previous diagram depicts a level 0
context model, and the next diagram shows refined data flow for the security function.
Step 2. Review and refine data flow diagrams for the software. Information obtained from
the requirements model is refined to produce greater detail. For example, the level 2 DFD
for monitor sensors
Step 3. Determine whether the DFD has transform or transaction flow characteristics.
Evaluating the DFD. Input and output should be consistent for a process.

Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries.
Incoming data flows along a path in which information is converted from external to
internal form; outgoing flow converts internalized data to external form.

Step 5. Perform “first-level factoring.” This mapping is top-down distribution of control.

Factoring leads to a program structure in which Top-level components perform decision
making and Low-level components perform most input, computation, and output work.
Middle-level components perform some control and do moderate amounts of work. When
transform flow is encountered, a DFD is mapped to a specific structure (a call and return
architecture) that provides control for incoming, transform, and outgoing information
processing.
•Step 6. Factor and refine the transaction structure and the structure
of each action path.
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality. A first-iteration architecture can always be refined by applying concepts of
functional independence. Components are exploded or imploded to produce sensible
factoring, separation of concerns, good cohesion, minimal coupling, and most important, a
structure that can be implemented without difficulty, tested without confusion, and
maintained without grief.
Object-Oriented Design
In the object-oriented design method, the system is viewed as a
collection of objects (i.e., entities). The state is distributed among
the objects, and each object handles its state data.
1.Objects: All entities involved in the solution design are known as objects.
For example, person, banks, company, and users are considered as objects. Every
entity has some attributes associated with it and has some methods to perform on
the attributes.
2.Classes: A class is a generalized description of an object. An object is an
instance of a class.
A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3.Messages: Objects communicate by message passing.
Messages consist of the integrity of the target object, the name of the requested
operation, and any other action needed to perform the function. Messages are often
implemented as procedure or function calls.
4. Abstraction: Complexity is handled using Abstraction. Abstraction is the removal of the
irrelevant and the amplification of the essentials.
5.Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information of an
object together but also restricts access to the data and methods from the outside world.
6.Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or
sub-classes can import, implement, and re-use allowed variables and functions from their immediate
superclasses.This property of OOD is called an inheritance. This makes it easier to define a specific
class and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar tasks
but vary in arguments, can be assigned the same name. This is known as polymorphism, which
allows a single interface is performing functions for different types. Depending upon how the
service is invoked, the respective portion of the code gets executed.
User Interface Design
•The visual part of a computer application or operating system through
which a client interacts with a computer or software. It determines how
commands are given to the computer or the program and how data is
displayed on the screen.
Types of User Interface
There are two main types of User Interface:
•Text-Based User Interface or Command Line Interface
•Graphical User Interface (GUI)
Text-Based User Interface: This method relies primarily on the keyboard. A
typical example of this is UNIX.
Advantages
•Many and easier to customizations options.
•Typically capable of more important tasks.
•Disadvantages
•Relies heavily on recall rather than recognition.
•Navigation is often more difficult.
Graphical User Interface (GUI): GUI relies much more heavily on the mouse. A
typical example of this type of interface is any versions of the Windows operating
systems.
Characteristics Descriptions

Windows Multiple windows allow different information to

be
displayed simultaneously on the user's screen.

Icons Icons different types of information. On some

systems, icons represent files. On other icons
describes processes.

Menus Commands are selected from a menu rather than

typed in a command language.

Pointing A pointing device such as a mouse is used for

selecting choices from a menu or indicating
items of interests in a window.

Graphics Graphics elements can be mixed with text or the

same display.
Advantages
•Less expert knowledge is required to use it.
•Easier to Navigate and can look through folders quickly in a guess and check manner.
•The user may switch quickly from one task to another and can interact with several different
applications.

Disadvantages
•Typically decreased options.
•Usually less customizable. Not easy to use one button for tons of different variations.
•Structure: Design should organize the user interface purposefully, in the meaningful and usual based on
precise, consistent models that are apparent and recognizable to users, putting related things together and
separating unrelated things, differentiating dissimilar things and making similar things resemble one
another. The structure principle is concerned with overall user interface architecture.
•Simplicity: The design should make the simple, common task easy, communicating clearly and directly
in the user's language, and providing good shortcuts that are meaningfully related to longer procedures.
•Visibility: The design should make all required options and materials for a given function visible
without distracting the user with extraneous or redundant data.
•Feedback: The design should keep users informed of actions or interpretation, changes of state or
condition, and bugs or exceptions that are relevant and of interest to the user through clear, concise, and
unambiguous language familiar to users.
•Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse by
allowing undoing and redoing while also preventing bugs wherever possible by tolerating varied inputs
and sequences and by interpreting all reasonable actions.