Lecture 1

Introduction To
Software Architecture
Architecture thinking
One possible answer
Role of software architecture
Context
 What is
software architecture ?
Definitions
 Architecture for a specific system may be captured as
“a collection of computational components – or simply
components – together with a description of the
interactions between these components – the
connectors”
An Introduction to Software Architecture - Garlan and Shaw (1993)

 The design process for identifying the subsystem

making up a system and the framework for sub-system
control and communication is the architecture design.
The output of this design process is a description of the
software architecture.
Software Engineering - Sommerville (2004)
Concept & examples
To sum up, we can define software architecture as
"The decomposition of software systems into modules"

Primary criteria: extendibility and reusability

Examples of software architecture techniques & principles:
 Abstract data types
 Object-oriented techniques: the notion of class,
inheritance, dynamic binding
 Object-oriented principles: uniform access, single-
choice, open-closed principle…
 Design patterns
 Classification of software architecture styles, e.g.
pipes and filters
Develop systems “architecturally”

 Design at an architectural level of abstraction

 Build systems compositionally from parts
 Assure that the system will satisfy critical
requirements before it is constructed
 Recognize and reuse standard architecture patterns
and styles
 Reuse codified architectural design expertise
 Reduce costs through product-lines
“Large” software systems

What may be large: any or all of

 Source size (lines of code)
 Binary size
 Number of users
 Number of developers
 Life of the project (years)
 Number of changes
 Number of versions
Process and product
o Software engineering affects both:
 Software products
 The processes used to obtain and operate them

o Products are not limited to code. Other examples

include requirements, design, documentation, test
plans, test results, bug reports

o Processes exists whether they are formalized or not

Software quality factors
Software engineering today

3 main cultures:
 Process
 Agile
 Object-oriented

The first 2 are usually seen as exclusive, but all have

major contributions to make.
Process culture

Emphasize:
 Plans
 Schedules
 Documents
 Requirements
 Specifications
 Order of tasks
 Commitments

Examples: Rational Unified Process, CMMI, Waterfall…

Agile culture

Characteristics:

o Short iterations
o Emphasis on working code; de-emphasis of plans
and documents
o Emphasis on testing; de-emphasis of specifications
and design . "Test-Driven Development"
o Constant customer involvement
o Refusal to commit to both functionality and deadlines
o Specific practices, e.g. Pair Programming

Examples: Extreme Programming (XP), Scrum

Agile culture

XP methodology Scrum framework

Object-oriented culture

Emphasizes:

 Seamless development
 Reversibility
 Single Product Principle
 Design by Contract
Software Architecture

 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.
 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

 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.
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:
 Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or system.
From Requirements to Architecture

 From problem definition to requirements specification

o Determine exactly what the customer and user want
o Specifies what the software product is to do

 From requirements specification to architecture

o Decompose software into modules with interfaces
o Specify high-level behavior, interactions, and non-functional properties
o Consider key tradeoffs
 Schedule vs. Budget
 Cost vs. Robustness
 Fault Tolerance vs. Size
 Security vs. Speed
o Maintain a record of design decisions and traceability
o Specifies how the software product is to do its tasks
Focus of Software Architecture

 Two primary focuses:  A framework for understanding

o System Structure system-level concerns
o Correspondence between o Global rates of flow
requirements and implementation o Communication patterns
o Execution Control Structure
o Scalability
o Paths of System Evolution
o Capacity
o Throughput
o Consistency
o Component Compatibility
Why software architecture ?

 A key to reducing development costs

o Component-based development philosophy
o Explicit system structure

 A natural evolution of design abstractions

o Structure and interaction details overshadow the choice of algorithms and data
structures in large/complex systems

 Benefits of explicit architectures

o A framework for satisfying requirements
o Technical basis for design
o Managerial basis for cost estimation & process management
o Effective basis for reuse
o Basis for consistency, dependency, and tradeoff analysis
o Avoidance of architectural erosion
Scope of Software Architecture
 Details of the architecture are a reflection of system
requirements and trade-offs made to satisfy them
 Possible decision factors
o Performance
o Compatibility with legacy software
o Planning for reuse
o Distribution profile
 Current and Future
o Safety, Security, Fault tolerance requirements
o Evolvability Needs
 Changes to processing algorithms
 Changes to data representation
 Modifications to the structure/functionality
Software “Architecting”
 The “architecting” problem lies in:
o Decomposition of a system into constitutional elements
o Composition of (existing) elements into a system

 Two idealized approaches

o Top-Down
 Decompose the large problem into sub-problems
 Implement or reuse components that solve the sub-problems
o Bottom-Up
 Implement new or reuse existing stand-alone components
 Compose (a subset of) the components into a system

 A realistic approach will require both.

Architecture Evaluation
 A software architecture is the earliest life-cycle artifact that
embodies significant design decisions.
 Analyzing for system qualities early in the life cycle allows for a
comparison of architectural options.
 With the advent of cost-effective, repeatable architecture
evaluation methods, architecture evaluation should be a standard
part of every architecture-based development methodology.
When and why to evaluate an architecture ?
 When building a system
o Evaluation should be done when deciding on architecture.

 When acquiring a system

o Architectural evaluation is useful if the system will have a long lifetime within
organization.
o Evaluation provides a mechanism for understanding how the system will evolve.
o Evaluation can also provide insight into other visual qualities.
A pattern example
A reservation panel

Flight sought from: Santa Barbara To: Zurich

Depart no earlier than: 03 Feb 2022 No later than: 04 Feb 2022

ERROR: Let’s choose a date in the future

Choose next action:

0 – Exit
1 – Help
2 – Further enquiry
3 – Reserve a seat
A reservation panel

Flight sought from: Santa Barbara To: Zurich

Depart no earlier than: 09 Feb 2022 No later than: 10 Feb 2022

AVAILABLE FLIGHTS: 2

Flt# UA 425 Dep 8:25 Arr 7:45 Thru: LAX, JFK

Flt# AA 082 Dep 7:40 Arr 9:15 Thru: LAX, DFW

Choose next action:

0 – Exit
1 – Help
2 – Further enquiry
3 – Reserve a seat
The transition diagram
What’s wrong with the previous solution ?

 Complex branching structure

 unstructured solution, difficult to-maintain source code
 Extendibility problems: dialogue structure "wired“ into
program structure.
A functional, top-down solution

Represent the structure of the diagram by a function

transition (i, k)
giving the state to go to from state i for choice k.

This describes the transitions of any particular

application.

Function transition may be implemented as a data

structure, for example a two-dimensional array.
The transition function

0 1 2 3
0 (Initial) 2
1 (Help) Exit Return
2 (Confirmation) Exit 3 0
3 (Reservation) Exit 4 2
4 (Seats) Exit 5 3
5 (Flights) Exit 0 4
The transition diagram
Software Architecture
in context
Fundamental Understanding

 3 fundamental understandings of software architecture

o Every application has an architecture
o Every application has at least one architect
o Architecture is not a phase of development
Wrong View: Architecture as a Phase

o Treating architecture as a phase denies its foundational role in

software development
o More than “high-level design”
o Architecture is also represented, e.g., by object code, source
code, …
Context of Software Architecture

o Requirements
o Design
o Implementation
o Analysis and Testing
o Evolution
o Development Process
Requirements Analysis

 Traditional SE suggests requirements analysis should be clean

and fresh by any consideration for a design
 However, without reference to existing architectures it
becomes difficult to assess practicality, schedules, or costs
o In building architecture we talk about specific rooms…
o …rather than the abstract concept “means for providing
shelter”
 In engineering, new products come from the observation of
existing solution and their limitations
New Perspective on Requirements Analysis

 Existing designs and architectures provide the solution

vocabulary
 Our understanding of what works now, and how it works,
affects our wants and perceived needs
 The insights from our experiences with existing systems
• helps us imagine what might work and
• enables us to assess development time and costs
 Requirements analysis and consideration of design must be
pursued at the same time
Non-Functional Properties (NFP)

 NFPs are the result of architectural choices

 NFP questions are raised as the result of architectural choices
 Specification of NFP might require an architectural framework
to enable their statement
 An architectural framework will be required for assessment of
whether the properties are achievable
The Twin Peaks Model

 The Twin Peaks Model is used in software development to iteratively develop the
architecture and the requirements.
 Both “peaks” are equally important.
Design and Architecture

 Design is an activity that pervades software development

 It is an activity that creates part of a system’s architecture
 Typically in the traditional Design Phase decisions concern
o A system’s structure
o Identification of its primary components
o Their interconnections
 Architecture denotes the set of principal design decisions
about a system
o That is more than just structure
Architecture-Centric Design

 Traditional design phase suggests translating the requirements

into algorithms, so a programmer can implement them
 Architecture-centric design
o stakeholder issues
o decision about use of Commercial off-the-shell (COTS)
component
o overarching style and structure
o package and primary class structure
o deployment issues
o post implementation/deployment issues
Design Techniques

o Basic conceptual tools

 Separation of concerns
 Abstraction
 Modularity

o Two illustrative widely adapted strategies

 Object-oriented design
 Domain-specific software architectures (DSSA)
Object-Oriented Design (OOD)

o Objects
 Main abstraction entity in OOD
 Encapsulations of state with functions for accessing and
manipulating that state
Advantages and Disadvantages of OOD
 Advantages
o UML modeling notation
o Design patterns
 Disadvantages
o Provides only
• One level of encapsulation (the object)
• One notion of interface
• One type of explicit connector (procedure call)
 Even message passing is realized via procedure calls
o OO programming language might dictate important design
decisions
o OOD assumes a shared address space
Domain Specific Software Architecture (DSSA)

o Capturing and characterizing the best solutions and best practices

from past projects within a domain
o Production of new applications can focus on the points of novel
variation
o Reuse applicable parts of the architecture and implementation
o Applicable for product lines
Implementation

o The objective is to create machine-executable source code

• That code should be faithful to the architecture
 Alternatively, it may adapt the architecture
 How much adaptation is allowed?
 Architecturally-relevant vs. unimportant adaptations
o It must fully develop all outstanding details of the application
Faithful Implementation
o All of the structural elements found in the architecture are
implemented in the source code
o Source code must not utilize major new computational elements
that have no corresponding elements in the architecture
o Source code must not contain new connections between
architectural elements that are not found in the architecture
Unfaithful Implementation

o The implementation does have an architecture

• It is latent, as opposed to what is documented.
o Failure to recognize the distinction between planned and
implemented architecture
• robs one of the ability to reason about the application’s
architecture in the future
• misleads all stakeholders regarding what they believe they
have as opposed to what they really have
• makes any development or evolution strategy that is based on
the documented (but inaccurate) architecture doomed to
failure
Implementation Strategies

o Generative techniques
• e.g. parser generators
o Frameworks
• collections of source code with identified places
where the engineer must “fill in the blanks”
o Middleware
• CORBA, DCOM, RPC, …
o Reuse-based techniques
• COTS, open-source, in-house
o Writing all code manually
How It All Fits Together
Analysis and Testing

o Analysis and testing are activities undertaken to assess the

qualities of an artifact
o The earlier an error is detected and corrected the lower the
aggregate cost
o Strict representations are required for analysis, so accurate
questions can be asked and answered
Analysis of Architectural Models

o Formal architectural model can be examined for internal

consistency and correctness
o An analysis on a formal model can reveal
 Component mismatch
 Incomplete specifications
 Undesired communication patterns
 Deadlocks
 Security flaws
o It can be used for size and development time estimations
Analysis of Architectural Models (cont’d)

 Architectural model
o may be examined for consistency with requirements
o may be used in determining analysis and testing strategies
for source code
o may be used to check if an implementation is faithful
Evolution and Maintenance
 All activities that chronologically follow the release of an
application
 Software will evolve
o Regardless of whether one is using an architecture-centric
development process or not
 The traditional software engineering approach to maintenance is
largely ad hoc
o Risk of architectural decay and overall quality degradation
 Architecture-centric approach
o Sustained focus on an explicit, substantive, modifiable,
faithful architectural model
Architecture-Centric Evolution Process

 Motivation
 Evaluation or assessment
 Design and choice of approach
 Action
o includes preparation for the next round of adaptation
Processes

 Traditional software process discussions make the process

activities the focal point
 In architecture-centric software engineering the product
becomes the focal point
 No single “right” software process for architecture-centric
software engineering exists
 THANK YOU
FOR LISTENING !