Software Architecture Agenda

• Definition
• Why software architecture
Introduction • Architecting software
• What is a Software Architecture
• Examples
Olivier Boissier • Architectural assets
Mines Saint-Etienne • References
Olivier.Boissier@emse.fr
Fall 2019
1 2

Software Architecture
Abstraction
Software Architecture (2)
High-level design of a software
• Its role is about the:
system, showing which desired
• Function (or purpose): mission, as described by some use cases in
system properties are achieved,
some scenario, functional or logical elements
and the reasons for their
• Form (or structure): model of the system, physical or structural
achievement. components of the system and their relationships
• Principles or patterns
‘‘set of structures needed to reason about the system, which • It is about:
Manage complexity in the design
comprise software elements, relations among them, and • the concern of the stakeholders,
properties of both’’ Swebok v3 • the gap between a current system's design and its future design
• Notes: • the evaluation of the properties which govern the design and the
• it refers also to the discipline concerned with the study of software evolution of a system
structures and architectures in a more generic way. • the fundamental decisions that contribute to its utility, cost, effort to
• It refers also to the documentation of a system’s software architecture build, and risk to use within its environment
3 • what is hard to change 4
 Short History Agenda
• The basics of software architecture were introduced by Dijkstra
(1968) and Parnas (1970). They studied: • Definition
• The key role of the structure of a software system, and
• Why software architecture
• How tricky the definition of the right structure for a given system is
• Architecting software
• A great deal of research has been conducted on software • What is a Software Architecture
architectures starting from the 90’s, mainly focusing on:
• How to solve recurrent architectural problems (patterns) • Examples
• Which architectural forms are more common (styles)
• Architectural assets
• Defining languages to describe software architectures (ADL)
• How to document the architecture of a system (views) • References
• ... claimed to give rise to the definition of a discipline
• See: Shaw and Garlan Software Architecture: Perspectives on an Emerging
Discipline, 1996 5 6

Increasing complexity Large software landscape

• Software systems are larger and complex
• In 2007 the Windows operating system scales to 60 million lines of
code (LoC) from 15 million lines in 1995
• Kinds of software • Software Standards
• Middleware • Standard IEEE: development
• In 2011, the size of software in BMW 7 Series reaches 200 million
• Embedded methods
LoC
• 2011 the size of sw in Airbus 380 reaches 1 billion LoC. • Open Source • Standard OMG: UML and
• Web Services CORBA
• 2015 Google is 2 billions LoC
• Standard W3C: Web
• Mobile (e.g. applet)
technologies
• Data Mining, Search engine
• Design in the Large becomes the common rule • Standard OASIS: Business
• Agents
• From objects and methods … Process
• Social software (e.g. Web 2.0)
• … To modules and components …
• Software ecosystems
• … … To large and complex systems …
• …
• … … … To systems of systems …
• … … … … To … 7 8
 Producing software is difficult The magic triangle
• Complexity derives from
• Quality Characteristics
• Fast technical innovation
(ISO 25010)
• Strong international competition • Functionality
• Psychological issues • Performance Efficiency
• Organizational issues • Compatibility
• Lack of professionals trained on software design and development • Usability
• Reusability
• Typical failures: bad project management, wrong • Security
requirements, mediocre design, excessive costs • Maintainability
• Stakeholders with contrasting interests • Portability

• New projects start with high risks, scarcely analyzed • Effort/Cost and Time
• Development
• Maintenance
Wrong decisions in crafting the software architecture of a
system are a major cause of project cancellation 9 10

Software reuse levels Agenda

• Design Patterns • Definition
• reuse the idea not the code
• Open Source • Why software architecture?
• reusable applications
• Architecting software
• Software cloning
• copy and paste, pb is maintainability and intellectual property • What is a Software Architecture?
• Component-based software engineering • Views and Viewpoints on Architecture
• Component-Off-The-Shelf
• Software product lines • Basic Elements
• produce a new member of the family focusing on the variable part
• Examples
• Software architectures
• reuse of elements, their relations and the related decisions • Architectural assets
11 • References 12
 Software Architecting vs
Architecting Software
Software Engineering
• Creative AND decision-making process rather than an
activity • Software Architecting
• Studies decisions which rule the design of software systems and
studies software reuse methods
• Fundamental decisions: • Is centered on the idea of reducing the complexity of software
• based on the impact on quality attributes and tradeoffs among through abstraction, separation of concerns, and reuse
competing quality attributes • Is still quite immature: it is hard to find two software architects who
• that profoundly affect the software and the development process agree on the right way to design a software system
• Software Engineering
• Software Architecture is the result of this decision process: • studies the methods to build software systems and products, the
• Software architecture is the set of design decisions which, if made theories at their basis, and the tools useful to develop and measure
the qualities of software
incorrectly, may cause your project to be cancelled (Eoin Woods)
• The software architecture represents the "significant decisions", • deals with limited resources
where significance is measured by cost of change (Grady Booch) • is a discipline strongly empirical, that is based on experience and
13 past projects 14

Software Architecture vs Requirements &

Soft. Design, Soft. Requirements Architectural Design
• Software requirements:
• state ‘what’ the software should do, but not ‘how’ • Which Requirements Are Most Important to Architectural Design?
• can be functional and non functional
Functional
• Software architecture: Requirements
• what, where and why but not the how Design Architectural Software
• High level views showing how the system meets the requirements, Constraints Design Architecture
documents the main software components and how they interact
with each other Non-Functional
• Is very abstract, deliberately hiding any details Requirements = Quality Attribute
• Which requirements are the most important when it comes to structuring
• Software design: an architecture?
• is the how of a software development process 15 After Architecting Software the SEI Way 16
 Requirements &
What to consider?
Something to Consider Architectural Design
• What’s wrong with designing a system that has one big source module,
What’s wrong with designing a system that has one big source module, one
one big object module, and one big executable as long as it functions
big object module, and one big executable as long as it functions properly? • Which Requirements Are Most Important to Architectural Design?
properly?
buildability portability
Functional
Module
modifiability 1 :
reliability Requirements
testability
2
3
:
: distributability Design Architectural Software
.
. Constraints Design Architecture
complexity . availability
1,999,999 :
2,000,000 : Non-Functional
maintainability reusability
Requirements = Quality Attribute
Others?

?
• What determines whether these requirements are met?
Which requirements do you think would be
• Which requirements do you think
negatively impacted would
by this be ? negatively impacted by
“design”?
this “design”? 17 18
After Architecting Software the SEI Way After Architecting Software the SEI Way

Architecting Software the SEI Way

Twitter #SEIArchitecture
© 2012 Carnegie Mellon University

Other influences on Examples of other influences

Architecture on Architecture
• Stakeholders
• customers, users, managers, marketing, developers, maintainers, etc.
• Development organization
Requirements • immediate and long term business goals organizational structure

Architectural Software • Technical environment

c es Design Architecture • object oriented, WWW, intelligent agents, EJB, service oriented,

lu en J2EE, thin client, .NET, etc.

Technical in f • Background and experience
Business • architect and organizational experience
Social • education and training

After Architecting Software the SEI Way 19 After Architecting Software the SEI Way 20
 Architecture is a source of Architectural Design
influences Context
Context andandArchitecture
design

Requirements
Context and architecture
https://www.iasaglobal.org/on-making-architectural-decisions/
Architectural Software
s Design Architecture
ce
lu en
Technical in f
Business
influences
Social
Understanding this cycle of influences helps us to plan for and manage
change throughout the lifetime of a system.
After Architecting Software the SEI Way 21 22
8

Architecting Software Agenda

• Architectural design has no stopping rule: • Definition
• no criterion telling when the architecture is finished
• Solutions to architectural problems are not correct or wrong: • Why software architecture
• usually they are good or bad; solving one problem may very well • Architecting software
result in an entirely different problem elsewhere in the system
• Architectural design involves trade-offs, such as those • What is a Software Architecture
between speed and robustness:
• Architecture X Function
• as a consequence, there is a number of acceptable solutions, rather
than one best solution • Views and Viewpoints on Architecture
• Architectural design problems do not have a well-defined set • Basic Elements
of potential solutions:
• software architects cannot exploit a set of ready-made solutions, but • Examples
have to apply knowledge, practices, and creativity to arrive at a
satisfactory solution • Architectural assets
23 25
• References
 Form X Function Form X Function
NoTwo Architectures
Unique for Web Search
and Definitive Architecture
Architecture
Altavista A
search engine Architecture
Google B
search engine

Two
requests requests
Architectures

© 2014 Jonathan Aldrich

For Web Search

...
network
switch

Big server
Cluster of
commodity
How does architecture affect system properties?
Two Architectures for Sending Email
• Modifiability / ease of change
servers

sendmail qmail
• Consistency of results
Modules
• Systemwithin sendmail process
cost Processes implementing qmail
• Scalability of system
• Reliability of system
Two
Architectures

© 2014 Jonathan Aldrich

Software Architecture
For Sending Mail

26 27
Which architecture was better in 1980? Which was better in 2000?
Factors to consider
• Simplicity
• Efficiency

Form X Function Form X Function

• Security
Software Architecture

ANo
taleUnique and Definitive Architecture
of two systems No Unique and Definitive Architecture

• Rackspace (https://www.rackspace.com/)
• Hosting provider
• Huge growth in customers, mail servers – and problems
• Re-designs: 3 major versions (6 total versions)

• All 3 systems they build had the same functionality (!) … but
different architectures

• Changes motivated by quality attributes

28 29
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2014
 Software Architecture Prescriptive Architecture
Principal design decisions vs Descriptive Architecture
A software system’s architecture is the set of principal design
decisions made about the system (N. Taylor et al.) • Prescriptive architecture is the Descriptive architecture is
system’s as-intended or as- the system’s as-realized
conceived architecture architecture
Design decisions encompass every aspect of the system under
• It may captured in a notation such
development, including:
architecture description language
• System structure (e.g. the architectural elements should be organized and
composed exactly like this)
• Functional behavior (e.g. data processing, storage, and visualization will
be performed in strict sequence)
• Interaction, relationships (e.g. communication among all system elements
will occur only using event notifications)
• Non functional properties (e.g. the system’s dependability will be ensured
by replicated processing modules)
• Implementation, physical (e.g. the user interface components will be built
using the Java Swing Toolkit) 30 31
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; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture w.r.t.

Other XXX Architectures
XXX Architectures
• Network architecture: concerned with the network infrastructure of systems,
i.e. functions, services, building blocks, and protocols of a network.

• Integration architecture: connecting multiple applications or systems of one

or more enterprises and thus integrating heterogeneous platforms, data,
technologies, organizations.

• Data architecture: encompasses the data-oriented aspects of a system by

considering the design of logical and physical data models, the selection of
persistence mechanisms (e.g., database or file system), the configuration of
a database, and the design of a data warehouse.

• Security architecture: focuses on guaranteeing confidentiality, integrity,

availability of systems or system landscapes, identity and authorization
checks, and the verifiability and non-repudiation of security-relevant
23
32 operations. 33
 Is this an architecture? Agenda
• An attempt to describe the architecture of an underwater acoustic • Definition
simulation
• Why software architecture
• Architecting software
• What is a Software Architecture
• Architecture X Function
• Views and Viewpoints on Architecture
Missing: • Basic Elements
• What is the nature of the elements?
• Examples
• What are the responsibilities, behaviors of the elements?
• What is the significance of the connections? What are the • Architectural assets
influences of an element on another element?
• What is the significance of the layout?
35 • References 36

Architecture Conceptual Model

IEEE 1471 Standard Views and Viewpoints
• An architecture goal is to respond to specific stakeholders’ concerns
• Architecture descriptions are inherently multi-view, as no single view can • An architecture is described by a collection of models/
capture all stakeholders’ concerns about an architecture blueprints
• The notion of a view is separate from a viewpoint, which identifies the set of • Models are organized into views addressing varying levels of
concerns and the representations/modeling techniques, etc. used to abstraction and different viewpoints
describe the architecture to address those concerns • the first (top-most) set of blueprints is special, and is also referred to
• A conforming architecture description has a 1-to-1 correspondence as ‘the architecture’ (or better: ‘the architecture description’ AD):
between its viewpoints and its views • it needs to make the transition to the real world (technical and operational
environment, use cases)
• it presents the system at a high level (the highest) of abstraction
• IEEE 1471 standard: Recommended Practice for Architecture Description
of Software-Intensive Systems • as such it is used for understanding, analysis,
• “weakest” type of IEEE standards, whose adoption and interpretation are the communication, construction, documentation .... answering
responsibility of the using organization questions
• Has been adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007, in 2007, most recent • e.g. evaluation of utility, cost and risk
version is ISO/IEC/IEEE 42010:2011
37 38
Views and Viewpoints (cont’d) Architectural Frameworks
Architectural frameworks are methods for creating, interpreting,
analyzing and using architectural models within a domain of
• Viewpoints are common • Views are subset of
application or a stakeholder community
concerns shared by different architectural design decisions
people in the software and in relation to viewpoints:
• 4+1 Architectural View • Open Group Architecture
its architecture: • Requirements
Model (Krutchen 95) Framework (TOGAF):
• Architects • Functional
• Development View • Business Architecture
• Developers • Logical
• Logical View • Application Architecture
• Testers • Data
• Physical View • Data Architecture
• Managers • Implementation
• Process View • Technical Architecture
• Customers • Execution,
• Use Cases
• End users • Performance
• Security Others: Hofmeister & Nord & Soni’s framework, Rozanski &
• Vendors
• Physical Woods’ framework, Clements & Bass’ framework, C4 framework
• Deployment 39 by Simon Brown 40

4+1 Architectural Views

4+1 Architectural Views
• facets of a software design that can be described and
Use Case View
• Unify and link the elements of the other 4 views
documented (logical, process, physical, development)
• Help to ensure the architectural model addresses
Classes, Objects, Components
all the requirements
Collaboration, Sequences
Logical View Development View • Each scenario can be illustrated using the other 4
views
End users Programmers
Use Cases
Functionalities Software management
Use case
State -Transitions View Deployment • MusicApp Use Cases Example:
Activities • Browse for new songs
Process view Physical view
System Integraters System engineer • Buy song
Performance System Topology
Scalability Installation • Download the purchased song on the phone
Throughput Communication
• Play the song
41 42
 4+1 Architectural Views 4+1 Architectural Views
Logical View Process View
• Decompose the system structure into software components • Model the dynamic aspects of the architecture and the
and connectors behavior of its parts
• Map functionalities (use cases) onto the components • Describe how components/processes communicate
• MusicApp Process View Example:
• MusicApp Logical View:

43 Use Cases: Browse, Pay and Play For Songs 44

4+1 Architectural Views 4+1 Architectural Views

Development View Physical View
• Static organization of the software code artifacts • Physical/Virtual resources where the software will be
• Map elements in the logical view and the code artifacts deployed
• MusicApp Development View: • Map logical and physical entities
• MusicApp Physical View:

45 46
 Architecture Document Architectural Description
Template Languages (ADLs)
• Architectural goals • Hundreds of ADLs are used to describe software
• Significant requirements architectures
• Functional & Non functional • ACME (ACMEStudio), Darwin, Archimate, …
• Decisions and justifications • An ADL
• is a formal means of representing architectures
• Key abstractions (Domain model)
• provides solid support for formal verification and correction but it is
• Architectural descriptions considerably more difficult to use than UML
• Logical component model • is usually domain-specific language
• Process model
• Some ADLs can even support auto generation of software
• Physical components
• UML like languages are developed
• Development model
• sysML extension of UML for architectural descriptions
• Deployment model
47 49

Basic elements of a
Agenda
• Definition
Software Architecture
• Why software architecture • A software system’s architecture typically is not (and should not
be) a uniform monolith. It should be an interplay of:
• Architecting software • Processing
• Data, also referred as information or state
• What is a Software Architecture • Interaction
• Architecture X Function • Basic elements are:
• Components
• Views and Viewpoints on Architecture
• Connectors
• Basic Elements • Constraints
• Rationale
• Examples
• Architectural configuration, or topology: set of specific
• Architectural assets associations between the components and connectors in the
• References 50 architecture to accomplish the system’s objective 51
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Component (cont’d)
Component
Example
• A component is an architectural entity that
• encapsulates a subset of the system’s functionality and/or data
• restricts access to that subset via an explicitly defined interface
• has explicitly defined dependencies on its required execution
context

• Components typically provide application-specific services

• They are units of decomposition of a system

• Can be a software package, Web service or module

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

Component Component
Components vs Objects vs Modules Component Interface
• Components Provided Interfaces
• Provided Interfaces
• Encapsulate state and functionality • Specify and document the externallySpecify
visible
features features
(or public (orcomponent
API) offered by the public API)
and document the externally visible
•

• Coarse-grained offered by the component Data types and model

-

• Black box architecture elements • Data types and model Operations -

Properties -

• Structure of architecture • Operations Events and call-backs

-

• Objects/Classes • Properties
• Encapsulate state and functionality • Events and call-backs
Compatible Interfaces
• Fine-grained • Required Interfaces Required Interface
• Can “move” across components • Specify the conditions upon which a component can be (re)used
• Identifiable unit of instantiation • The platform is compatible
• Modules • The environment is setup correctly
• Rarely exist at run time Adapter Wrapper • Specify the conditions upon which a com
• May require other modules to compile can be (re)used
54 55
The platform is compatible
• Package the code
-

- The environment is setup correctly

 Connector
• Architectural building block that models: Ex:
• Interactions among components
• Rules that govern those interactions
Con
It provides interaction duct(s) and transfer of control/data nec
tor
• Many interaction types: Typ
• In many software systems they are simple interactions e.g. procedure
calls or shared data accesses es
• Much more complex and semantically rich interactions are possible! e.g.
client-server protocols, database access protocols, asynchronous event
multicast

• They typically provide application-independent interaction

facilities, not always directly visible in the code
56 57
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Connector Connector
Conceptual vs Implementation Why do we need them?
• In software architectures, connectors: • Separate computation from interaction
• Are first-class entities and have identity • Interaction abstraction and/or parameterization
• Describe all system interaction • Localization of interaction definition
• Entitled to their own specifications & abstractions • Specification of complex interactions
• Binary vs. N-ary
• Asymmetric vs. Symmetric
• In software system implementations, connectors: • Interaction protocols
• Frequently have no dedicated code, no identity • Minimize component interpendencies
• Typically do not correspond to compilation units • Extra-component system (interaction) information
• Are distributed across multiple modules and interaction mechanisms • Component independence
• Component interaction flexibility
• Support software evolution
• At component-, connector-, and system-level
• Facilitate heterogeneity, dynamism, distributions
58 59
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; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Constraints Agenda
• Definition
• Components must be constrained to ensure that: • Why software architecture
• the requirements are met
• the required functionality is achieved • Architecting software
• no functionality is duplicated
• What is a Software Architecture
• the required performance is achieved
• modularity is realized • Examples
• Architectural assets
• References

60 61

Example at small scale Example at small scale

• Unix command line • Unix command line

ls invoices | grep -e august | sort ls invoices | grep -e august | sort

• Application architecture can be understood based on very

few rules
• 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
63
62 63
 Example at large scale Example at large scale (cont’d)
WWW in a (Big) Nutshell 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” (URL) • Resources can be manipulated through their
representations.
• HTML is a very common representation language used on the Web.
• Each resource denotes, informally, some information.
• All communication between user agents and origin servers
• URL’s can be used to determine the identity of a machine on must be performed by a simple, generic protocol (HTTP),
the Internet, known as an origin server, where the value of which offers the command methods GET, POST, etc.
the resource may be ascertained.
• Communication between user agents and origin servers is
• Communication is initiated by clients, known as user agents, fully self-contained.
who make requests to servers. • (So-called “stateless interactions”)
• Web browsers are common instances of user agents.
64 65

Example at large scale (cont’d) Example at large scale (cont’d)

WWW’s Architecture WWW Architecture
• Architecture (of the Web) is wholly separate from the code
• There is no one piece of code that implements the
architecture. • This is the Web
• There are multiple pieces of code that implement each of
the various components of the architecture.
• E.g., different Web browsers
• 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.
66 67
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Example at large scale (cont’d) Example at large scale (cont’d)
WWW Architecture WWW Architecture
• This is the Web again: • This is also the Web

68 69
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; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Agenda Architectural Principles

Principles are general rules and guidelines, intended to be
• Definition enduring and seldom amended, that inform and support the way
• Why software architecture in which an organization sets about fulfilling its mission
• Simplicity • Modularity
• Architecting software
• Low coupling
• What is a Software Architecture • Separation of concerns
• Examples
• Abstraction • Postponing decisions
• Architectural assets • Encapsulation
• References • Information hiding
• Clear interface
• High cohesion
70 71
 Architectural sources Pattern
• Intuition • A pattern is a common solution to a common problem in a
given context
• The experience of the architect
• Pattern types:
• Method • Architectural Patterns (distribution, security, … patterns)
• Design Patterns
• An approach to derive the architecture from the
• Programming Patterns (idioms)
requirements • Requirement Patterns
• Theft • Testing Patterns
• Project Management Patterns
• Most elements of a software architecture are • Process Patterns
derived from a previous system of the same • Organizational Patterns
kind, another system with similar characteristics, • …
or an architecture found in technical literature • Anti-Patterns
72 73

Architectural Pattern
Architectural Patterns
Example: Layers
Architectural pattern – Layers
Named collection of architectural design decisions that are
applicable to a recurring design problem parameterized to
account for different software development contexts in which ISO OSI 7-Layer Model

that problem appears Layer 7 Application Provides application facilities

Layer 6 Presentation Structures information as required

Layered Component Layer 5 Session Manages the connection Personal Organizer

Layer 4 Transport Creates packets of data
<<layer>> Personal Organizer
Application-Specific (from Application-Specific)
Layer 3 Network Routes packets of data
Notification Composition Layer 2 Data Link Detects and corrects errors

Layer 1 Physical Transmits bits

• Architectural Patterns <<layer>>
Busi ness-Specifi c
Address Book
(from Business-Specific)
Calculator
(from Business-Specific)

• Express fundamental structural organizations, specify relationships

among (sub-)systems
vs. Design Patterns <<layer>> Filestore Memory Math

• Capture roles in solutions that occur repeatedly, define the

Base Management Management (from Base)
(from Base) (from Base)

relationships among roles 74 75

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Architectural Styles
Architectural Styles
vs Architectural Patterns
Named collection of architectural design decisions that (i) are
applicable in a given development context, (ii) constrain Architectural Styles
architectural design decisions that are specific to a particular • are strategies and dominant
system within that context, and (iii) elicit beneficial qualities in • Apply to a development context (e.g. highly distributed system, gui-
each resulting system intensive)
• Are general constraints, architecture with superior properties,
• A common vocabulary for the design elements • Must be refined and adapted,
• Improve communication by shared understanding

• A predefined configuration and composition rules

Patterns
• Known benefits and limitations • Are tactics
• Ensure quality attributes if constraints are followed • Apply to a design problem
• Specialization of components and connectors, together with a set of constraints • Express fine-grained constraints, specific to recurrent problems,
on how they can be used in concrete systems
• Can be used many times in several places,
76 • Can be combined 77
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Domain Specific
Reference Architecture
Software Architecture (DSSA)
• A DSSA is the combination of:
A reference architecture:
• Reference architecture for an application domain
• is an architecture • A library of components for that architecture containing reusable chinks of
representation of a particular domain expertise,
domain of interest. • A method of choosing and configuring components to work within an instance
• typically includes many of the reference architecture
different architectural • A DSSA is thus an assemblage of software components
• Specialized for a particular type of task (domain), generalized for effective use
patterns, applied in different
across that domain,
areas of its structure possibly • and composed in a standardized structure (topology) effective for building
partially or completely successful applications.
instantiated • Since DSSAs are specialized for a particular domain they are only of
value if one exists for the domain wherein the engineer is tasked with
building a new application.
Example reference architecture for the development of web applications
• DSSAs are the pre-eminent means for maximal reuse of knowledge and
from the Microsoft Application Architecture Guide (Key: UML) 78 prior development and hence for developing a new architectural design79
 Reference Model Application Framework

A reference model is an abstract representation of entities, An application framework represents the partial
their relationships and behavior, in a given domain of interest, implementation of a specific area of an application
and which typically forms the conceptual basis for the
development of more concrete elements • Most widely-known frameworks support user interfaces
• Java Server Pages
• ASP.NET
• Examples: a business model, an information model, or a
glossary of terms

80 81

Product Lines Product Line (Example)

• A set of related products that have substantial commonality • A consumer is interested in a 35-inch HDTV with a built-
in DVD player for the North American market.
• In general, the commonality exists at the architecture level
• Such a device might contain upwards of a million lines of
embedded software.
• One potential ‘silver bullet’ of software engineering
• Power through reuse of • This particular television/DVD player will be very similar:
• Engineering knowledge • to a 35-inch HDTV without the DVD player,
• Existing product architectures, styles, patterns • and also to a 35-inch HDTV with a built-in DVD player for the
• Pre-existing software components and connectors European market, where the TV must be able to handle PAL or
SECAM encoded broadcasts, rather than North America’s NTSC
format.

These closely related televisions will similarly each have a

million or more lines of code embedded within them.

82 83
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Architectural Styles, DSSAs,
Domains vs. Product Lines
Product Lines
Domains are in the problem space, product lines are in • Architectural Styles
the solution space • Can be general or domain-specific
• Provides general guidelines for diverse kinds of applications; focus
• Domain • Product Line on –ility development
• Consumer electronics • Sony WEGA TVs • Domain Spec. Soft. Architectures (DSSA)
• Avionics • Boeing 747 Family • Domain specific; includes elaborate domain model and specific
• Compilers • GNU compiler suite reference architecture
• Video games • Suite of games built on • Product lines
same engine • Explicit set of related products with common aspects

Style DSSA / Ref Arch Product Line

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

Architectural Mechanism Packaged application

Architectural mechanisms represent common concrete A packaged application is a Commercial-Off-The-Shelf (COTS)
solutions to frequently encountered problems. They may be product available in the market that can be bought "as is”
patterns of structure, patterns of behavior, or both. [RUP]
• These applications are usually large grained, that is they
• Often described as provide a significant amount of capability (and reuse)
• “the mechanism for achieving X”
• “this element is underpinned by mechanism Y”
• Examples
• Customer Relationship Management (CRM) application (e.g. Siebel)
• Examples • Enterprise Resource Planning (ERP) application (e.g. SAP)
• Persistency mechanism
• Error logging mechanism
• Communication mechanism
• The amount of required custom development is minimal
• Shopping cart
86 • Primary focus is on configuring the application 87
 Legacy Application Agenda
• Definition
A legacy application is a system that continues to be used • Why software architecture
because the owning organization cannot replace or redesign it
• Architecting software
• Usually no way to have past (regression) tests • What is a Software Architecture
• Examples
• Tends to be a focus on integration rather than new
development • Architectural assets
• References
• Often results in a focus on enterprise application integration
(EAI)
88 89

References
Books
• Architecture Styles
• Institutions
• http://www.iso-architecture.org/ieee-1471/ (Systems and software engineering —
• Buschmann et al.: Pattern-Oriented Software Architecture, Vol. 1, 2, 4
Architecture description ISO/IEC/IEEE 42010) • Fowler: Patterns of Enterprise Application Architecture
• https://iasaglobal.org/ (International Association of Software Architects) • http://www.aosabook.org/ (Book on Architectures of Open Source Systems)
• https://www.sei.cmu.edu/architecture (Software Engineering Institute / • http://www.softwarearchitecturebook.com/ (Slides from the book “Software
Architecture) Architecture: Foundations, Theory and Practice” by: Richard N. Taylor,
• http://www.softwarearchitectureportal.org/ (The Software Architecture Portal) Nenad Medvidovic, and Eric M. Dashofy Publisher: Wiley ISBN-10:
• http://www.bredemeyer.com/papers.htm (Software Architecture Resources) 0470167742)
• People • https://www.viewpoints-and-perspectives.info/ (Software Systems
• http://handbookofsoftwarearchitecture.com/ (Software Architecture Grady Booch) Architecture, Rozanski, Woods)
• https://www.martinfowler.com/bliki/ (Martin Fowler’s blog and wiki) • https://docs.microsoft.com/en-us/previous-versions/msp-n-
• http://stal.blogspot.com/ (Michael Stal Blog) p/ee658093(v=pandp.10) (Software Architecture and Design Microsoft)
• http://www.ivencia.com/index.html?/softwarearchitect/ (ivencia) • http://www.ece.ubc.ca/~matei/EECE417/BASS/ (Software Architecture in
• http://softwarearchitecturezen.blogspot.com/ (Peter Crips Blog) Practice)
• Software Architecture in Practice, Second Edition, Len Bass, Paul Clements,
90 Rick Kazman, Addison Wesley, 2003 91
 Videos / Podcasts Tools
• Archimate (Standard Notation for Enterprise Architecture)
• Eclipse (IDE): http://www.eclipse.org/
• George Fairbanks: Introduction to Software Architecture 2012
(Video: https://www.youtube.com/watch?v=x30DcBfCJRI) • Enterprise architect (IDE):
• http://codingblocks.net/ http://www.sparxsystems.com/products/ea/index.html
• http://www.se-radio.net/tag/architecture • Modelio (IDE for software modeling in UML and Archimate):
• https://softwareengineeringdaily.com/ https://www.modelio.org/
• https://player.oreilly.com/videos/9781491901137 • Archi (Archimate Modeling Tool)
• https://player.oreilly.com/videos/9781491901137 (Software Architecture
Fundamentals Understanding the basics) https://www.archimatetool.com/
• https://www.ibm.com/developerworks/rational/library/feb06/eeles • AcmeStudio (IDE for modeling Software Architecture)
http://www.cs.cmu.edu/~acme/

92 93