SOFTWARE

ARCHITECTURE
Lecture 1
Software Crisis

The causes of the software crisis

 The scale of the software is getting bigger and bigger
 Increasing complexity
 Delivery time is relatively short
Software Crisis
The IBM 360 operating system developed by IBM of the United
States from 1963 to 1966 ， which took 5000 people a year to
work, with at most 1000 people working on development, and
nearly a million lines of programming…According to statistics,
each new release of the operating system is the result of finding
1000 bug fixes in the previous version…
The director of the project, F. D. Brooks, later summed up his
painful lessons in the development process:’... Just as a fugitive
beast falls into the mire and becomes a moribund struggle, the
more it struggles, the deeper it sinks, the last it cannot escape.
Programming is just like this. A lot of programmers are forced to
struggle in the mud... No one expected that the problem would
fall into such a predicament...’. The history of the IBM360
operating system has become a classic example of software
development projects.
Software Crisis

The crisis manifested itself in several ways

 Increasing software costs
 Development progress is difficult to control
 Software was very inefficient
 Software was of low quality
 Projects were unmanageable and code difficult to maintain
The main manifestation of the software crisis

 Increasing software costs

• In the 1950s software costs accounted for 10%
-20% of the total computer system cost. By the
mid-1960s, the share of software costs in
computer systems had risen to about 50%.
• Moreover, the figure is constantly increasing. The
following is a set of data from the Air Force
computer system: In 1955, software costs
accounted for about 18% of the total cost,
reaching 60% in 1970, reaching 72% in 1975 and
reached in 1980 80% in 1985 reached about 85%.
The main manifestation of the software crisis

 Development progress is difficult to control

• In the software development process, user’s
demand changes and other unexpected situations
emerge in an endless stream, making the software
development process is difficult to ensure that the
plan is achieved on schedule.
• Blindly increasing the software developer is not
proportional to improve the ability of software
development. On the contrary, with the increase of
the number of personnel, the problems of
personnel organization, coordination,
communication, training and management will be
even more serious.
The main manifestation of the software crisis

 Software was very inefficient and of low quality

• Due to the lack of guidance of engineering thought,
programmers almost always use their own ideas to
replace the user’s demand for software. The software
designs with randomness, many functions are just a
programmer‘s wishful thinking, which is the important
factor of the software is unsatisfactory
The main manifestation of the software crisis

 Projects were unmanageable and code difficult to

maintain
• Because in the process of software design and
development, the developers didn‘t strictly follow the
software development standard, and there is no complete
record of the true state of the system documentation,
resulting in great difficulties in software maintenance.
• Especially in the process of using the software, the original
developer may have left the original development
organization for various reasons, making the software
almost unmaintainable .
• Data show that the industry is responsible for the
maintenance of software to pay for the total hardware and
software costs of 40-75%.
How to overcome the software crisis ？
Introduction

The story about kennel, architecture and

modeling…
We are building a software skyscraper in a Kennel’s way
Kennel’s architecture design

One person can build

Need:
• Design plan (idea) in
the builder's mind
• Simple process:
building while thinking
• Simple tools
 Villa’s architecture design

Built by a team and

must be built effectively
and efficiently.

Need:
• Design, modeling
• Well defined process
• Powerful tools
Buildings’architecture design

HOW TO BUILD?
Story moral: pay attention to the design of
architecture

Point 1:the part and

the whole

Point 2:Modeling and

Implementation
Architecture

 The definition of Computer Architecture was

introduced by C.M Amdahl in introducing the IBM 360
system in 1965: Computer architecture is the
computer's property, conceptual structure and
functional characteristics, seen by programmers.

 The concept of Software Architecture was mentioned in

An Introduction to Software Architectur e by David Garlan
and Mary Shaw in 1993.
Reference material

 Bass L, Clements P, Kazman R, Software Architecture in

Practice, 2nd Edition, Addison Wesley, 2003.
 Shaw M, Garlan D, Software Architecture –
Perspectives on an emerging discipline, Prentice Hall,
1996.
 Stephen T.Albin, The Art of Software Architecture
Design Methods and Techniques,2003.
What is software architecture ？

 Definition of IEEE610.12—1990

Architecture is the basic organization of a system based

on the relationship between components and components,
the relationship between components and the environment,
and the principle that guides the design and evolution of the
above content.
Software Architecture = {Components, Connectors,
Environment, Principle}
What is software architecture ？

 Definition of Booch&Rumbaugh&Jacobson
• Software Architecture encompasses the significant decisions
about
• the organization of a software system,
• the selection of the structural elements and their interfaces by
which the system is composed together with - their behavior as
specified in the collaboration among those elements,
• the composition of these elements into progressively larger
subsystems,
• the architectural style that guides this organization, these
elements and their interfaces, their collaborations, and their
composition.

Software Architecture = {Components, Elements ,

Subsystems, Style}
What is software architecture ？

 Definition of Bass

The software architecture of a program or computing

system is one or more structures of the system, including the
software components, the external visual properties of the
components, and the relationships between the components.
 Definition of Garlan&Perry

The structure of the components of a program/system,

their interrelationships, and principles and guidelines
governing their design and evolution over time.
What is software architecture ？

 Definition of Shaw
Shaw made the following classification of the various views
of the software architecture definition ：
• Structure Model
This is the most Direct and prevalent module establishment
method. Using component /connector and other conception to
describe architecture , and inflect critical content including system
configuration/restriction/consumption/style and characters with
architecture.
Core to Structure Model is architecture description language.
What is software architecture ？

 Definition of Shaw
• Framework Model
Similar with Structure Model,not concentrate particularly
to detail, but to unitary framework.
Framework model is aiming to solution to special
problem.
• Dynamic Model
Supplement to structure and framework model, it
mainly focus on extensive behavior characters. For
example, description to system reconfiguration or
evolvement.
What is software architecture ？

 Definition of Shaw
• Process Model
• Research on steps and process of system
• Configuration model is following to Process Model
What is software architecture ？

 Definition of Garlan&Shaw ‘s model

Software Architecture = {Components, Connectors,

Constrains}
a. Component
Component can be a set of code, such as program
modules, it can be a separate program, such as a database
server. Component is a collection of related objects, running to
achieve some calculation logic. They are either structurally
related or logically related. The component is relatively
independent, only through interface and external interaction,
and the customization and normalization of component
embedded in different application systems can be significant for
the reuse of component.
What is software architecture ？

 Definition of Garlan&Shaw ‘s model

Software Architecture = {Components, Connectors,

Constrains}
b. Connector
Connector can be process calls, pipelines, remote
procedure calls, etc., which used to represent the
interaction between components, they connect different
components to form part of the architecture. The connector
is also a group of objects. It generally appears as a framed
or transposed object.
What is software architecture ？

 Definition of Garlan&Shaw ‘s model

Software Architecture = {Components, Connectors,

Constrains}
c. Constrain
The constraint is generally the rule of the object connection,
or indicates the attitude or condition of the connection of the
component, for example, the upper component can require the
service of the lower component, and vice versa. Two objects
must not send messages recursively. The consistency
constraints on code copy migration and under what conditions
is the connection invalid?
What is software architecture ？

 Definition of Perry&Worf ‘s model

software architecture is a set of architecture elements that

have a particular form. This set of elements is divided into 3
categories:
• The Processing Elements responsible for completing the
data processing
• the Data Elements being processed
• The Connecting Elements used to connect the different
combinations of the architectures together

Software Architecture = {Elements, Form, Rational}

What is software architecture ？

 Definition of Boehm ‘s model

Software architecture includes system components,

connectors, constraints, the set reflects the needs of different
groups of people, as well as rational.
Software Architecture = {Components, Connectors,
Constrains, Stakeholders’needs ,Rationale}
What is the significance of software
architecture?

“Good architecture design has always been a

major factor determining the success of a software
system”
 Architecture is the means by which stakeholders can
communicate

Software architecture represents the system's high level of public

abstraction. In this way, most, if not all, of the people involved in the
system can use it as a basis for building a mutual understanding and
form a common understanding and exchange of ideas.

Architecture provides a common language to express various

concerns and consultations, which makes rational management of
large and complex systems. This has a great impact on the final
quality and use of the project.
What is the significance of software
architecture?

 Architecture is the embodiment of early design decisions

• Software architecture defines the constraints of the system.
• Software architecture determines the organizational structure
for developing and maintaining the organization.
• Software architecture restricts the quality attributes of the
system.
• By studying the software architecture may predict the quality
of the software.
• Software architecture makes inference and control changes
easier.
• Software architecture is helpful for progressive prototyping.
• Software architecture can be used as a basis for training.
What is the significance of software
architecture?

 Software architecture is a transitive and reusable model

Software

Software architecture reuse means that architecture decisions can

affect multiple systems with similar needs, which is more
advantageous than code-level reuse.
The History of Software Architecture

Characterized by small-scale
‘Non-architecture’ design phase application development in
assembly language
The theme of program structure
design emerged, characterized
Germination phase by control flow graph and the
data flow graph as a software
structure
The structure model of the
system is described from
initial phase
different aspects, and UML is the
typical representative.
To describe the high-level abstraction
of the system structure as the center,
Advanced phase do not care about the modeling of
specific details, divides the
architecture model and the limits of
traditional software structure, the
phase marked by Kruchten suggests
‘4 + 1’ model
Research Status of Software Architecture

 Software architecture description research

• Software Architecture Description Language (ADL)
ADL is such a language that system designers can use the features
it provides to model software system conceptual architectures. ADL
provides a conceptual framework for specific syntax and
characterization architectures.
• Use the '4 + 1' model to describe the software
architecture
The ‘4 + 1’ model consists of a logical view, a development view,
a process view and a physical view, and organically combines the four
views through the scene.
• Use the UML to describe the software architecture
Research Status of Software Architecture

 Software architecture design research

• Architecture style research

• Architecture design principles

• Architecture Design Patterns

• Architecture design method

Research Status of Software Architecture

 Architecture-based software development methodology

• In essence, software architecture is an abstract solution to software
requirements. After introducing the software development of the
architecture, the construction process of the application system becomes ：
problem definition—software requirements—software architecture—
software implementation

 Software Architecture Assessment

 Common software evaluation methods include Software Architecture
Analysis Method(SAAM) and Architecture Tradeoff Analysis Method(ATAM).
They are both scenario based software architecture evaluation methods.

 Domain Specific Software Architecture (DSSA)

 DSSA applies software architecture theory to specific areas. Because
applications in specific areas have similar characteristics, they can learn from
the mature software systems in the field. Through the field of software
architecture, solutions can be achieved in a field of reuse 。

 Software Architecture Support Tools

Developing Directions of Software architecture

 Information exchange among various software architecture

languages
 Design tools and the environment
 Architecture re-engineering issues
Quality Attributes

 What is Quality Attribute ？

 A quality attribute (QA) is a measurable or testable
property of a system that is used to indicate how well
the system satisfies the needs of its stakeholders.
 How to express the Quality Attribute
 Availability
 Interoperability
 Modifiability
 Performance
 Security
 Testability
 Usability
 Other Quality attrbutes
Quality Attributes

 Availability
Availability refers to the ability of a system to mask or repair faults
such that the cumulative service outage period does not exceed a
required value over a specified time interval.
The availability of a system can be calculated as the probability
that it will provide the specified services within required bounds
over a specified time inter- val. When referring to hardware, there
is a well-known expression used to derive steady-state availability:
MTBF
(MTBF + MTTR)
where MTBF refers to the mean time between failures and MTTR
refers to the mean time to repair. In the software world, this
formula should be interpreted to mean that when thinking about
availability, you should think about what will make your system
fail, how likely that is to occur, and that there will be some time
required to repair it.
Quality Attributes

 Availability General Scenario

Quality Attributes

 Tactics for Availability

 Detect Faults
 Ping/echo Ping/echo refers to an asynchronous
request/response message pair ex- changed between
nodes, used to determine reachability and the round-trip
delay through the associated network path.
 Heartbeat Heartbeat is a fault detection mechanism that
employs a periodic message exchange between a system
monitor and a process being monitored.
 Exception detection Exception detection refers to the
detection of a system condition that alters the normal
flow of execution.
 …
Quality Attributes

 Tactics for Availability

 recover from faults
 preparation-and-repair .Preparation-and-repair tactics are
based on a variety of combinations of re- trying a
computation or introducing redundancy.
 reintroduction Reintroduction is where a failed
component is reintroduced after it has been corrected.
 Prevent faults
 Removal from service
 Transactions.
 Predictive model
 Exception prevention
 Increase competence set.
Quality Attributes

 Tactics for Availability

Quality Attributes

 Interoperability
Interoperability is about the degree to which two or more
systems can usefully exchange meaningful information via
interfaces in a particular context. The definition includes not
only having the ability to exchange data (syntactic
interoperability) but also having the ability to correctly interpret
the data being exchanged(semantic interoperability).
Quality Attributes

 Interoperability General Scenario

Quality Attributes

 Tactics for Interoperability

 Locate
 Discover service. Locate a service through searching a
known directory service. There may be multiple levels of
indirection in this location process—that is, a known
location points to another location that in turn can be
searched for the service. The service can be located by type
of service, by name, by location, or by some other attribute.
 Manage Interfaces
 Orchestrate. Orchestrate is a tactic that uses a control
mechanism to coordinate and manage and sequence the
invocation of particular services (which could be ignorant of
each other).
 Tailor interface. Tailor interface is a tactic that adds or
removes capabilities to an interface.
Quality Attributes

 Tactics for Interoperability

Quality Attributes

 Modifiability
Modifiability is the ability to quickly make changes to a system
at a higher performance-to-price ratio. Often based on some
specific changes, the modifiability is measured by examining
the costs of these changes.

• What can change?

• What is the likelihood of the change?

• When is the change made and who makes it?

• What is the cost of the change?

Quality Attributes

 Modifiability General Scenario

Quality Attributes

 Tactics for Modifiability

 Reduce the Size of a Module
 Split module. If the module being modified includes a
great deal of capability, the modification costs will likely be
high. Refining the module into several smaller modules
should reduce the average cost of future changes.
 Increase Cohesion
 Increase semantic coherence. If the responsibilities A and B
in a module do not serve the same purpose, they should
be placed in different modules. This may involve creating a
new module or it may involve moving a responsibility to an
existing module. One method for identifying
responsibilities to be moved is to hypothesize likely
changes that affect a module. If some responsibilities are
not affected by these changes, then those responsibilities
should probably be removed.
Quality Attributes

 Tactics for Modifiability

 Reduce Coupling
 Encapsulate. Encapsulation introduces an explicit interface
to a module.
 Use an intermediary breaks a dependency.
 Restrict dependencies is a tactic that restricts the modules
that a given module interacts with or depends on.
 Refactor is a tactic undertaken when two modules are
affected by the same change because they are (at least
partial) duplicates of each other. Code re- factoring is a
mainstay practice of Agile development projects, a
 Abstract common services.
 Defer Binding
 bind values at compile time or build time
 bind values at deployment time
 bind values at runtime
Quality Attributes

 Tactics for Modifiability

Quality Attributes

 Performance
It’s about time and the software system’s ability to meet
timing requirements. When events occur—interrupts, messages,
requests from users or other systems, or clock events marking
the passage of time—the system,or some element of the
system, must respond to them in time.Characterizing the events
that can occur (and when they can occur) and the system or
element’s time-based response to those events is the essence
is discussing performance.
Quality Attributes

 Performance General Scenario

Quality Attributes

 Tactics for Performance

 Control Resource Demand
 Manage sampling rate.
 Limit event response.
 Prioritize events.
 Reduce overhead.
 Bound execution times.
 Increase resource efficiency
 Manage Resources
 Increase resources.
 Introduce concurrency.
 Maintain multiple copies of computations.
 Maintain multiple copies of data.
 Bound queue sizes.
 Schedule resources.
Quality Attributes

 Tactics for Performance

Quality Attributes

 Security
 Security is a measure of the system’s ability to protect
data and information from unauthorized access while
still providing access to people and systems that are
authorized.

 The simplest approach to characterizing security has

three characteristics: Confidentiality, Integrity, and
Availability (CIA). Other characteristics that are used to
support CIA are these: Authentication , Nonrepudiation
, Authorization
Quality Attributes

 Security General Scenario

Quality Attributes

 Tactics for Security

 Detect Attacks
 Detect intrusion
 Detect service denial
 Verify message integrity
 Detect message delay
 Resist Attacks
 Identify actors.
 Authenticate actors.
 Authorize actors.
 Limit access.
 Limit exposure.
 Encrypt data.
 Separate entities.
 Change default settings.
Quality Attributes

 Tactics for Security

 React to Attacks
 Revoke access.
 Lock computer.
 Inform actors.
 Recover from Attacks
 maintain an audit trail
 Restore
Quality Attributes

 Tactics for Security

Quality Attributes

 Testability
Software testability refers to the ease with which software
can be made to demonstrate its faults through (typically
execution-based) testing. Specifically, testability refers to
the probability, assuming that the software has at least
one fault, that it will fail on its next test execution.
Intuitively, a system is testable if it“gives up” its faults
easily.
Quality Attributes

 Testability General Scenario

Quality Attributes

 Tactics for Testability

 Control and Observe System State
 Specialized interfaces.
 Record/playback.
 Localize state storage.
 Abstract data sources.
 Sandbox.
 Executable assertions.
 Limit Complexity
 Limit structural complexity
 Limit nondeterminism.
Quality Attributes

 Tactics for Testability

Quality Attributes

 Usability
Usability is concerned with how easy it is for the user to
accomplish a desired task and the kind of user support
the system provides.
 Usability comprises the following areas:
 Learning system features.

 Using a system efficiently.

 Minimizing the impact of errors.

 Adapting the system to user needs.

 Increasing confidence andatisfaction.

Quality Attributes

 Usability General Scenario

Quality Attributes

 Tactics for Usability

 Support user Initiative
 Cancel.
 Undo.
 Pause/resume.
 Aggregate.
 Support System Initiative
 Maintain task model.
 Maintain user model.
 Maintain system model.
Quality Attributes

 Tactics for Usability

Quality Attributes

 Other Important Quality attributes

 Variability

 Portability

 development distributability

 Scalability

 deployability

 Mobility

 Monitorability

 Safety