Software Architecture

and Design
Course introduction

Nguyen Huu Quoc

Lecturer
VLT-KKT
Van Lang University

© 2009, Based on Anthony J. Lattanze’s Lectures

Lecture Topics
 Describe the objectives of this course and
outline the course contents
 Discussion of what software architecture is
 the role and importance
 common architectural terminology
 levels of design abstraction

2/37
 Course Goals
 To make sure that you understand:
 that there are NO RECIPES in systemic design
 that design is based on judgment
 sound judgment is based on design principles
 that design documentation is more than UML, ad-hoc
drawings,…
 what design can be used for
To introduce you to principles that can help you
design and build better software intensive systems
in a more timely and cost effective way
3/37
Specific Objectives - 1
Understand the influence of architectural
drivers on the software structures a software
architect selects
Understand the technical, organizational, and
business role of software architecture
Recognize some major architectural structures
(patterns, tactics, etc.)

4/37
 Specific Objectives - 2
 Generate architectural alternatives in a given
context and choose among them
 Introduce a few architectural methods and
techniques
 Introduce software architecture evaluation
concepts and techniques to determine the fitness
of an architectural design
 Introduce the concept of product lines and
architectures role in creating successful product
lines

5/37
 General Course Overview
Part 1
 Course overview and basic concepts
 Architectural drivers
Part 2
 Structures
 Guidance for the architect
 Documentation

6/37
Have You Heard These Before?

System Architecture

Enterprise Software
Architterecture Architecture

Which do we have!? Which do we need!?

What is architecture?
7/37
 What is Architecture?
 Architecture is design...
From Merriam-Webster (2005):
1: the art or science of building;
2 a: formation or construction as or as if as the result
of conscious act
b: a unifying or coherent form or structure
3: architectural product or work
4: a method or style of building
5: the manner in which the components of a computer
or computer system are organized and integrated

8/37
 A Short History of Systems – 1
 Before the 19th century the word system had
little technological or mechanical meaning
 The term system was used to describe physiological
systems, philosophical systems, natural systems (e.g.
ecological or planetary systems)

 Aerospace  Environmental
 Biomedical  Mechanical
 Chemical  Materials
 Civil  Marine
 Electrical  Software
9/37
 A Short History of Systems – 2
 Systems thinking developed as a consequence of
complex devices being contrived in the late 19th
century
 The US transcontinental railroad
• The traditional mechanical arts body of knowledge proved
increasingly inadequate to address design complexities
The phone system (1877) electrical grid (1880)
 By 1920, AT&T engineers referred to their national
network as The System and the company had job titles
for System Engineers and had a Systems Development
department
10/37
 A Short History of Systems – 3
 Modern system engineering methods evolved
from the design and development of large
government defense systems from 1940 through
the 1960s
 The RAND Corporation (1946) created systems
analysis
• Espoused the idea of designing the larger system first, then
identifying and designing the parts, and finally assembling the
system from the parts
• This approach drove the need for more powerful abstractions
and methods – architecture design for systems was born

11/37
 State of the Practice – 1
 Eberhardt Rectin is viewed by many as the father of
modern system engineering and system architecture
following is classic textbook Systems Architecting:
Creating and Building Complex Systems
 defined and formalized the roles and responsibilities of
the system architect
 introduced a number of design heuristics and analytical
techniques that could be used by system architects to
develop architectures for systems
 Prior to Rectin, the term Architecture as confined to
building designs
12/37
 State of the Practice – 2
 Systems Engineering is a design and management
discipline for designing and building large,
complex, and inter-disciplinary systems. A critical
element of systems engineering is the system’s
architecture
 Describes the elements and interactions of a complete
system, and their contribution toward the goal of the
system
 Includes identifying and characterizing the system’s
elements, but not the substructure of the elements nor is
software design explicitly part of systems engineering
13/37
What I See in Practice

14/37
 What I See in Practice
A principle tenant of system
engineering is that bottom-up
integration is only possible
with sound top-down design
that begins with a robust
system architecture

Unfortunately there is little

guidance on the technical
aspects of architecting. The
focus of system engineering
remains on the programmatic
aspects

15/37
 Enterprise Architectures – 1
Enterprise architecture is a relative late comer to
the “architecture scene”
 Evolved from information technology (IT) systems
engineering group at IBM
 John Zachman of IBM described the basic tenets of IT
system or enterprise architectures
• he compared IT architecting activities to those of architects in
the building industry
• he later defined the Zachman Enterprise Architecture
Framework – emerged in the late 90’s
 Many Enterprise Architecture Frameworks (EAFs)
have emerged since Zachman’s original work
16/37
 Example Enterprise Architecture
 The Zachman Framework describes a holistic
model of an enterprise's information infrastructure
from six perspectives
 Planner
 Owner
 Designer
 Builder
 Subcontractor
 user
 In the Zachman Framework, these are the
stakeholders
17/37
Classic Sorting Problems

18/37
 The Cells
 The rows are very abstract and incomplete near
the top but become more detailed and specific
moving toward the bottom
 The top two rows are business-oriented and can be
expressed in business-oriented vocabularies
 The bottom four rows are in the technical domain
 An implementation emerges on the last row
 The framework contains 6 rows and 6 columns
yielding 36 unique cells or aspects

19/37
 Enterprise Architectures – 2
 Enterprise architecture is a means for describing
business structures and processes that connect
business structures†
• Describes flows of information and activities
between entities in an enterprise
• Enterprise architectures may or may not be supported
by computer (IT) systems
• Largely a documentation framework
• Software architectural design (really any technical
design) is not addressed explicitly by most EAFs

20/37
 Issues
 The Zachman Framework
 prescribes no specific
• order of column or row implementation
• architectural design process
• artifacts, implementation methods, and detailed design
methods…
 is a VERY coarse grained abstraction and defers
many of the important technical details
 usually requires help to use in practice
 results in copious amounts of documentation

21/37
 What I See in Practice
 There are LOTS of EAFs – many are based upon
Zachman's work
 Private: Zachman
 Government: C4ISR, DoDAF, TEAF, FEAF, TOGAF
 Proprietary: NCR Enterprise Architecture Framework
 Open Standards: ISO Reference Model for Open
Distributed Processing (ISO RM-ODP)
While most EAFs do not address technical design,
they help identify/define business processes,
entities, required infrastructure, applications,
organizational information flow, and so forth
22/37
Software Architecture Defined

“The software architecture of a program

or computing system is the structure or
structures of the system, which
comprise the software elements, the
externally visible properties of those
elements, and the relationships among
them.*”

23/37
Typical Description of a System’s
Architecture
You will regularly see these kinds of things in practice
–but what does it mean?
Is this a system architecture?

Figure X: Overall Software Structure

Controller Process
(CP)

Propagation Loss Reverberation Noise Mode

Model (ModP) Model (ModR) (ModN)

24/37
 What Does This Picture Say?
 The system has of four elements?
 Three of the elements have something in
common?
 they are positioned next to each other
 CP may be different from the other three
 All the elements apparently have some sort of
relationship since the diagram is fully
connected
 Besides this we know nothing else!

25/37
Enterprise, System, or Software
Architecture? – 1
 The short answer is, “it depends”
 Depends upon scope and the point of view
Hardware Point of View
Business Point of •hardware elements
THINGBEI
View •mechanical& electrical
NG BUILT
•business entities interfaces
•process flow
•organizational
context
Software Point of View
•software elements
•functional requirements
•compute hardware
Engineers view design from various points of view – all are important
and contribute to the construction of the thing begin built...
26/37
27/37
Good Intentions, Different Concerns
 Systems Engineers/Architects think in terms of
interdisciplinary design elements and how to best
design, schedule construction, integrate, and test very
large, distributed systems
Enterprise Architects think in terms of business
processes, organizational entities, information flow, and
infrastructure in complex, distributed organizations
While not stated – both systems and enterprises are
intimately dependent upon software for much of their
functionality

28/37
The Focus of This Course
“Software-intensive systems are any systems that
intimately depend upon software, the associated
computational hardware, operating systems, data,
and so forth to render service to stakeholders.” *

Our focus in this course will be Software Intensive System Design!

29/37
 Key Principles
 Architecture design is hierarchical
 What may be a concern for an enterprise architect, might not be
a concern for a software architect.
 A designer at one point constrains designers and implementers
downstream
 Detailed designs and implementation details are left to
downstream experts
Architecture is design, but not all design is architectural
 What is an architectural concern at one level of abstraction,
might be too much detail for another

“Always design a thing by considering it in its next larger context—a

chair in a room, a room in a house, a house in an environment, an
environment in a city plan.” Gottlieb Eliel Saarinen (1873–1950)

30/37
Architecture is Hierarchical
Enterprise: Business
Processes mapped to
coarse grained
infrastructure.
System: Traditional
focus on functional
requirements;
allocated
to physical elements;
systems-of-systems
Software: Multi-dimensional, satisfaction of
functional and non-functional requirements;
often orthogonal to system structures; critical to
satisfying business goals.
31/37
Architectural Design Concerns
Abstraction Granularity: Key Design Concerns:
o Business Processes and Operational Models
o Business Data
Enterprise Architecture o Organizational Structure and Relationships
o Enterprise Stakeholders
o IT Infrastructure
o Identification of System Context
o Partitioning (hardware/infrastructure focus)
System Architecture o Identification of Software Requirements
o Overall Systemic Functional Requirements
o Systemic Integration and Testing
o Identification of Crosscutting Design Concerns
(quality attributes)
Software Architecture o Software Functional Requirements
o Partitioning of Software Application(s)
o Software and Systemic Integration and Testing
o Language Features
o Algorithmic Efficiencies
Detail Software Design o Data Structure Design
o Software Application Testing
o Implementation of Functionality3

32/37
 Too Small For Architecture?
Sometimes systems are so small that the
architecture may seem deceptively trivial.
 The key word here is “deceptively”
Architectural reasoning holds throughout the
design spectrum
 Attention to systemic properties must come first
 This requires diligence in getting the architecture
drivers and attention to systemic Design
 Architecture design is a springboard for all subsequent
design
 Architecture design does not replace detailed design, it
complements detailed design
33/37
What Systems Have Architectures? – 1
 Every software intensive system has an
architecture whether it was deliberately designed
or not
 Every system is composed of elements, and there are
relationships among them
 Elements have responsibilities in the system
 In the simplest case, a system is composed of a
single element, related only to itself
 Architectures meet various functional needs,
promote some qualities (performance,
modifiability, and so forth) as well as inhibit other
34/37
What Systems Have Architectures? – 2
 Just having a software architecture is different
from having one that is known to everyone:
 Is the "as implemented architecture the same as the
specified?
• if not, then any promises made vis-à-vis the architecture are
null and void.
 What is the rationale for architectural decisions?
If you don’t explicitly develop an architecture,
you will get one anyway—and you might not
like what you get!

35/37
Architecture Design Defined
“The software architecture of a program or
computing system is the structure or
structures of the system, which comprise
the software elements, the externally
visible properties of those elements, and
the relationships among them.*”

*Bass, L.; Clements, P. & Kazman, R. Software Architecture in Practice, Second

Edition. Boston, MA: Addison-Wesley, 2003.

36/37
 Summary
We described the course goals and
established the course framework:
 We discussed the differences between system,
enterprise, and software architecture
 Introduced the concept of design concerns and
pointed out those architectural concerns we will
focus on in this course
 We also discussed the role and importance of
architecture design
 This course is about software intensive system
design and we will focus on software’s place in
systemic design
37/37
Questions & Answers

38/37