Software Architecture

Instructor: Dr. Iftikhar Ahmed Khan

Lectures 1-2-3,4

Slides prepared by the help of slides from Pan Wuming

(Software Engineering College, SEC)
 Rationale for the COURSE
• Designing, developing, and evolving complex
software systems requires a mastery of
analytical and technical skills, as well as a
knowledge of appropriate processes,
architectures and design patterns.
• Software architects building complex systems
must create the illusion of simplicity through
decomposition, abstraction, and encapsulation
of functionality.
 Course Objectives
Through study of this course, the students will be
able to understand, design and analyze systems
from an architectural viewpoint. In particular,
they will be able to
– analyze an architecture’s business context
– capture quality requirements with quality
scenarios
– achieve them by applying architecture tactics
– document architectural decisions

21/4/29 3
 Career Path
• Set your sights on becoming an expert in
software engineering
– gather broad experience
– develop technical, leadership,
communication and people skills

Senior
Individual Software Team
Software Architect
Contributor Engineer Leader
Engineer

Increasing responsibility, scope and challenge

21/4/29 4
 Why is learning knowledge about
architecture important?
• Software architecture is not emphasized in
software engineering course;
• The development of a large software system
is far beyond design and programming;
• A software architecture is the development
product that gives the highest return on
investment with respect to quality,
schedule, and cost.

21/4/29 5
• Credits (3)
• Pre-requisites
– Experience of programming in a high-
level programming language, e.g. C, C#
or Java
 Main contents of this course
• Envisioning Architecture
• Creating an Architecture
• Analyzing Architectures
• Moving From One System to Many

21/4/29 7
 Part One.  Envisioning Architecture

• The Architecture Business Cycle    

• What Is Software Architecture?  
• A-7E Avionics System: A Case Study in
Utilizing Architectural Structures  

21/4/29 8
 Part Two.  Creating an Architecture

• Understanding Quality Attributes  

• Achieving Qualities      
• Air Traffic Control: A Case Study in Designing for
High Availability
• Designing the Architecture
• Flight Simulation: A Case Study in an Architecture
for Integrability  
• Documenting Software Architectures  
• Reconstructing Software Architectures

21/4/29 9
 Part Three.  Analyzing Architectures
• The ATAM: A Comprehensive Method for
Architecture Evaluation
• The CBAM: A Quantitative Approach to
Architecture Design Decision Making      
• The World Wide Web
A Case Study in Interoperability

21/4/29 Software Architecture: Module 1 10

 Part Four.  Moving From One System
to Many
• Software Product Lines: Re-using
Architectural Assets
• CelsiusTech: A Case Study in Product
Line Development  
and if time permitted   
• J2EE/EJB: A Case Study of an Industry-
Standard Computing Infrastructure
• Software Architecture in the Future

21/4/29 Software Architecture: Module 1 11

 References
• Textbook
– Len Bass, Paul Clements, Rick Kazman , Software Architecture in
Practice, Second Edition,2nd, Addison Wesley ,2003 (Textbook)

Extended contents of this course can be found in

• Architecture style and documenting architecture
– Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R.,
Nord, R., Stafford, J. Documenting Software Architectures: Views and
Beyond. Addison-Wesley, 2003.
• Architecture design process
– Felix Bachmann, Len Bass, Mark Klein, Deriving Architectural
Tactics: A Step Toward Methodical Architectural Design, Technical
Report ,CMU/SEI-2003-TR-004, March 2003
– Felix Bachmann, Len Bass, Mark Klein, Preliminary Design of ArchE:
A Software Architecture Design Assistant, Technical Report
,CMU/SEI-2003-TR-021, September 2003

21/4/29 Software Architecture: Module 1 12

 the Architecture Business Cycle 
• Where Do Architectures Come From?    
• Software Processes and the Architecture
Business Cycle 
• What Makes a "Good" Architecture?

21/4/29 13
 Software Architecture: Definition
• The software architecture of a program or
computing system is the structure or structures
of the system, which comprise software
elements, the externally visible properties of
those elements, and the relationships among
them.
• The architectural view of a system is abstract,
distilling away details of implementation,
algorithm, and data representation and
concentrating on the behavior and interaction of
"black box" elements.
21/4/29 Software Architecture: Module 1 14
The Swedish Ship Vasa
• 1620 Sweden & Poland at war
• Swedish king to build a ship never before
– World's most formidable instrument of war: 70 meters
long, able to carry 300 soldiers, and with an astonishing
64 heavy guns mounted on two gun decks.
• Hybertsson a famous ship architect failed
• Inquiries followed, which concluded that the ship
was well built but "badly proportioned." In other
words, its architecture was flawed.
• 375 years old story, well illustrates the
Architecture Business Cycle
The Swedish Ship Vasa cont…
• organization goals  requirements 
architecture  system.
• The architecture flows from the architect's
experience and the technical environment
of the day.
• Hybertsson suffered from the fact that
neither of those were up to the task before
him
The Swedish Ship Vasa cont…
Three things that Hybertsson could have used and we
will study in this course:
• Case studies of successful architectures crafted to
satisfy demanding requirements, so as to help set
the technical playing field of the day.
• Methods to assess an architecture before any
system is built from it, so as to mitigate the risks
associated with launching unprecedented designs.
• Techniques for incremental architecture-based
development, so as to uncover design flaws before
it is too late to correct them
 Where Do Architectures Come From?

• An architecture is the result of a set of

business and technical decisions.
• In any development effort, the
requirements make explicit some—but
only some—of the desired properties of the
final system.

21/4/29 Software Architecture: Module 1 18

 Architectures Are Influenced By
System Stakeholders
• Stakeholders have different concerns that
they wish the system to guarantee or
optimize.
– performance, reliability, availability,
platform compatibility, memory
utilization, network usage, security,
modifiability, usability, and
interoperability with other systems as well
as behavior.

21/4/29 Software Architecture: Module 1 19

 Architectures Are Influenced By The
Developing Organization
• Immediate business
– immediate business investment in certain assets,
such as existing architectures and the products
based on them.
• long-term business
– long-term business investment in an infrastructure
to pursue strategic goals and may view the
proposed system as one means of financing and
extending that infrastructure
• organizational structure.
– Like Hierarchical, Horizontal, Branched etc..

21/4/29 21
 Influenced By The Background And
Experience Of The Architects
• Experience
• architect's education and training, exposure
to successful architectural patterns,
• exposure to systems that have worked
particularly poorly or particularly well.

21/4/29 22
 Architectures Are Influenced By The
Technical Environment
• It include standard industry practices or
software engineering techniques prevalent in
the architect's professional community.

21/4/29 Software Architecture: Module 1 23

Complications of Influences on an
Architecture
• Architects need to know and understand
the nature, source, and priority of
constraints on the project as early as
possible
• They must identify and actively engage the
stakeholders to solicit their needs and
expectations.

Software Architecture: Module 1 24

 Influences on the architecture
Architect’s Influences

Customers
and End User
Requirements
(Qualities) Architect
Developing Architecture
Organization

Technical System
Environment

Architect’s
Experience

21/4/29 Software Architecture: Module 1 25

Architecture Business Cycle (ABC)
• What is the relationship of a system's software
architecture to the environment in which the system
will be constructed and exist?
• Software architecture is a result of technical, business,
and social influences.
• Its existence in turn affects the technical, business,
and social environments that subsequently
influence future architectures.
• This cycle of influences, from the environment to
the architecture and back to the environment, the
Architecture Business Cycle (ABC).
 Architecture Business Cycle

Architect’s Influences

Customers
and End User
Requirements
(Qualities) Architect
Developing Architecture
Organization

Technical System
Environment

Architect’s
Experience

21/4/29
 The architecture affects the structure
of the developing organization
• Architecture prescribes the units of software
that must be implemented (or otherwise
obtained) and integrated to form the system.
• These units are the basis for the development
project's structure.
• Teams are formed for individual software
units; and the development, test, and
integration activities all revolve around the
units.

21/4/29 Software Architecture: Module 1 28

 The architecture affects the structure
of the developing organization cont…
• Likewise, schedules and budgets allocate
resources in chunks corresponding to the
units
• If a company becomes adept at building
families of similar systems, it will tend to
invest in each team by nurturing each area of
expertise

21/4/29 Software Architecture: Module 1 29

 The architecture can affect the goals
of the developing organization
• A successful system built from an
organization can enable it to establish a
foothold in a particular market area.
• The architecture can provide opportunities
for the efficient production and
deployment of similar systems, and the
organization may adjust its goals to take
advantage of its newfound expertise to
plumb the market
• Feedback from the system  developing
organization
21/4/29 Software Architecture: Module 1 30
 The architecture can affect customer
requirements for the next system
• Giving the customer the opportunity to receive a
system (based on the same architecture) in a
more reliable, timely, and economical manner than
if the subsequent system were to be built from
scratch.
• The customer may be willing to relax some
requirements to gain these economies

21/4/29 Software Architecture: Module 1 31

 The architecture can affect architects
experience
• A system that was successfully built around
a tool bus or .NET or encapsulated finite-
state machines will engender similar
systems built the same way in the future.
• On the other hand, architectures that fail are
less likely to be chosen for future projects.

21/4/29 Software Architecture: Module 1 32

 Few systems will influence and actually
change the software engineering culture
• The first relational databases, compiler
generators, and table-driven operating
systems had this effect in the 1960s and
early 1970s;
• The first spreadsheets and windowing
systems, in the 1980s.
• The World Wide Web is the example for the
1990’s
• J2EE may be the example for the first decade
of the twenty-first century

21/4/29 Software Architecture: Module 1 33

 the Architecture Business Cycle 
• Where Do Architectures Come From?    
• Software Processes and the Architecture
Business Cycle 
• What Makes a "Good" Architecture?

21/4/29 Software Architecture: Module 1 34

 Architecture-Based Process Steps
• Create the business case for the system
• Understand the requirements
• Create or select the architecture
• Represent and communicate the architecture
• Analyze or evaluate the architecture
• Implement the system based on the architecture
• Ensure the implementation conforms to the
architecture

21/4/29 Software Architecture: Module 1 35

 Architecture in the Product Life-Cycle

Inception Elaboration Construction Transition Upgrade

Envision Create Architecture Reuse

and Other
Analyze Products
System
Inception

Architectural Baseline Inception

21/4/29
Creating the Business Case for the System
• It is an important step in creating and constraining
any future requirements.
– How much should the product cost?
– What is its targeted market?
– What is its targeted time to market?
– Will it need to interface with other systems?
– Are there system limitations that it must work within?
• These are all questions that must involve the
system's architects. They cannot be decided solely
by an architect, but if an architect is not consulted in
the creation of the business case, it may be
impossible to achieve the business goals
Understanding the Requirements
• Understanding Requirements by the help of
one or combination of these techniques
– object-oriented analysis uses scenarios
– finite-state-machine models for safety
critical systems
– creation of prototypes
Creating or Selecting the Architecture
“Conceptual integrity is the key to sound
system design and that conceptual integrity
can only be had by a small number of minds
coming together to design the system's
architecture.” (Fred Brooks, Mythical Man-
Month)
• Appropriate decision to create or to use an
existing architecture depends on what you
have with you (Team, Resources,
Requirements)
Communicating the Architecture
• For effectiveness of the project's design, it
must be communicated clearly and
unambiguously to all of the stakeholders.
– Developers must understand the work
assignments
– Testers must understand the task structure it
imposes on them
– Management must understand the scheduling
implications it suggests and so forth
• Architecture's documentation should be
informative, unambiguous, and readable by
many people with varied backgrounds
Analyzing or Evaluating the Architecture
• In any design process there will be multiple
candidate designs considered. Some will be rejected
immediately. Others will contend for primacy.
• Choosing among these competing designs in a
rational way is one of the architect's greatest
challenges
• For judging and architecture for qualities that could
support the system Scenario-based techniques,
Architecture Tradeoff Analysis Method (ATAM) or
Cost Benefit Analysis Method (CBAM) could be
used
Implementing Based on the Architecture
• Keep developers faithful to the structures
and interaction protocols constrained by the
architecture.
• Having an explicit and well-communicated
architecture is the first step toward ensuring
architectural conformance.
• Having an environment or infrastructure
that actively assists developers in creating
and maintaining the architecture (as
opposed to just the code) is better.
Ensuring Conformance to an Architecture
• Constant vigilance is required in the
maintenance phase to ensure that the actual
architecture and its representation remain
faithful to each other during this phase.
• Although work in this area is comparatively
immature, there has been intense activity in
recent years.
• Reconstructing architectures from existing
system is an example
 the Architecture Business Cycle 
• Where Do Architectures Come From?    
• Software Processes and the Architecture
Business Cycle 
• What Makes a "Good" Architecture?

21/4/29 Software Architecture: Module 1 44

Good or Bad Architecture
• Same technical requirements for a system,
two different architects in different
organizations will produce different
architectures
• Which one of them is the right one?
• There is no such thing as an inherently good
or bad architecture. Architectures are either
more or less fit for some stated purpose
Good or Bad Architecture
• Good thing is that architectures can in fact be
evaluated—one of the great benefits of paying
attention to them—but only in the context of
specific goals
• There are rules of thumb that should be followed
when designing an architecture. Failure to apply
these rules does not mean that architecture will be
flawed, but serves as a warning sign that should be
investigated
• Two types of observations for these rules
• Process Guidelines and Product Guidelines
 Architecture Process Guidelines
There are rules of thumb that should be followed
when designing an architecture. Process
Guidelines are:
• Single architect or small group with identified
leader
• Must have system technical requirements and
articulated, prioritized qualitative properties
• Architecture must be well-documented using an
agreed-on notation that all can understand
• Architecture should be actively reviewed by all
stakeholders
21/4/29 Software Architecture: Module 1 47
 Architecture Process Guidelines
(Cont.)
• Analyze architecture for applicable quality
measures and formally review early in
process
• Architecture should allow creation of a
skeletal system on which functionality can
incrementally grow
• Architecture should result in specific
resource restriction/allocation models
(memory, bandwidth, time)

21/4/29 Software Architecture: Module 1 48

 Product (Structural) Guidelines
• Well-defined functional modules using
information hiding, separation of concerns, and
well-defined interfaces
• Module separation of concerns should allow
concurrent, relatively independent development
by separate teams
• Quality attributes should be achieved using well-
known architectural tactics specific to each
attribute
• Never depend on a particular version of a
commercial product or tool; make change
straightforward and inexpensive

21/4/29 Software Architecture: Module 1 49

 Product (Structural) Guidelines (Cont.)
• Separate data producers from data
consumers
• Parallel processing: well-defined processes
and tasks that may not mirror module
structure
• Process or task assignment to processors
must be easily changed, even at run-time
• Consistently use a small number of simple
interaction patterns

21/4/29 Software Architecture: Module 1 50

 Summary
• Requirements are always insufficient for
architecture design.
• An architecture is the result of a set of
business and technical decisions.
• The architecture affects things that influence
the architecture itself.
• Architecture Process

21/4/29 Software Architecture: Module 1 52