SWE TEST 2 Chapter 7 A
Conversion of Requirements to Design
Once the requirements of a project are understood, the transformation of requirements into a design begins.
The requirements addressed the “What?” (what the system is supposed to do, what are the constrains, etc.),
the design addresses the “How?” (how the system is decomposed into components, how these components
interface and interact, how each individual component works, etc.).
This is a difficult step that involves the transformation of a set of intangibles (the requirements) into another
set of intangibles (the design).
Software design first deals with how the software is to be structured—that is, what its components are and how
these components are related to each other.
DESIGN PHASES 1. Architectural design phase:
It is a “macro” view.
• This is a high-level overview of the system is developed.
• The main components are listed, as well as properties external to the components and relationships
among components
DESIGN PHASES 2. Detailed design phase
It is a “micro” view.
• The architectural components are decomposed to a much finer level of detail.
The design phase is divided into two separate parts
1. Architectural design phase and 2. Detailed design phase
Detailed Design comes from
Requirements & Architecture
SOFTWARE ARCHITECTURE
The software architecture of a system represents the design decisions related to overall system structure and
behavior.
• Think about the important modules and how they interact with other modules.
• Architecture helps stakeholders understand and analyze how the system will achieve essential qualities such
as modifiability, availability, and security.
• Architecture serves as a blueprint for a system.
• Every system has an architecture.
• There could be more than one structure.
• The focus is on the interfaces among modules rather than details concerning the internals of each module.
SOFTWARE ARCHITECTURE
Views and Viewpoints
A view is a representation of a system structure. The structure exists whether you represent it or not, and the
view only depicts the structure.
Formally, a view, in software architecture, is a way to portray those aspects or elements of the architecture that
are relevant to the concerns the view intends to address and, by implication, the stakeholders to whom those
concerns are important. (What you see?)
A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines
the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template
models for constructing its views. (Where are you looking from?)
Views and Viewpoints
1. Logical/Structural view
Represents the object-oriented
decomposition of a system. This view
shows the system's functionality and how it
is organized into components. It is typically
represented using class diagram.
SOFTWARE ARCHITECTURE Views and Viewpoints
2. Process View
The process view focuses on the system’s
run-time behavior and deals with the
system’s dynamic elements. This view shows
the system's dynamic behavior, such as how
its components interact with each other and
with the environment
SOFTWARE ARCHITECTURE 3. Development View or Implementation
View
The development view depicts a system from the
standpoint of a programmer and is concerned
with software administration.
The implementation view is another name for this
view. It describes system components using the
UML Component diagram. The Package diagram
is one of the UML diagrams used to depict the
development view.
SOFTWARE ARCHITECTURE
SOFTWARE ARCHITECTURE Views and Viewpoints 4. Physical View
The physical view portrays the system from the
perspective of a system engineer. The physical layer, it
is concerned with the topology of software components
as well as the physical connections between these
components. It is also called as deployment view.
It Illustrates the physical organization of the application,
it's about “what code runs in what hardware
". Represents the mapping of the software to the
hardware.
SOFTWARE ARCHITECTURE
Meta-Architectural Knowledge
▪ Although many systems have been developed with many different architectures, several architectures share
common characteristics at many levels.
▪ Meta-architectural knowledge - Comparing system architectures and describing their similarities and
differences.
▪ It is a set of high-level decisions that will strongly influence the structure of the system but is not itself the
structure of the system. The meta-architecture, through style, patterns of composition or interaction, principles
and guidelines, rules certain structural choices out, and guides selection decisions and tradeoffs, among others.
▪ Meta-architectural knowledge serves two main purposes.
o First, it can be used as a starting point for a particular system’s architecture, saving some work and
providing guidance for the final architecture.
o Second, it is an effective communication mechanism for providing a quick idea of the high-level structure of
a system when written in a format like design patterns, architectural styles are also called architectural
patterns.
OFTWARE ARCHITECTURE
The software architecture community has codified this kind of meta-architectural knowledge mainly in three
different ways:
1. Architectural styles or patterns
2. Architectural tactics
3. Reference architectures