Software architecture design

System architecture design

tutorial study notes
Concept of software
architecture
 Definition of the software
architecture
• A program and computing system software architecture refers to
one or more structures of the system. The structure includes the
construction of the software, the external visible properties of the
construction, and their interrelationships.

• The architecture is not a workable software. Specifically, it is an

expression that enables software engineers to:
– Effectiveness of the analytical design in meeting the specified
requirements.
– In the stage when the design change is relatively easy, consider
the possible options of the architecture.
– Reduce the risk associated with the software construction.
 Definition of the software
architecture
• The design of software architecture usually considers the
two levels of —— data design and architecture design in
the design pyramid.
• Data design enables us to represent the data
construction of architecture in traditional system and the
definition of class in object-oriented system
(encapsulating properties and operations), while
architecture design mainly focuses on the structure,
properties and exchange function of software
construction
 Software architecture design
and lifecycle
1. Requirements analysis stage
• Requirements and SA design face different objects: one is the
problem space; the other is the solution space.
• Maintaining the traceability and transformation of the two has
always been the goal of the software engineering field.
• The transition from software requirements model to SA model
focuses on two issues
1. How to build the SA model according to the demand model.
• The Use case graph is used to describe the requirements,
and the transformation from the Use Case graph to the SA
model is generally completed by part-of-speech analysis
and some empirical rules.
2. How to ensure the traceability of the model transformation
• Maintain by form or Use Case Map, etc
 Software architecture design
and lifecycle
2. Design stage
• Description of SA model, design and analysis method of SA
model, summary and reuse of SA design experience.
• The study of the SA model description was divided into three
levels:
• The basic concept of the SA
• Build, connect,
• Architecture description language
• Multi-view representation of the SA model
• 4+1 model, UML
 5.1.2 Software architecture
design and lifecycle
3. The realization stage

• The architecture of the implementation stage is studied

in the following aspects.
– Study the SA-based development process support,
such as project organization structure, configuration
management, etc.
– Seek pathways from SA to excessive implementation,
such as introducing programming language elements
into SA phase, model mapping, building and
assembly, and multiplexing middleware platforms
– Study test techniques based on SA
 5.1.2 Software architecture
design and lifecycle
4. Member assembly stage

• Under the guidance of SA design model, the reusable

component assembly can realize the system at a higher
level and improve the efficiency of the system
implementation. In the process of component assembly,
the SA design model plays the role of the system
blueprint.
• The middleware follows specific component standards,
provide support for component interconnection, and
provide corresponding public services, such as security
services, naming services, etc.
 Software architecture design
and lifecycle
5. Deployment phase

• SA performs the software deployment as follows:

– Provides a high-level architecture view describing the
hardware and software model of the deployment
phase
– Based on the SA model, we can analyze the quality
attributes of the deployment scheme to choose a
reasonable deployment scheme
• At the present stage, SA-based software deployment
research focuses more on the organization and
demonstration of deployment stage, evaluating and
analyzing the deployment scheme, etc. The analysis of
deployment scheme often stays at the qualitative level
and requires the participation of deployment personnel.
 Software architecture design
and lifecycle
6. Post-stage development

• The post-development stage is the stage after the

software deployment and installation. At this stage, SA
research mainly focuses on maintenance, evolution,
reuse and other aspects. Typical research directions
include dynamic software architecture, architecture
recovery and reconstruction, etc.
 Software architecture design
and lifecycle
• life cycle

requirement design
implementation Build the
analysis phase phase assembly stage

Post-development Deployment
phase phase
 Importance of software
architecture
• Software architecture can meet the quality of the system
• Architecture design enables beneficiaries to achieve
agreed goals
• The architecture design supports the planning process
• The guidance of architecture design for system
development
• Architecture design can manage complexity effectively
• The architecture design lays the foundation for reuse
• Architecture design can reduce maintenance costs
• The architecture design can support the conflict analysis
Architecture-based software
development approach
 Overview of the design method
of the architecture
• Architecture-based software design (Architecture-Based Software
Design, ABSD) method.

• The ABSD approach is architecture-driven, or a combination of

commercial, quality, and functional requirements that make up the
architecture.

• Design activities begin before the demand extraction and analysis

are completed, and the demand extraction and analysis should be
conducted in parallel with the design activities.

• The ABSD approach has three bases. Functional decomposition,

the selection of architecture style, and the use of software templates

• The ABSD method is recursive, and each step of the iteration is

clearly defined.
 Concepts and terminology
• The ABSD method is
a top-down,
recursively preferred
method, through
which the architecture
of a software system
is refined and known
to produce software
components and
classes.
• The design elements
used in the ABSD
 Concepts and terminology
• Perspective and view
– When considering an architecture, it is important to
examine it from a different perspective (perspective),
which prompts software designers to consider
different properties of the architecture.
• Use-case and quality scenarios
– While using the use case to inactivate the functional
requirements, we inactivate the quality requirements
by defining specific scenarios, and call these
scenarios quality scenarios.
Development model based on
the architecture
• Traditional software
development model
(waterfall model) has
disadvantages such
as low development
efficiency and poor
support for software
reuse.
 Architecture requirements
• Demand refers to the
user's expectation of the
target software system in
terms of function,
behavior, performance,
design constraints, etc
– Demand acquisition
– Identity construction
– Demand review
 Architecture design
• Architecture requirements
are used to stimulate and
adjust design decisions,
and different views are
used to express
information related to
quality objectives.
Architecture design is an
iterative process. If the
system to be developed
can be used from the
existing system, the
design process of the
existing system can be
 Documented architecture
• The vast majority of architectures are
abstract and composed of some
conceptual constructs. Therefore, in order
for the system analysts and programmers
to implement the architecture, the
architecture must also be documented.
• The main output of the architecture
documentation process is two documents:
the architecture specification and the
quality design specification for testing the
architecture requirements.
 Architecture review
• The purpose of the review is to identify the
potential risks, early detection of defects
and errors in the architecture design,
including the architecture can meet the
demand, quality requirements is reflected
in the design, level is clear, component
division is reasonable, document
expression is clear, build the design to
meet the requirements of function and
performance.
 Implementation of the
architecture
• The so-called
"implementation" is to
display a software
architecture with
entities, which should
not only conform to
the structural design
decisions described in
the architecture,
divide them into
prescribed
construction, and
 Evolution of the architecture
• Architecture evolution
is the use of system
evolution steps to
modify applications to
meet new
requirements.
Software architecture style
 Overview of the software
architecture style
• Architecture style defines a family of systems, where an
architecture defines a vocabulary and a set of
constraints. The vocabulary contains some types of build
and connectors, and this set of constraints indicates how
the system combines these components and connectors.
 Classic architecture style
—— Pipe and filters
• In a pipeline / filter-style software architecture, each
component has a set of inputs and outputs, data entry
components, processed internally, and then produced by
data output. Therefore, the component here is called a
filter, and this style of connector is like a pipeline for data
flow transmission, passing the output of one filter to the
input of another filter.
 Classic architecture style
—— Data abstraction and object-oriented
organization
• The concept of abstract data type
plays an important role in
software systems, and the
software industry has generally
turned to use object-oriented
systems. This style builds on
data abstraction and object-
oriented, where representations
of data and their response
operations are encapsulated in
an abstract data type or object. A
component of this style is an
object, or an instance of an
abstract data type
 Classic architecture style
—— event driven system
• An event-driven system style is that the
component does not directly call a process, but
rather triggers or broadcasts one or more
events. Procedures in other components in the
system are registered in one or more events.
When an event is triggered, the system
automatically calls all the processes registered
in this event, so that the trigger of an event leads
to the call of the process in another module
 Classic architecture style
—— hierarchical system
• The hierarchical system
forms a hierarchy; each
level serves the upper layer
and acts as the lower
customer. In some
hierarchical systems,
outside of some carefully
selected output functions,
the internal layer interfaces
are only visible to the
adjacent layers. In such a
system, the components
implement the virtual
machines on the layer.
 5.3.2 Classic architecture style
—— Warehouse system and
knowledge base
• In the warehouse style,
there are two different
constructs: the central
secretary structure
explains the current state,
and the independent
components are executed
on the Zhongxiang data
storage.
• On the one hand, if the
control sharing data is
built, the warehouse is a
traditional database; on
the other hand, if the
 Classic architecture style
—— C2 style
• The C2 architecture style • The organization rules are as follows:
– Both the build and the connector
can be summarized as in the system have a top and a
parallel building networks bottom
by connections bound – The top of the build shall be
together under a set of connected to the bottom of a
connector and the bottom of the
rules, build to the top of a connector.
Direct connections between child
constructs is not allowed.
– A connector can be connected to
any number of other build and
connectors
– When two connections are directly
connected, they must go from the
bottom of one to the top of the
other
 Customer / Server style
• C / S style is an
application on the host
through a non-intelligent
terminal physically
connected to the host.
• The C / S architecture
•
has three main C/S
–
shortcoming:
Development costs are high
components: the – Client program to design clothing
database server, the – The information content and form
are single
client applications, and – User interface styles are
different
the network. – Software transplantation is
difficult
– Software maintenance and upgrade
are difficult
Three-layer C / S structure style
• The representation layer is the
user structure part of the
application for the dialogue
function with the application
logic
• The functional layer is the
application ontology and is
responsible for the specific
business processing logic
• The data layer is usually a
database management
system, which is responsible
for managing the reading and
writing of the database data
5.3.5 Browser / server style
• The browser / server
style (B / S) is an
implementation of the
above three-tier
application structure.
The specific structure
is the browser / web
server / database
server.
 Area-specific software
architecture
•
 Definition of the 5.4.1DSSA
• Simply put, (Domain • The essential
Specific Software characteristics of the
Architecture, DSSA) DSSA are as follows
is a standard software – A strictly top-by-one
architecture that problem domain.
provides an – Universal. Making it
organizational usable for the
development of a
reference for a set of
particular application in
applications in a the domain.
specific application – A proper abstraction
field. of the building
organization model of
 DSSA Basic activities
• Field analysis
– The primary goal of this phase is the live domain
model. The domain model describes the common
demand between the systems in the domain, that is,
the demand described by the domain model is the
domain demand.
• Field design
– The goal of this stage is a live DSSA. DSSA describes
the solution to the requirements represented in the
domain model, which is not a representation of a
single system, but a high-level design able to
accommodate the requirements of multiple systems in
the domain.
• Field implementation
– The primary goal of this phase is to develop and
organize reusable information based on domain
Personnel involved in the DSSA
• domain expert
• Field analyst
• Field designer
• Field realization personnel
 The DSSA establishment
process
• Define the domain scope.
• Define the domain-specific
elements
• Define the domain-specific
design and implementation
requirements constraints
• Define domain models and
architecture
• Generate, and collect the
reusable product units