CS 3212

Software Architecture & Design

Dr. Chinthana Wimalasuriya

Lecture 1
Introduction to Software Architecture

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Course Logistics

 Lectures: Fridays 8.15 a.m. – 10.15 a.m.

 Lecturer: Dr. Chinthana Wimalasuriya
 Instructor/Grader: TBD
 Assessment
 Final Exam 60%
 Continuous Assessment 40%
 Assignments 10%
 Projects 30%

2
Software Architecture: Foundations, Theory, and Practice

Textbooks

 Recommended Textbook
 Richard Taylor, Nenad Medvidovic and Eric Dashofy, Softare
Architecture – Foundations, Theory and Practice, 2010
 Supplementary Textbooks
 Len Bass, Paul Clements and Rick Kazman, Software Architecture
in Practice, 2nd Edition, 2003
 Diomidis Spinellis and Georgios Gousios, Beautiful Architecture,
2009.
 Nick Rozanski and Eoin Woods, Software Systems Architecture,
2009.

3
Software Architecture: Foundations, Theory, and Practice

The Origins

 Software Engineers have always employed software

architectures
 Very often without realizing it!
 Address issues identified by researchers and
practitioners
 Essential software engineering difficulties
 Unique characteristics of programming-in-the-large
 Need for software reuse
 Many ideas originated in other (non-computing) domains

4
Software Architecture: Foundations, Theory, and Practice

Software Engineering Difficulties

 Software engineers deal with unique set of problems

 Young field with tremendous expectations
 Building of vastly complex, but intangible systems
 Software is not useful on its own e.g., unlike a car,
thus
 It must conform to changes in other engineering
areas
 Some problems can be eliminated
 These are Brooks’ “accidental difficulties”
 Other problems can be lessened, but not eliminated
 These are Brooks’ “essential difficulties”
5
Software Architecture: Foundations, Theory, and Practice

Accidental Difficulties

 Solutions exist
 Possibly waiting to be discovered

 Past productivity increases result of overcoming

 Inadequate programming constructs & abstractions

 Remedied by high-level programming languages

 Increased productivity by factor of five
 Complexity was never inherent in program at all

6
Software Architecture: Foundations, Theory, and Practice

Accidental Difficulties (cont’d)

 Past productivity increases result of overcoming (cont’d)

 Viewing results of programming decisions took long
time
 Remedied by time–sharing
 Turnaround time approaching limit of human
perception
 Difficulty of using heterogeneous programs

 Addressed by integrated software development

environments
 Support task that was conceptually always possible

7
Software Architecture: Foundations, Theory, and Practice

Essential Difficulties

 Only partial solutions exist for them, if any

 Cannot be abstracted away

 Complexity
 Conformity

 Changeability

 Intangibility

8
Software Architecture: Foundations, Theory, and Practice

Complexity

 No two software parts are alike

 If they are, they are abstracted away into one

 Complexity grows non-linearly with size

 E.g., it is impossible to enumerate all states of
program
 Except perhaps “toy” programs

9
Software Architecture: Foundations, Theory, and Practice

Conformity

 Software is required to conform to its

 Operating environment

 Hardware

 Often “last kid on block”

 Perceived as most conformable

10
Software Architecture: Foundations, Theory, and Practice

Changeability

 Change originates with

 New applications, users, machines, standards, laws

 Hardware problems

 Software is viewed as infinitely malleable

11
Software Architecture: Foundations, Theory, and Practice

Intangibility

 Software is not embedded in space

 Often no constraining physical laws

 No obvious representation
 E.g., familiar geometric shapes

12
Software Architecture: Foundations, Theory, and Practice

Pewter Bullets

 Ada, C++, Java and other high–level languages

 Object-oriented design/analysis/programming
 Artificial Intelligence
 Automatic Programming
 Graphical Programming
 Program Verification
 Environments & tools
 Workstations

13
Software Architecture: Foundations, Theory, and Practice

Promising Attacks On Complexity (In

1987)
 Buy vs. Build
 Requirements refinement & rapid prototyping
 Hardest part is deciding what to build (or buy?)

 Must show product to customer to get complete spec.

 Need for iterative feedback

14
Software Architecture: Foundations, Theory, and Practice

Promising Attacks On Complexity

(cont’d)
 Incremental/Evolutionary/Spiral Development
 Grow systems, don’t build them

 Good for morale

 Easy backtracking

 Early prototypes

 Great designers
 Good design can be taught; great design cannot

 Nurture great designers

15
Software Architecture: Foundations, Theory, and Practice

Primacy of Design

 Software engineers collect requirements, code, test,

integrate, configure, etc.
 An architecture-centric approach to software engineering
places an emphasis on design
 Design pervades the engineering activity from the
very beginning
 But how do we go about the task of architectural
design?

16
Software Architecture: Foundations, Theory, and Practice

Analogy: Architecture of Buildings

 We all live in them

 (We think) We know how they are built
 Requirements

 Design (blueprints)

 Construction

 Use

 This is similar (though not identical) to how we build

software

17
Software Architecture: Foundations, Theory, and Practice

Some Obvious Parallels

 Satisfaction of customers’ needs

 Specialization of labor
 Multiple perspectives of the final product
 Intermediate points where plans and progress are
reviewed

18
Software Architecture: Foundations, Theory, and Practice

Deeper Parallels

 Architecture is different from, but linked with the

product/structure
 Similarly, the principal design decisions characterizing a software
architecture, exist independently from, but are linked to, the
code that implements the architecture.
 Properties of structures are induced by the design of the
architecture
 Similarly, properties of software applications such as resilience to
certain types of security attacks are determined by the design of
their architectures.
 The architect has a distinctive role and character

19
Software Architecture: Foundations, Theory, and Practice

Deeper Parallels (cont’d)

 Process is not as important as architecture
 Architects and construction companies follow and
depend on standard processes to guide their daily
activities and ensure that all aspects of the design
and build activities are addressed.
 But, the design and resulting qualities are at the
forefront
 Process is a means, not an end

20
Software Architecture: Foundations, Theory, and Practice

Deeper Parallels (cont’d)

 Building architecture has matured over time into a
discipline
 A body of knowledge exists about how to create a wide range of
buildings to meet many types of needs
 Architectural styles as sets of constraints
 Swiss Chalet, Gothic Cathedral, New York Skyscraper
 Styles also as wide range of solutions, techniques and palettes
of compatible materials, colors, and sizes
 Similarly software architecture is maturing into a robust
discipline leveraging the knowledge gained from various
system development experiences.
 Software architectural styles are a major point of
intellectual leverage in creating complex software 21
systems.
Software Architecture: Foundations, Theory, and Practice

More about the Architect

 A distinctive role and character in a project

 Very broad training
 Competence of engineering

 Amasses and leverages extensive experience

 A keen sense of aesthetics

 Deep understanding of the domain

 Properties of structures, materials, and

environments
 Needs of customers (how people work, play, eat
and live)
22
Software Architecture: Foundations, Theory, and Practice

More about the Architect (cont’d)

 Even first-rate programming skills are insufficient for the

creation of complex software applications
 But are they even necessary?

23
Software Architecture: Foundations, Theory, and Practice

Limitations of the Analogy…

 We know a lot about buildings, much less about
software
 Hence, we need to be more methodical and analytical about
software
 The nature of software (intangible) is different from that
of building architecture (can discern by looking at it)
 Hence, with software, it is more difficult to measure progress,
analyze design qualities, etc.
 Software is much more malleable than physical materials
 The two “construction industries” are very different
 Software deployment has no counterpart in building
architecture
 Software is a machine; a building is not 24
Software Architecture: Foundations, Theory, and Practice

…But Still Very Real Power of

Architecture
 Giving preeminence to architecture offers the potential
for
 Intellectual control

 Conceptual integrity

 Effective basis for knowledge reuse

 Realizing experience, designs, and code

 Effective project communication

 Management of a set of variant systems

 Limited-term focus on architecture will not yield

significant benefits!
25
Software Architecture: Foundations, Theory, and Practice

Thus…

 Software architecture must be at the very heart of

software system design and development
 It must be in the foreground
 More than process

 More than component analysis

 And, more than programming

 This prominence has to be given over the entire lifespan

of the software development process.

26
Software Architecture: Foundations, Theory, and Practice

Notable Points

 All software systems have an architecture.

 There are good architectures, bad architectures, elegant
architectures, interesting architectures, dysfunctional
architectures and curious architectures.
 Your objective should be to develop the skills necessary
to ensure that the software systems you design have
good, elegant and effective architectures.

27
 Software Architecture: Foundations, Theory, and Practice

Architecture in Action: WWW

 This is the Web

28

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Software Architecture: Foundations, Theory, and Practice

Architecture in Action: WWW

 So is this

29

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Software Architecture: Foundations, Theory, and Practice

Architecture in Action: WWW

 And this

30

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

WWW in a (Big) Nutshell

 The Web is a collection of resources, each of which has

a unique name known as a uniform resource locator, or
“URL”.
 Each resource denotes, informally, some information.
 URI’s can be used to determine the identity of a machine
on the Internet, known as an origin server, where the
value of the resource may be ascertained.
 Communication is initiated by clients, known as user
agents, who make requests of servers.
 Web browsers are common instances of user agents.

31
Software Architecture: Foundations, Theory, and Practice

WWW in a (Big) Nutshell (cont’d)

 Resources can be manipulated through their

representations.
 HTML is a very common representation language
used on the Web.
 All communication between user agents and origin
servers must be performed by a simple, generic protocol
(HTTP), which offers the command methods GET, POST,
etc.
 All communication between user agents and origin
servers must be fully self-contained. (So-called “stateless
interactions”)
32
Software Architecture: Foundations, Theory, and Practice

WWW’s Architecture

 Architecture of the Web is wholly separate from the code

 There is no single piece of code that implements the
architecture.
 There are multiple pieces of code that implement the
various components of the architecture.
 E.g., different Web browsers

33
Software Architecture: Foundations, Theory, and Practice

WWW’s Architecture (cont’d)

 Stylistic constraints of the Web’s architectural style are

not apparent in the code
 The effects of the constraints are evident in the Web

 One of the world’s most successful applications is only

understood adequately from an architectural vantage
point.

34
Software Architecture: Foundations, Theory, and Practice

Architecture in Action:
Pipe and Filter on the Desktop
 Remember pipes and filters in Unix?
 ls invoices | grep –e august | sort

35
Software Architecture: Foundations, Theory, and Practice

Pipe and Filter on the Desktop

(contd.)
 Application architecture can be understood based on
very few rules
 Filter takes a stream of text characters as input and produces a
stream of characters as its output
 A filter’s processing may be controlled by a set of parameters
 Pipe is a way of connecting two filters (the character stream
output of the first filter is routed to the character stream input of
the second filter)
 Applications can be composed by non-programmers
 Akin to Lego blocks

 A simple architectural concept that can be

comprehended and applied by a broad audience
36
Software Architecture: Foundations, Theory, and Practice

“Genres” of Architecture

 Enterprise Architecture
 System of Systems Architecture
 Systems Architecture
 Software Architecture

37
Software Architecture: Foundations, Theory, and Practice

Commonalities between the

Genres
 Satisfaction of functional and quality attributes
 Evaluation of architecture for suitability
 Documentation and communication of the architecture
 Using the architecture as a blueprint for construction and
development.

38
Software Architecture: Foundations, Theory, and Practice

Activities for All Genres

 Understanding goals, context, and requirements

 Architecture creation, evaluation and documentation
 Managing the architecture post-creation (evolution)
 Assisting in post-architecture activities (maintenance,
conformance and performance analysis, etc.)

39
Software Architecture: Foundations, Theory, and Practice

Software Architecture and Other

Genres
 Software architectures show up in the architectures of
other genres
 Enterprise architecture and system architecture provide an
environment in which software lives.
 Both provide requirements and constraints to which software
architecture must adhere.
 Elements of both are likely to contain software architecture, but
neither substitutes for or obviates a software architecture.
 Both software and system architectures are critical for ensuring
that the system meets its business and mission goals.
 Each system in a SoS has system and software architectures.

40
Software Architecture: Foundations, Theory, and Practice

What is Software Architecture

 Software architecture encompasses the structure of

large software systems:
 Abstract view

 Eliminates details of implementation, algorithm and

data representation
 Concentrates on the behavior and interaction of
“black box” elements.

41
Software Architecture: Foundations, Theory, and Practice

Definition

 The software architecture of a program or a 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.

42
Software Architecture: Foundations, Theory, and Practice

Question

 What is the relationship of a system’s software

architecture to the environment in which the system will
be constructed and where it will exist?

43
Software Architecture: Foundations, Theory, and Practice

Answer

 It’s a cycle: Architecture Business Cycle (ABC)

 Software architecture is a result of technical, business
and social influences
 In turn, it affects each of these environments.

44
Software Architecture: Foundations, Theory, and Practice

Where do Architectures Come

From?
 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.
 Failure to satisfy documented as well as non-
documented constraints can cause many problems.

45
Software Architecture: Foundations, Theory, and Practice

Influences of Stakeholders on the

Architect

46
Software Architecture: Foundations, Theory, and Practice

Architectural Influences

 Stakeholders
 Each stakeholder has different concerns and goals,
some contradictory
 Development Organization
 Immediate business, long-term business, and
organizational (staff skills, schedule, and budget)
 Background and Experience of the Architects
 Repeat good results, avoid duplicating disasters

 The Technical Environment

 Standard industry practices or common SE techniques
47
Software Architecture: Foundations, Theory, and Practice

Ramification of Influences

 Almost never are the properties required by the business

and organizational goals consciously understood let
alone fully articulated.
 Architects need to know and understand the nature,
source, and priority of constraints on the project as
early as possible.
 Architects must identify and actively engage the
stakeholders to solicit their needs and expectations.
 Use architecture reviews and iterative prototyping.

48
Software Architecture: Foundations, Theory, and Practice

Main Message

 Architectures affect the factors that influence them

 The relationship among business goals, product
requirements, architect’s experience, architectures,
and field systems form a cycle with feedback loops
that a business can manage:
 To handle growth
 To expand enterprise area
 To take advantage of previous investments in
architecture and system building.

49