lecture7.ppt

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Modeling
Software Architecture
Lecture 7

Software Architecture: Foundations, Theory, and Practice
Objectives
 Concepts
 What is modeling?
 How do we choose what to model?
 What kinds of things do we model?
 How can we characterize models?
 How can we break up and organize models?
 How can we evaluate models and modeling notations?
 Examples
 Concrete examples of many notations used to model software
architectures
 Revisiting Lunar Lander as expressed in different modeling
notations
2

What is Architectural Modeling?
 Recall that we have characterized architecture as the set of
principal design decisions made about a system
 We can define models and modeling in those terms
 An architectural model is an artifact that captures some or
all of the design decisions that comprise a system’s
architecture
 Architectural modeling is the reification and
documentation of those design decisions
 How we model is strongly influenced by the notations we
choose:
 An architectural modeling notation is a language or
means of capturing design decisions.
3

How do We Choose What to
Model?
 Architects and other stakeholders must make critical
decisions:
1. What architectural decisions and concepts should be
modeled,
2. At what level of detail, and
3. With how much rigor or formality
– These are cost/benefit decisions
 The benefits of creating and maintaining an
architectural model must exceed the cost of doing
so
4

Stakeholder-Driven Modeling
 Stakeholders identify
aspects of the system
they are concerned
about
 Stakeholders decide the
relative importance of
these concerns
 Modeling depth should
roughly mirror the
relative importance of
concerns
5
From Maier and Rechtin, “The Art of Systems Architecting” (2000)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

What do We Model?
 Basic architectural elements
 Components
 Connectors
 Interfaces
 Configurations
 Rationale – reasoning behind decisions
6

What do We Model? (cont’d)
 Elements of the architectural style
 Inclusion of specific basic elements (e.g.,
components, connectors, interfaces)
 Component, connector, and interface types
 Constraints on interactions
 Behavioral constraints
 Concurrency constraints
 …
7

 Static and Dynamic Aspects
 Static aspects of a system do not change as a
system runs
 e.g., topologies, assignment of
components/connectors to hosts, …
 Dynamic aspects do change as a system runs
 e.g., state of individual components or
connectors, state of a data flow through a
system, …
8

 Functional and non-functional aspects of a system
 Functional
 “The system prints medical records”
 Non-functional
 “The system prints medical records quickly and
confidentially.”
 Architectural models tend to be functional
 It is often important to capture non-functional
decisions
 Even if they cannot be automatically or
deterministically interpreted or analyzed
9

Important Characteristics of
Models
 Ambiguity
 A model is ambiguous if it is open to more than one
interpretation
 Accuracy and Precision
 Different, but often conflated concepts
 A model is accurate if it is correct, conforms to
fact, or deviates from correctness within
acceptable limits
 A model is precise if it is sharply exact or
delimited
10

Accuracy vs. Precision
11
Inaccurate and
imprecise:
incoherent or
contradictory
assertions
Accurate but
imprecise:
ambiguous or
shallow
assertions
Inaccurate but
precise:
detailed
assertions that
are wrong
Accurate and
precise:
detailed
assertions that
are correct

Views and Viewpoints
 Generally, it is not feasible to capture everything we
want to model in a single model or document
 The model would be too big, complex, and confusing
 So, we create several coordinated models, each
capturing a subset of the design decisions
 Generally, the subset is organized around a particular
concern or other selection criteria
 We call the subset-model a ‘view’ and the concern (or
criteria) a ‘viewpoint’
12

Views and Viewpoints Example
13
Deployment view of a 3-tier
application
Deployment view of a
Lunar Lander system
Both instances of the
deployment viewpoint

Commonly-Used Viewpoints
 Logical Viewpoints
 Capture the logical (often software) entities in a
system and how they are interconnected.
 Physical Viewpoints
 Capture the physical (often hardware) entities in a
system and how they are interconnected.
 Deployment Viewpoints
 Capture how logical entities are mapped onto physical
entities.
14

Commonly-Used Viewpoints
(cont’d)
 Concurrency Viewpoints
 Capture how concurrency and threading will be
managed in a system.
 Behavioral Viewpoints
 Capture the expected behavior of (parts of) a
system.
15

Consistency Among Views
 Views can contain overlapping and related design
decisions
 There is the possibility that the views can thus
become inconsistent with one another
 Views are consistent if the design decisions they contain
are compatible
 Views are inconsistent if two views assert design
decisions that cannot simultaneously be true
 Inconsistency is usually but not always indicative of
problems
 Temporary inconsistencies are a natural part of
exploratory design
 Inconsistencies cannot always be fixed 16

Example of View Inconsistency
17

Common Types of Inconsistencies
 Direct inconsistencies
 E.g., “The system runs on two hosts” and “the
system runs on three hosts.”
 Refinement inconsistencies
 High-level and low-level views of the same parts of a
system conflict
 Static vs. dynamic aspect inconsistencies
 Dynamic aspects (e.g., behavioral specifications)
conflict with static aspects (e.g., topologies)
18

Surveying Modeling Approaches
 Generic approaches
 Natural language
 PowerPoint-style modeling
 UML, the Unified Modeling Language
 Early architecture description languages
 Darwin
 Rapide
 Wright
 Domain- and style-specific languages
 Koala
 Weaves
 AADL
 Extensible architecture description languages
 Acme
 ADML
 xADL
20

Natural Language
 Spoken/written languages such as English
 Advantages
 Highly expressive
 Accessible to all stakeholders
 Good for capturing non-rigorous or informal architectural
elements like rationale and non-functional requirements
 Plentiful tools available (word processors and other text editors)
 Disadvantages
 Ambiguous, non-rigorous, non-formal
 Often verbose
 Cannot be effectively processed or analyzed by
machines/software
21

22
Natural Language Example
“The Lunar Lander application consists of three components: a data store
component, a calculation component, and a user interface component.
The job of the data store component is to store and allow other components
access to the height, velocity, and fuel of the lander, as well as the current
simulator time.
The job of the calculation component is to, upon receipt of a burn-rate
quantity, retrieve current values of height, velocity, and fuel from the data
store component, update them with respect to the input burn-rate, and store
the new values back. It also retrieves, increments, and stores back the
simulator time. It is also responsible for notifying the calling component of
whether the simulator has terminated, and with what state (landed safely,
crashed, and so on).
The job of the user interface component is to display the current status of
the lander using information from both the calculation and the data store
components. While the simulator is running, it retrieves the new burn-rate
value from the user, and invokes the calculation component.”

Related Alternatives
 Ambiguity can be reduced and rigor can be increased
through the use of techniques like ‘statement
templates,’ e.g.:
 The (name) interface on (name) component takes (list-of-
elements) as input and produces (list-of-elements) as output
(synchronously | asynchronously).
 This can help to make rigorous data easier to read and interpret,
but such information is generally better represented in a more
compact format
23

Informal Graphical Modeling
 General diagrams produced in tools like PowerPoint and
OmniGraffle
 Advantages
 Can be aesthetically pleasing
 Size limitations (e.g., one slide, one page) generally constrain
complexity of diagrams
 Extremely flexible due to large symbolic vocabulary
 Disadvantages
 Ambiguous, non-rigorous, non-formal
 But often treated otherwise
 Cannot be effectively processed or analyzed by
machines/software
24

Informal Graphical Model Example
25

UML – the Unified Modeling
Language
 13 loosely-interconnected notations called diagrams that
capture static and dynamic aspects of software-intensive
systems
 Advantages
 Support for a diverse array of viewpoints focused on many
common software engineering concerns
 Ubiquity improves comprehensibility
 Extensive documentation and tool support from many
vendors
 Disadvantages
 Needs customization through profiles to reduce ambiguity
 Difficult to assess consistency among views
 Difficult to capture foreign concepts or views
27

UML Example
28

Early Architecture Description
Languages
 Early ADLs proliferated in the 1990s and explored ways
to model different aspects of software architecture
 Many emerged from academia
 Focus on structure: components, connectors,
interfaces, configurations
 Focus on formal analysis
 None used actively in practice today, tool support has
waned
 Ideas influenced many later systems, though
29

Darwin
 General purpose language with graphical and textual
visualizations focused on structural modeling of systems
 Advantages
 Simple, straightforward mechanism for modeling structural
dependencies
 Interesting way to specify repeated elements through
programmatic constructs
 Can be modeled in pi-calculus for formal analysis
 Can specify hierarchical (i.e., composite) structures
 Disadvantages
 Limited usefulness beyond simple structural modeling
 No notion of explicit connectors
 Although components can act as connectors
30

Darwin Example
31
component DataStore{
provide landerValues;
}
component Calculation{
require landerValues;
provide calculationService;
}
component UserInterface{
require calculationService;
require landerValues;
}
component LunarLander{
inst
U: UserInterface;
C: Calculation;
D: DataStore;
bind
C.landerValues -- D.landerValues;
U.landerValues -- D.landerValues;
U.calculationService -- C.calculationService;
}
Canonical Textual Visualization Graphical Visualization

Programmatic Darwin Constructs
32
component WebServer{
provide httpService;
}
component WebClient{
require httpService;
}
component WebApplication(int numClients){
inst S: WebServer;
array C[numClients]: WebClient;
forall k:0..numClients-1{
inst C[k] @ k;
bind C[k].httpService -- S.httpService;
}
}

Koala
 Darwin-inspired notation for specifying product lines of
embedded consumer-electronics devices
 Advantages
 Advanced product-line features let you specify many
systems in a single model
 Direct mapping to implemented systems promotes
design and code reuse
 Disadvantages
 Limited to structural specification with additional
focus on interfaces
34

Koala Example
35
Single system Product line of two systems
interface IDataStore{
void setAltitude(int altitudeInMeters);
int getAltitude();
void setBurnRate(int newBurnRate);
int getBurnRate();
...
}

AADL: The Architecture Analysis
& Design Language
 Notation and tool-set for modeling hardware/software systems,
particularly embedded and real-time systems
 Advantages
 Allows detailed specification of both hardware and software
aspects of a system
 Automated analysis tools check interesting end-to-end properties
of system
 Disadvantages
 Verbose; large amount of detail required to capture even simple
systems
 Emerging tool support and UML profile support
36

AADL (Partial) Example
37
data lander_state_data
end lander_state_data;
bus lan_bus_type
end lan_bus_type;
bus implementation lan_bus_type.ethernet
properties
Transmission_Time => 1 ms .. 5 ms;
Allowed_Message_Size => 1 b .. 1 kb;
end lan_bus_type.ethernet;
system calculation_type
features
network : requires bus access
lan_bus.calculation_to_datastore;
request_get : out event port;
response_get : in event data port lander_state_data;
request_store : out event port lander_state_data;
response_store : in event port;
end calculation_type;
system implementation calculation_type.calculation
subcomponents
the_calculation_processor :
processor calculation_processor_type;
the_calculation_process : process
calculation_process_type.one_thread;

38
bus lan_bus_type
end lan_bus_type;
properties
features
subcomponents
connections
bus access network -> the_calculation_processor.network;
event data port response_get ->
the_calculation_process.response_get;
event port the_calculation_process.request_get ->
request_get;
event data port response_store ->
the_calculation_process.response_store;
properties
Actual_Processor_Binding => reference
the_calculation_processor applies to
the_calculation_process;
end calculation_type.calculation;
processor calculation_processor_type
features
end calculation_processor_type;
process calculation_process_type
features
request_store : out event data port lander_state_data;
end calculation_process_type;

39
bus lan_bus_type
end lan_bus_type;
properties
features
subcomponents
connections
bus access network -> the_calculation_processor.network;
the_calculation_process.response_get;
event port the_calculation_process.request_get ->
request_get;
event data port response_store ->
the_calculation_process.response_store;
properties
Actual_Processor_Binding => reference
the_calculation_processor applies to
the_calculation_process;
end calculation_type.calculation;
processor calculation_processor_type
features
end calculation_processor_type;
process calculation_process_type
features
end calculation_process_type;
thread calculation_thread_type
features
properties
Dispatch_Protocol => periodic;
end calculation_thread_type;
process implementation calculation_process_type.one_thread
subcomponents
calculation_thread : thread client_thread_type;
connections
calculation_thread.response_get;
event port calculation_thread.request_get -> request_get;
event port response_store ->
calculation_thread.response_store;
event data port request_store -> request_store;
properties
Dispatch_Protocol => Periodic;
Period => 20 ms;
end calculation_process_type.one_thread;

AADL Example Explained a Bit
 Note the level of detail at which the system is specified
 A component (calculation_type.calculation) runs on…
 a physical processor (the_calculation_processor), which
runs…
 a process (calculation_process_type.one_thread), which in
turn contains…
 a single thread of control (calculation_thread), all of which
can make two kinds of request-response calls through…
 ports (request_get/response_get,
request_store/response_store) over…
 an Ethernet bus (lan_bus_type.Ethernet).
 All connected through composition, port-mapping, and so on
 This detail is what gives AADL its power and analyzability
40

xADL
 Modular XML-based ADL intended to maximize
extensibility both in notation and tools
 Advantages
 Growing set of generically useful modules
available already
 Tool support in ArchStudio environment
 Users can add their own modules via well-defined
extensibility mechanisms
 Disadvantages
 Extensibility mechanisms can be complex and
increase learning curve
 Heavy reliance on tools
41

xADL Example
42
<types:component xsi:type="types:Component"
types:id="myComp">
<types:description xsi:type="instance:Description">
MyComponent
</types:description>
<types:interface xsi:type="types:Interface"
types:id="iface1">
Interface1
<types:direction xsi:type="instance:Direction">
inout
</types:direction>
</types:interface>
</types:component>

xADL Example
43
types:id="myComp">
MyComponent
types:id="iface1">
Interface1
inout
</types:direction>
</types:interface>
</types:component>
component{
id = "myComp";
description = "MyComponent";
interface{
id = "iface1";
description = "Interface1";
direction = "inout";
}
}

xADL Example
44
types:id="myComp">
MyComponent
types:id="iface1">
Interface1
inout
</types:direction>
</types:interface>
</types:component>
component{
id = "myComp";
description = "MyComponent";
interface{
id = "iface1";
description = "Interface1";
direction = "inout";
}
}

xADL Tools
45
xADL 2.0
Schemas
DOM Implementation
(e.g., Crimson, Xerces)
Manipulates XML documents
as data structure of elements
and attributes
DOM Implementation
(e.g., Crimson, Xerces)
Manipulates XML documents
as data structure of elements
and attributes
XSV
Off-the-shelf XML
schema validator
XSV
Off-the-shelf XML
schema validator
XML Spy
Off-the-shelf XML
development
environment
XML Spy
Off-the-shelf XML
development
environment
Data Binding Library
Provides object-oriented
interface to xADL
documents
Data Binding Library
Provides object-oriented
interface to xADL
documents
ArchEdit
Tree-based syntax-
directed editor
for xADL documents
ArchEdit
Tree-based syntax-
directed editor
for xADL documents
xArchADT
Façade interface
for data binding
library
xArchADT
Façade interface
for data binding
library
Apigen
XML schema to
Java data
binding generator
Apigen
XML schema to
Java data
binding generator
(Other Tools)
Tools that implement
xADL semantics
(Other Tools)
Tools that implement
xADL semantics
parses/edits
uses
uses
parses
generates
validates
edits
wraps
uses
use

ArchStudio Environment
46

xADL Schemas (Modules)
47
Schema Features
Structure &
Types
Defines basic structural modeling of prescriptive
architectures: components, connectors, interfaces,
links, general groups, as well as types for components,
connectors, and interfaces.
Instances
Basic structural modeling of descriptive architectures:
components, connectors, interfaces, links, general
groups.
Abstract
Implementation
Mappings from structural element types (component
types, connector types) to implementations.
Java
Implementation
Mappings from structural element types to Java
implementations.
Options
Allows structural elements to be declared optional—
included or excluded from an architecture depending
on specified conditions.
Variants
Allows structural element types to be declared
variant—taking on different concrete types depending
on specified conditions.
Versions
Defines version graphs; allows structural element types
to be versioned through association with versions in
version graphs.

Caveat 1
 The preceding overview optimized for breadth rather
than depth
 Semantics and capabilities of many of these notations
quite deep and subtle
 Some even have entire books written about them
 You are encouraged to investigate individual
notations more deeply
48

Caveat 2
 Some systems are difficult to model in traditional
ways
 ‘Agile’ systems that are not explicitly designed
above the level of code modules
 Extremely large, complex, or dynamic systems
(e.g., the Web)
 Can model limited or less complex aspects
 Can model one instance of the system (e.g.,
one Web application)
 Exploit regularity
 Model the style
 Model the protocols 49

lecture7.ppt

Recommended

More Related Content

Similar to lecture7.ppt (20)

Recently uploaded (20)

lecture7.ppt