‫بسم هللا الرحمن الرحيم‬
‫ والصالة والسالم على رسول هللا‬، ‫الحمد هلل‬
Introduction to Software Architectures
Hany H. Ammar, Professor,
LANE Department of Computer Science and Electrical Engineering
West Virginia University, Morgantown, West Virginia, USA, and
Faculty of Computers and Information, Cairo University, Cairo, Egypt
Software Architectures Course Overview
1
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Line Architectures
Software Architecture Evaluation
Software Architectures Course Overview
2
Introduction to Software Architectures
Software Architectures Course Overview
3
Why Software Architecture ?
 Software architecture is a major determinant of software
quality (performance, deployment, maintenance and
product evolution)
“Software architecture is not only concerned
with structure and behavior, but also with usage,
functionality, performance, resilience, reuse,
comprehensibility, economic and technology
constraints and tradeoffs” - The Rational Unified
Process, 2002
Software Architectures Course Overview
4
Why Software Architecture ?
 The Carnegie Mellon Software Engineering Institute
(SEI) developed the Architectural Tradeoff
Analysis Method (ATAM) for qualitative evaluation
of architectures by expert evaluators and validated
its usefulness in practice.
 This process not only permits evaluation of specific
architecture quality attributes (e.g., modifiability,
performance, security, and reliability) but also allows
engineering tradeoffs to be made among possibly
conflicting quality goals.
Software Architectures Course Overview
5
Software Architecture Views
Architecture views provide the basis for reasoning about the
appropriateness and
quality of the architecture for achieving system
quality goals.

Some common architectural views include
 the logical view, which represents system functions; key system
abstractions and their dependencies; and data flows
 the module decomposition view, which represents the hierarchical
decomposition of the system's functionality into units of
implementation. This decomposition can include objects,
procedures, functions, and their relationships.
 the communicating-processes view, which represents processing
threads, their synchronization, and the data flows between them
 the deployment view, which shows how the software is allocated to
hardware including processors, storage, and external devices or
sensors, along with the communications paths that connect them
Software Architectures Course Overview
6
More on Views
 Views serve as the primary vehicle for communicating
the architecture to its stakeholders, the primary
engineering handle for designing quality attributes
into the system, and the primary window into the
architecture for evaluators who are checking it for
fitness of purpose.
Software Architectures Course Overview
7
What is software architecture
ANSI/IEEE Std 1471-2000, Recommended Practice for
Architectural Description of Software-Intensive
Systems
Architecture is defined by the recommended
practice as the fundamental organization of a
system, embodied in its components, their
relationships to each other and the environment,
and the principles governing its design and
evolution
Software Architectures Course Overview
8
What is software architecture
A simplified Definition
A software architecture is defined by a
configuration of architectural elements-components, connectors, and data-constrained in their relationships in order to
achieve a desired set of architectural
properties.
Software Architectures Course Overview
9
Software Architecture Elements
• A component is an abstract unit of software
instructions and internal state that provides a
transformation of data via its interface
• A connector is an abstract mechanism that
mediates communication, coordination, or
cooperation among components.
Software Architectures Course Overview
10
Software Architecture Elements
• A datum is an element of information that is transferred from a
component, or received by a component, via a connector.
• A configuration is the structure of architectural relationships among
components, connectors, and data during a period of system run-time.
• An architectural style is a coordinated set of architectural constraints
that restricts the roles/features of architectural elements and the
allowed relationships among those elements within any architecture
that conforms to that style.
• Detailed example: http://sunset.usc.edu/SSCS/toc.html
Standard Satellite Control Segment
Reference Architecture
Software Architectures Course Overview
11
Example of an Architecture
Development Process
Software Architectures Course Overview
12
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Lines
Software Architecture Evaluation
Software Architectures Course Overview
13
Software Architectures Standards
http://www.sei.cmu.edu/architecture/IEEE_1471.html
• IEEE-Std-1471-2000 Recommended Practice for
Architectural Description of Software-Intensive Systems
• One hallmark of the maturity of a discipline is the
development of standards codifying concepts, terms
and practices that have become understood and widely
applied within that discipline.
• In 2001, ANSI adopted it as an American standard.
Most recently, ISO recently adopted IEEE 1471:2000
as ISO/IEC 42010:2007, Systems and Software
Engineering—Architectural Description.
Software Architectures Course Overview
14
IEEE 1471 Goals and
Objectives
• Define direction for incorporating architectural thinking into
IEEE standards
• ¨ Take a “wide scope” interpretation of architecture as
applicable to software-intensive systems
• ¨ Establish a conceptual framework and vocabulary for
describing architectural issues of systems.
• ¨ Identify and promulgate sound architectural practices
• ¨ Allow for the evolution of those practices as relevant
technologies mature
Software Architectures Course Overview
15
Software Architectures Course Overview
16
Software Architectures Course Overview
17
IEEE 1471 Conceptual Framework
• An architectural description (or AD) is organized into a set of
architectural views.
• Each view addresses one or more architectural concerns held by the
system stakeholders interested in that architecture.
• An architectural concern is any area of interest in the system's
construction, deployment, use or other factors which could affect its
architecture.
• An AD is incomplete when there are identified architectural concerns
which are not addressed in at least one view.
• An architectural view is a set of architectural models. The notations,
techniques and rules for constructing and interpreting those models
must be documented to enable architects to create – and stakeholders
to understand – a conforming architectural view.
• The notations, techniques and rules are described in an architectural
viewpoint.
Software Architectures Course Overview
18
Software Architectures Course Overview
19
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Lines
Software Architecture Evaluation
Software Architectures Course Overview
20
A Simple Example of Software
Architecture Using UML2
• EXAMPLE: SATELLITE CONTROL SYSTEM
Use-Case Diagram
Software Architectures Course Overview
21
A Simple Example of Software
Architecture Using UML2
• SATELLITE CONTROL SYSTEM Architecture composition
Software Architectures Course Overview
22
A Simple Example of Software
Architecture Using UML2
• SATELLITE CONTROL SYSTEM Architecture structure
Software Architectures Course Overview
23
A Simple Example of Software
Architecture Using UML2
• SATELLITE CONTROL SYSTEM Architectural behavior
Software Architectures Course Overview
24
.
Architectural Description languages
Authors
Instution/project
Summary
Reference
David Garlan,
Bob Monroe,
and Drew
Kompanek
Dave Wile
(USC)
CMU, 1995-
Generic ADL to
support
Interchange
http://www.cs.cmu.edu/~acme/
CMU, Able group
Customization of
architectural styles
through
environment
generation
http://www.cs.cmu.edu/afs/cs/project/
able/www/aesop/aesop_home.html
CMU, Able group
Protocol Analysis
http://www.cs.cmu.edu/~able/wright/
Stanford Univ
Event patterns,
architectural
simulation
http://www.cs.stanford.edu/cs/Resear
ch/index.html
Further links are not working
North Eastern
University, Center for
Software Sciences
Aspect-oriented
and adaptive
programming
http://www.ccs.neu.edu/research/dem
eter/
ADL
ACME
Aesop
Wright
Robert J. Allen
Rapide
Demeter
Karl Lieberherr
Software Architectures Course Overview
25
Architectural Description Languages
Unicon
CMU, Compose
Group
Architectural
Compilation
http://www.cs.cmu.edu/afs/cs/project
/vit/www/unicon/
CHAM
G. Berry and
G.
Boudol
?
Rewrite rule
semantics
[Berry1992]
SADL:
Mark Moriconi
and
Xiaolei
Qian
SRI International
Refinement
patterns
http://www.sdl.sri.com/programs/dsa
/sadl
C2
Richard N.
Taylor
Professor
David F.
Redmiles
University of
California, Irvine
C2 architectural
style, GUI
apps
http://www.ics.uci.edu/pub/arch/ADL/
SADL.html
Darwin
Ioannis
Georgiadi
s (?)
Department of
Computing,
Imperial College of
Science,
Technology &
Medicine,
Distributed System
Exo-Structure,
Dynamism
http://www.doc.ic.ac.uk/~igeozg/Proj
ect/Darwin/
Software Architectures Course Overview
26
Architectural Description Languages
Meta-H
Honeywell
real-time, faulttolerant
avionics
?
Naval Postgraduate
School
computer-aided
prototyping
http://wwwcaps.cs.nps.navy.mil/
Modechart
Univ. of Texas at
Austin
RT architectures
http://www.cs.utexas.edu/users/cpg/R
TS/
Resolve
Ohio State University
specifications of
reusable
software
http://www.cis.ohio-state.edu/rsrg/
PSDL/CAPS
Luqi
Software Architectures Course Overview
27
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Lines
Software Architecture Evaluation
Software Architectures Course Overview
28
Architecture Development
Software Architectures Course Overview
29
The outline of the architecting method
framework
submethods
Quality Attributes
explore
specific details
Software Architectures Course Overview
30
Iterative Architecting Process
Software Architectures Course Overview
31
Designing Architectures: Attribute-Driven Design (ADD)
http://www.sei.cmu.edu/architecture/add_method.html
http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr023.pdf
• A method of designing an architecture to achieve quality and
functional needs
 In ADD, architecture design is developed by taking sets of quality
attribute scenario inputs and using knowledge of relationship between
quality attribute access and architecture.
• Develops a software architecture based on process
decomposition, stepwise refinement and fulfillment of
attribute qualities.
• It is a recursive process where at each repetition, tactics and
an architecture style or pattern is chosen to fulfill quality
attribute needs.
Software Architectures Course Overview
32
ADD Steps
These steps form an iterative stepwise refinement process
1.
2.
Choose a component to decompose
Refine the component based on these steps:
a. Choose architecture driver
b. Choose architecture style or pattern
c. Instantiate component and place functions using
different views
d. Create interface on sub-components
e. Identify and enhance use case and quality
scenario to be used as constraint for subcomponents
3. Repeat all the steps above for each component that
needs to be decomposed.
Software Architectures Course Overview
33
Architectural Styles
• An architectural style is a class of architectures characterized
by:
– Components types: are component classes characterized by
either SW packaging properties or functional or computational
roles within an application.
– Communication patterns between the components: the
communication protocols between the component types.
– Semantic constraints, indicating the behavioral properties of the
components individually, and in the context of their interactions.
– A set of connectors, SW artifacts that enable us to implement
the communication between the components in a way that
satisfies the semantic constraints.
Software Architectures Course Overview
34
Architectural styles grouped into
families
1.
Independent Components. SW system is viewed a set of
independent processes or objects or components that
communicate through messages. Two subfamilies:
• Event based systems (implicit and direct invocation
style) and
• Communicating processes family (client-server style).
Software Architectures Course Overview
35
Architectural Styles: Event-Based Architectures
Software Architectures Course Overview
36
Architectural Styles: Virtual Machines
2. Virtual Machines. User programs are treated as data by a
virtual machine, which is an abstract machine
implemented entirely in software, that runs on top of
the actual hardware machine.ex rule-based style.
Software Architectures Course Overview
37
Architectural Styles: Data Flow
3. Data Flow. Include batch sequential systems and pipes
and filters. BSS, different components take turns at
processing a batch of data, each saving the result of
their processing in a shared repository that the next
component can access. PF, we have stream of data
through a more or less complex structure of process
(filters). Ex, UNIX.
Software Architectures Course Overview
38
Architectural Styles: Data Centered
4. Data-Centered Systems. Consist of having different
components communicate through shared data
repositories. When data repository is an active repository
that notifies registered components of changes in it thenblackboard style.
Software Architectures Course Overview
39
SW Systems-Mix of Architecture Styles
• Most SW systems use a mix of architecture styles. Ex,
personnel management system with a scheduling
component, implemented using the independent
component style, and a payroll component, using the
batch sequential style.
• Choosing a style to implement a particular system
depends on several factors. The technical factors
concern the level of quality attributes that each style
enables us to attain.
– Event-based systems-achieve very high level of evolvability,
at the expense of performance and complexity.
– Virtual-machine style-achieve very high level of portability, at
expense of performance and perhaps even testability.
Software Architectures Course Overview
40
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Lines
Software Architecture Evaluation
Software Architectures Course Overview
41
What is software Product
Line?
 Re-use of asset architecture for some systems can maximize
company investment.
 Mature organization keeps their architecture as an intellectual
asset which is very valuable and able to increase turn over and
reduce cost.
 Software Product Line – discipline, and re-use strategy sharing
of asset in producing a group of products.
 Objective – able to re-use asset from the previous projects such
as basic architecture, the same element, designs,
documentations, user manual, artifact project management
such as budgeting and scheduling, and test plan & test cases.
 When the product line produced, the assets will be kept in asset
library to be used for other projects.
Software Architectures Course Overview
42
What is Software Product Line?
 Software product line is defined as “A set of
software-intensive systems sharing a common
managed set of features that satisfy the specific
needs of a particular market segment or mission”
 These Systems are developed from a common core
of assets (e.g. a common architecture) in a
prescribed way.
Software Architectures Course Overview
43
Product Line Architecture
 Software architecture is the most important asset in a
product line.
 There are three important things that need to be
acknowledging by the architecture in product line:
– Identifying variation point.
– Supporting variation point.
– Evaluate the suitable architecture for the product line.
Software Architectures Course Overview
44
Supporting Variation Point
 Architecture will support variation point the form of:
–
Using or eliminating elements.
–
Using the same elements with variant attributes.
–
Choosing the element which has same interface but different implementation or different
quality attribute.
 Techniques:
–
In OO system, the use of specialization and generalization for class.
–
Developing extension points at the element.
–
Using the same parameter with in the component.
–
Over loading – using the same function in different type of data.
Software Architectures Course Overview
45
Example 1: PLA for a Microwave Oven
Software Architectures Course Overview
46
Definition of Terms Used in the Example Class
Diagram
• Kernel: Kernel in product lines represents the mandatory features
for the product line members. i.e.: they cannot be omitted in
products. The stereotype <<kernel>> is used to specify Kernel in
UML class diagrams.
• Optional: Optionality in product lines means that some features
are elective for the product line members, which means they can
be omitted in some products and included in others. The
stereotype <<optional>> is used to specify optionality in UML
class diagrams. The optionality can concern classes, packages,
attributes or operations.
• Variant: Variant classes are modeled using UML inheritance and
stereotypes. Each variation point will be defined by an abstract
class and a set of subclasses. The abstract class will be defined
with the stereotype <<variant>> and each subclass will be
stereotyped <<variant>>, or <<optional>>, the default value being
variant.
Software Architectures Course Overview
47
Example 1(cont.): Microwave
Sample Sequence Diagram
Software Architectures Course Overview
48
OUTLINE
•
•
•
•
•
•
Introduction to Software Architectures
Software Architectures Standards
Modeling and Documenting Software Architectures
Software Architecture Design and Analysis
Software Product Lines
Software Architecture Evaluation
Software Architectures Course Overview
49
Software Architecture Evaluation
The Architecture Tradeoff Analysis Method (ATAM)
The following diagram displays a conceptual flow of the ATAM.
http://www.sei.cmu.edu/architecture/ata_method.html
Software Architectures Course Overview
50
The Architecture Tradeoff
Analysis Method (ATAM)
• Business drivers and the software
architecture are elicited from project
decision makers.
• These are refined into scenarios and the
architectural decisions made in support of
each one
• Analysis of scenarios and decisions
results in identification of risks, non-risks,
sensitivity points, and tradeoff points in
the architecture.
Software Architectures Course Overview
51
The Architecture Tradeoff
Analysis Method (ATAM)
• Risks are synthesized into a set of risk
themes, showing how each one threatens
a business driver.
• The most important results are improved
architectures
• The output of an ATAM is an out-brief
presentation and/or a written report that
includes the major findings of the
evaluation
Software Architectures Course Overview
52
The Architecture Tradeoff
Analysis Method (ATAM)
• These are typically:
– the architectural styles identified
– a "utility tree" — a hierarchic model of the driving
architectural requirements
– the set of scenarios generated and the subset
that were mapped onto the architecture
– a set of quality-attribute-specific questions that
were applied to the architecture and the
responses to these questions
– a set of identified risks
– a set of identified non-risks
Software Architectures Course Overview
53
Conclusions
• Architecture is defined by the recommended practice as the
fundamental organization of a system, embodied in its components,
their relationships to each other and the environment, and the
principles governing its design and evolution
• IEEE 1471: One hallmark of the maturity of a discipline is the
development of standards codifying concepts, terms and practices that
have become understood and widely applied within that discipline.
• There are several methods and notations for Modeling and
Documenting Software Architectures
• We need to study existing methods for Software Architecture Design
and Analysis
• We need to study methods of Software Architecture Evaluation
Software Architectures Course Overview
54