Transcript Reflections on Software Architecture Bran Selic Rational Software Canada

Reflections on Software Architecture
Bran Selic
Rational Software Canada
[email protected]
“The bottom line for mathematicians is that the
architecture has to be right. In all the mathematics that I
did, the essential point was to find the right
architecture. It's like building a bridge. Once the main
lines of the structure are right, then the details
miraculously fit. The problem is the overall design.”
--Freeman Dyson
2
General Overview
 Part 1: Software Architectures, Architectural Models,
and the Unified Modeling Language
 Approach, definitions, UML as an ADL
 Part 2: Some Key Architectural Patterns for Modern
Software Systems
 Useful patterns for distributed systems
 Part 3: The Engineering of Software Architectures
 A conceptual framework for quantitative analyses of
software architectures
3
Part 1:
Software Architectures, Architecture
Models, and the UML
Objectives of Part 1
 Introduce key concepts and terminology
 Identify requirements for describing run-time
architectural views
 Demonstrate how UML can be used as an Architectural
Description Language (ADL)
5
Part 1 Overview
 Software Architecture Concepts
 Requirements for Modeling Run-Time Views
 The Unified Modeling Language
 A UML Profile for Architectural Modeling
6
IEEE Standard 1471-2000
 A “framework for codifying architectural thinking,
thereby facilitating the common application and
evolution of available and emerging architectural
practices”
 Adopted in September 2000
 Can be obtained (for free!) from:
http://ieeexplore.ieee.org/iel5/7040/18957/00875998.
pdf?isNumber=18957
7
IEEE 1471: Key Concepts
1
System
1
1..n
1..n
Stakeholder
1..n
Architecture
Architectural Description
1..n
Concern
1..n
1..n
1..n
1..n
1..n
Viewpoint
View
1..n
1..n
Model
8
1..n
IEEE1471: Key Definitions
 Architecture: “The fundamental organization of a system
embodied in its components, their relationships to each other
and to the environment, and the principles guiding its design
and evolution”
 Architectural description: “A collection of products to document
an architecture”
 View: “A representation of a whole system from the perspective
of a related set of concerns”
 Based on a viewpoint
 Viewpoint: “A specification of the conventions for constructing
and using a view”
 Identifies languages and methods used for describing views and
techniques for analyzing those views
 E.g., technology viewpoint, information model viewpoint
9
Reconciling Viewpoints
 Does this create a Humpty-Dumpty problem?
View 2
View 2
?
View 1
View 1
 Each viewpoint expresses a portion of the single
underlying model
 The different viewpoint languages should be formally aligned
10
The Role of Architectural Descriptions
 Specification of a system’s architecture
 Definition of its evolutionary envelope
 Communication among stakeholders (e.g.,
requirements elicitation)
 Evaluation and comparison of architectures
 Planning and managing system development
11
Communication Vehicle
End-user
Functionality
Technology
Process
Ease of integration
Functionality
Sales and field
support
Ease of use
Complexity
Qualities
Ease of customization
Reliability
Development
manager
Skills
Price
Business
Concerns
Architect
Development costs, skills
On time delivery
Developer
Performance and throughput
Stability and maintainability
Ease of diagnosing problems
System
administrator
Ease of introducing modifications
Testability and tractability
Structure and dependencies between parts
Ease of installation
12
Organization and
culture
Definition of the Evolutionary Envelope
 Anticipates likely directions of system evolution
 Evolution outside this envelope requires extensive
(systemic) changes and is usually very expensive and risky
Point-to-point architecture
A
X
Loosely-coupled architecture
A
X
Mediator
B
13
C
B
C
 Software Architecture Concepts
 Requirements for Modeling Run-Time Views
 The Unified Modeling Language
 A UML Profile for Architectural Modeling
14
Run-Time Views
 We are interested in defining a language and modeling
techniques for that language used in the run-time
viewpoint
 Run-time views describe:
The run-time organization of significant software
components interacting through interfaces, those
components being composed of successively smaller
components and interfaces
15
Example Run-Time View
 Example telecom run-time view
Structure
Channel1
TerminalA
TerminalB
Application Layer
Channel2
Services Layer
16
Behavior
Fundamental Run-Time Structural Relationships
 Peer relationship:
PartA
PartB
 Containment relationship:
Container
Container
Part
composition (existence dependency)
Part
Part
shared aggregation (information hiding)
 Layering relationship:
Layer N+1
Layer N
17
Architectural Component-Based Design
Library
Channel1
System1
Terminal
TerminalA
TerminalB
Channel2
Channel
System2
Terminal
Tester
18
TerminalA
Terminal
Tester
Refining Architectures (Reuse)
 E.g., using inheritance on entire architectures to derive product
families
Channel1
TerminalA
TerminalB
Channel1
TerminalA
TerminalB
Channel2
19
The Fate of Architectures: Architectural Decay
 The gradual deterioration of an architecture through
seemingly “minor” incremental changes
ring road
Lab Building
20
Preventing Architectural Decay
 Architectural decay occurs because
 The architecture is obscured in the implementation (code)
 There is no formal mechanism for ensuring that the
implementation conforms to the architectural description
 We need architectural description languages (ADLs)
that are easily learned and understood
 Graphical descriptions of run-time views are generally easier
to comprehend than textual ones
 We need to make the architectural description a
fundamental part of the implementation
 Requires formal ADLs that can be automatically converted
into code …and back
 Latest buzzword: Model-Driven Development
21
 Software Architecture Concepts
 Requirements for Modeling Run-Time Views
 The Unified Modeling Language
 A UML Profile for Architectural Modeling
22
The Unified Modeling Language
 A consolidation of proven ideas and practices based
on the object paradigm in the form of a generalpurpose OO modeling language
 Standardized by the Object Management Group in
1997
 Why focus on UML?
 Widely adopted by software practitioners
 Widely taught in universities and technical seminars
 Widely supported by many software tool vendors
23
UML: The Language of Software Development
Public
Feedback
Planned major revision (2002)
UML 2.0
Approved minor revision 2001
UML 1.4
Current minor revision 1999
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sept 1997
First submission to OMG, Jan 1997
UML 1.1
UML partners
UML 1.0
Web - June 1996
UML 0.9
Unified Method 0.8
OOPSLA 95
Other methods
24
OOSE
Booch method
Harel Statecharts
OMT
Components of UML
 Basic set of (extensible) modeling concepts
 used for modeling both problems and solutions (object,
class, association)
 deep semantic roots
 Formal rules of semantically meaningful composition of
concepts (well-formedness)
 Graphical notation for modeling concepts (optional!)
 8 different diagram types (requirements, structure, behavior,
deployment)
25
Semantic Variation in UML
 Semantic aspects that are:
 undefined (e.g., scheduling discipline), or
 intentionally ambiguous (multiple, mutually-exclusive,
interpretations)
 Why?
 Different domains require different specializations
 The applicability and usefulness of UML would have been
severely constrained if it could not support such diversity
 The scope and semantic impact of semantic variation
choices must be strictly limited
26
Specialization of UML
 Avoiding the PL/I syndrome (“language bloat”)
 UML standard as a basis for a “family of languages”
UML Standard 1.4
Real-Time UML
27
UML for eCommerce
Variations produced
using built-in
extensibility mechanisms:
stereotypes, tagged values,
constraints
…..etc.
How Do We Specialize UML?
 Typically used to capture semantics that cannot be specified
using UML itself
Integer
But, how can we
specify a clock?
Counter
ResetCounter()
Specialization
through regular
inheritance
28
Semantics:
an active counter whose
value changes
synchronously with the
progress of physical
time
Stereotyping UML Concepts
 Example: a “clock” stereotype based on the generic
UML Class concept
Integer
«clock»
MyTimePiece
SetTime()
29
Semantics:
an active counter whose
value changes
synchronously with the
progress of physical time
UML Profiles
 A package of related specializations of general UML
concepts that capture domain-specific variations and
usage patterns
 A domain-specific interpretation of UML
 Fully conformant with the UML standard
 additional semantic constraints cannot contradict the general
UML semantics
 within the “semantic envelope” defined by the standard
Standard UML Semantics
Profile Y
30
Profile X
 Software Architecture Concepts
 Requirements for Modeling Run-Time Views
 The Unified Modeling Language
 A UML Profile for Architectural Modeling
31
Capsules: Architectural Objects
 A special kind of active object
Encapsulation
shell
Ports
32
Capsules: Internal Behavior
 Optional hierarchical state machine (event handler with
run-to-completion semantics)
transitionS1toS2:
{int x;
x = 0;
p2.send(s1);
p3.send(s2);
…
};
S1
S2
33
S3
Capsules: UML Modeling
 Stereotype of Class concept («capsule») with
specialized (executable) semantics
 Class diagram representation:
«capsule»
CapsuleClassX
#counter : int
#x : char
ports
+portB : ProtocolA::master
+portC : ProtocolB
34
Protocols: Reusable Behavior Patterns
 Interaction contracts between capsules
 e.g., operator-assisted call
Caller
Operator
Callee
call
ack
number
call
ack
transfer
talk
time
35
Protocol Specifications
 A collaboration that may be required on multiple
occasions and situations
Alice
caller
OperatorAssisted
Call
callee
Bob
protocol state machine
significant sequences
caller
operator
callee
operator
initial
Charlie
Dexter
connecting
connected
36
Protocol Roles
 Specifies one party in a protocol
significant sequences
caller
operator
callee
Incoming signals
signal
source
call
caller
number
caller
ack
callee
OperatorRole
protocol state machine
Outgoing signals
signal
target
call
callee
transfer
caller
ack
caller
initial
connecting
connected
37
Protocol Refinement
 Using standard inheritance
Incoming signals
Incoming signals
signal
source
signal
source
call
caller
call
caller
number
caller
number
caller
ack
callee
ack
callee
reply
caller
OperatorRole
Outgoing signals
signal
target
call
callee
transfer
caller
ack
caller
Outgoing signals
Extended
OperatorRole
38
signal
target
call
callee
transfer
caller
ack
caller
query
caller
Ports
 Fully isolate a capsule’s implementation from its
environment (in both directions)
Capsule
S1
Environment
S2
Each port is typed with a single protocol role
39
Ports: Collaboration Diagram Notation
 Shorthand notation for capsule instances
 iconified form
portA : ProtocolA::master
«capsule»
/anX:CapsuleClassX
1
«port»
/portA:ProtocolA::master
41
Collaborating Capsules
 Using connectors
remote:FaxProt
«capsule»
sender : Fax
«capsule»
remote:FaxProt
receiver : Fax
Connector
Connectors model communication channels
Each connector supports a single protocol
Static typing rules apply (compatible protocols)
42
Composition: Structural Patterns
sendCtrl : Control
Relay
port
c : Control
receiveCtrl : Control
c : Control
remote:FaxProt
«capsule»
/sender:Fax
remote:FaxProt
«capsule»
/receiver:Fax
FaxCall
43
Composite Capsule Semantics
 Run-time assertion: the complete internal structure of a
composite is automatically created (recursively, if
necessary) when the capsule is created
f1 := create(FaxCall);
«capsule»
sender:Fax
«capsule»
receiver:Fax
f1:FaxCall
44
Benefits of Run-Time Assertion
 Architectural enforcement: only explicitly prescribed
architectural structures can be instantiated
 it is not possible to bypass (corrupt) the architecture by lowlevel programming
 Simplification: low-level program code that dynamically
creates (destroys) components and the connections
between them is eliminated
 in some systems this can be as much as 35% of all code
 Major net gain in productivity and reliability
45
End Ports: Where Structure and Behavior Meet
 Notational convention
Implementation
End Port
c : SystemControl
capsule state machine
senderCtrl : Control~
Public End
Port
receiveCtrl : Control~
initial
connecting
c : Control
«capsule»
/sender:Fax
46
connected
c : Control
«capsule»
/receiver:Fax
Summary: UML as an ADL
 Only four key UML stereotypes are needed
 Supplemented with formally defined constraints to ensure
executable models that can be used for automatic code
generation
Stereotype
UML Metaclass
«protocol»
Collaboration
«protocolRole»
ClassifierRole
«port»
Class
«capsule»
Class
 The UML 2.0 RFP requires this kind of modeling
capability in the UML core
48
Inter-Addendum
Active Object: Definition
 An active object is an object that, after creation,
commences execution of a program that continues until
the object has been terminated
 A key aspect of that program is the determination of
when to respond to service (feature) requests from
other objects
 Requires that the object have a buffer (“queue”) for keeping
pending service requests
 (Definition carefully adjusted to avoid any reference to
threads of control, processes, and similar technologyspecific mechanisms)
50
…just to stir up some interesting controversy
 Patterns are not symmetry breakers but symmetry
makers
 Used to restore symmetry where it has been broken
 Naturally, this requires them to be asymmetric, since broken
symmetry cannot be restored with symmetric things
 The aesthetics of patterns are determined by how
efficiently and how effectively they restore symmetry
51
However, to avoid less amusing controversy…
 “It does not matter whether the cat is white or black as
long as it catches mice”
-- Ancient Chinese capitalist proverb
 “Make a better mousetrap and the world will beat its
way to your door”
-- Modern American capitalist proverb
52
Part 2:
Some Key Architectural Patterns
Mousetraps for Modern Software
Systems
Objectives of Part 2
 Describe three important patterns used in architectural
design
 Demonstrate the use of the UML as an ADL
54
Design Patterns
 A design pattern is a proven generalized solution to a
generalized problem that can be used to derive a
specific solution to a specific problem
 Represent distilled reusable experience
 Major benefits of using patterns:
 Simplify and speed-up design
 Reduce risk
 Facilitate communications between designers
55
Part 2 Overview
 Example System
 The Recursive Control Pattern
 The Run-Time Layering Pattern
 The Guest Pattern
56
Example System
 A multi-line packet switch that uses the alternating-bit
protocol as its link protocol
End user
AB
protocol
AB
sender
line card 1
End user
.
.
.
AB
receiver
End user
57
line card N
unreliable
transmission
medium
AB
receiver
AB
sender
SWITCH
Alternating Bit Protocol (1)
 A simple one-way point-to-point packet protocol
packetizer
Sender
Receiver
unpacker
data(1)
pktA
data(1)
ack
ackA
ack
data(2)
pktB
data(2)
ack
ackB
ack
…etc.
58
AB
protocol
Alternating Bit Protocol (2)
 State machine specification
Sender SM
Receiver SM
AcceptPktA
RcvdPktA
ackB/^ack
data/^pktA
pktA/^data
ack/^ackA
timeout/^pktB
WaitAckA
timeout/^ackB
WaitAckB
AcceptPktB
59
WaitPktA
timeout/^ackA
timeout/^pktA
ackA/^ack
WaitPktB
data/^pktB
pktB/^data
RcvdPktB
ack/^ackB
 Example System
 The Recursive Control Pattern
 The Run-Time Layering Pattern
 The Guest Pattern
60
Additional Considerations
 Support infrastructure
operator
interface
AB
receiver
AB lines
manager
AB
sender
SWITCH
DB
interface
DBase
61
System
operator
Control
The set of (additional) mechanisms and actions
required to bring a system into the desired operational
state and to maintain it in that state in the face of
various planned and unplanned disruptions
 For software systems this includes:




62
system/component start-up and shut-down
failure detection/reporting/recovery
system administration, maintenance, and provisioning
(on-line) software upgrade
Retrofitting Control Behavior
Hardware
Audit
JustCreated
Analysing
Failure
ReadyToGo
GettingData
AcceptPktA
WaitAckA
WaitAckB
AcceptPktB
63
Failed
The Control Automaton
 In isolation, the same control behavior appears much
simpler
JustCreated
GettingData
Hardware
Audit
ReadyToGo
Operational
64
Analysing
Failure
Failed
Control versus Function
 Control behavior is often treated in an ad hoc manner, since it
is not part of the primary system functionality
 typically retrofitted into the framework optimized for the functional
behavior
 leads to controllability and stability problems
 However, in highly-dependable systems as much as 80% of the
system code is dedicated to control behavior!
65
Some Important Observations
 Control predicates function
 before a system can perform its primary function, it first has
to reach its operational state
 Control behavior is often independent of functional
behavior
 the process by which a system reaches its operational state
is often the same regardless of the specific functionality of
the component
66
Basic Design Principles
 Separate control from function
 separate control components from functional components
 separate control and functional interfaces
 imbed functional behavior within control behavior
 Centralize control
 if possible, focus control in one component
 place control policies in the control components and control
mechanisms inside the controlled components
67
The Basic Structural Pattern
 Set of components that need to be controlled as a unit
Central
Controller
Control
interface
Controlled
Component 1
...
Functional
(service)
interface
68
Controlled
Component N
Recursive Application
 Hierarchical control
 scales up to arbitrary number of levels
Central
Controller
Central
Controller
Controlled
Component 1
69
...
Central
Controller
Controlled
Component N
...
Controlled
Component 1
...
Controlled
Component N
Realization with UML-RT
 Composite plays role of centralized controller
«capsule»
CompSet
JustCreated
GettingData
Hardware
Audit
ReadyToGo
«capsule»
c1:Comp1
70
Operational
Analysing
Failure
Failed
«capsule»
cN:CompN
Exploiting Inheritance
 Abstract control classes can capture common control
behavior and structure
 Different subclasses capture function-specific behavior
AbstractControllee
ports
controlPort: CtrlProtocol
Sender
71
Receiver
. . .
Exploiting Hierarchical States
JustCreated
Analysing
Failure
AbstractControllee
ports
controlPort: CtrlProtocol
GettingData
Failed
Hardware
Audit
ReadyToGo
72
Sender
Operational
 Example System
 The Recursive Control Pattern
 The Run-Time Layering Pattern
 The Guest Pattern
73
Containment Relationships
 Two basic kinds:
Container
Container
Part
composition (existence dependency)
Part
Part
shared aggregation
 Common property: encapsulation
 Parts are hidden from view of external entities
74
Semantics of Layering (1)
 A fundamentally different type of structural relationship
AB sender
operator interface
Operating System
 Layering is different from containment
 Higher-layers do not contain lower layers
 Formally, the lower layers “contain” the higher layers
(existence dependency) but they do not encapsulate them
75
Semantics of Layering (2)
 In complex systems, layering is a complex
multidimensional relationship
 e.g., 7-layer model of Open System Interconnection (OSI)
Level 7
Level 6
Level 5
Level 4
Network
Link
Hardware
76
Operating
System
Some Inadequate Representations of Layering
 Staircase model
Application
Specialized Services
General Services
Operating System
 Toaster model
77
More on the OSI Model
 Two distinct kinds of interfaces: peer and SAP
Public Interface
Layer N + 1
Layer N + 1
SAP
Layer N
Public or Private
Interface?
78
Implementation Components
 Private sub-components required to realize the
functionality offered by component through its public
interface
Internal
implementation
component
A
B
AB sender
Timing Service
79
External
implementation
component
C
D
operator interface
Interface Types for Layering
 Need to differentiate two interface types:
 Usage interface: implementation-independent interface
through which a component provides its services (function
and control)
 Implementation interface (service access point):
implementation-specific interface through which a
component accesses an external service
 Front-end/back-end views:
Implementation
Interface
Usage
Interface
80
Implementation Interfaces
 Implementation interfaces are public interfaces but can
be viewed as being in a different “plane” (dimension)
from service interfaces
A
B
AB sender
90o
Timing Service
81
C
D
operator interface
Behavior Components and End ports
 End ports (ports connected directly to state machines)
Implementation
End Port
c : SystemControl
capsule state machine
senderCtrl : Control~
Public End
Port
receiveCtrl : Control~
initial
connecting
c : Control
«capsule»
/sender:Fax
82
connected
c : Control
«capsule»
/receiver:Fax
Implementation Interface Characteristics
 Implementation dependent
 Connected directly to behavior (e.g., state machine)
 Directly accessible independently of encapsulation
nesting
Shared Implementation Service
83
Modeling Layers with Capsules and Ports
 Implementation interfaces are modeled by
implementation end ports that can be connected
directly to service ports of other capsules
Service
access
point
«capsule»
UpperLayer
«capsule»
InternalComp
«capsule»
TimingService
84
 Example System
 The Recursive Control Pattern
 The Run-Time Layering Pattern
 The Guest Pattern
85
Architecture by Assertion and Dynamic Systems
«capsule»
/sender:Fax
«capsule»
/receiver:Fax
f1:FaxCall
 Much of the idea behind ADLs is to make explicit all valid
architectural structure
 Only the “officially certified” structural relationships can occur at run
time
 Ensures system integrity and security
 But, what about dynamic structures?
 Structures created in response to the dynamics of the physical world
(e.g., a fax call)
86
Dynamic Relationships
 In dynamic systems, it is not known in advance which
specific components will be involved in a dynamic
relationship
«capsule»
ABconnection
ABsender
?
87
ABsender[N]
ABreceiver
ABreceiver[N]
?
Dynamic Plug-In Roles
 Static placeholders that are filled in at run-time
Plug-in role
«capsule»
ABconnection
ABsender
ABsender
ABsender[1]
{plug-in}
ABsender[N]
88
ABreceiver
ABreceiver
Abreceiver[7]
{plug-in}
ABreceiver[N]
Type Genericity of Plug-ins
m:T1
a:T1
n:T2
b:T2
aReceiver:P
ABreceiver
{plug-in}
x:T2
y:T1
bReceiver:Q
z:T3
 Plug-in roles can be filled in by any component that has
the appropriate ports
 provided that the corresponding ports are not already
connected in some other composite
 a capsule can fit in even if it has additional ports that are not
required for the role
89
General Overview
 Part 1: Software Architectures, Architectural Models,
and the Unified Modeling Language
 Approach, definitions, UML as an ADL
 Part 2: Some Key Architectural Patterns for Modern
Software Systems
 Useful patterns for distributed systems
 Part 3: The Engineering of Software Architectures
 A conceptual framework for quantitative analyses of
software architectures
91
Part 3:
The Engineering of Software
Architectures
Objectives of Part 3
 Establish the importance of the quantitative aspects in
the architecting of software systems
 To introduce an engineering-oriented approach to
software architecture design and show how it can be
effectively realized in a UML context
93
Part 3 Overview
 The Physics of Software
 The Logical and Engineering Viewpoints
 Quality of Service Concepts
 Engineering-Oriented Software Design
94
Common Wisdom...
 When designing software, we are instructed to ignore
details of the technology and similar “implementation”
issues until we have devised a logically sound solution
to the problem
 simplifies the design problem (separation of concerns)
 software is portable to new/different technologies
 But, in the days of Internet-based distributed
applications, is this still a valid approach?
95
Real World Design Issues (1)
 Possibility of out-of-date state information due to
lengthy (and variable) transmission delays
Node1 (New York)
Node2 (Tokyo)
observer
on
“on”
State?
“on”
It’s a game of numbers!
96
off
Real World Design Issues (2)
 Inconsistent views of system state due to relativistic
effects:
 different observers see different event orderings
clientA
notifier1
notifier2
clientB
e2
e1
e1
e2
time
It’s a game of numbers!
97
Distributed System Characteristics
 Key characteristics:
 concurrency and asynchrony
 need for communication and synchronization between sites
 communication delays
 possibility of partial failure
 Each of these adds major complexity to our design problem
 Real-world distributed programming can be different from and
much more complex than conventional programming
 In general, these problems cannot always be solved by underlying
services!
98
Impossibility Result No.1
It is not possible to guarantee that agreement
can be reached in finite time over an
asynchronous communication medium, if the
medium is lossy or one of the distributed sites
can fail
 Fischer, M., N. Lynch, and M. Paterson,
“Impossibility of Distributed Consensus with One
Faulty Process” Journal of the ACM, (32, 2) April
1985.
99
Impossibility Result No.2
It is not possible to guarantee common
knowledge [distributed agreement] if
communication delays are unbounded, even if
communication is guaranteed
 Halpern, J.Y, and Moses, Y., “Knowledge and
common knowledge in a distributed environment”
Journal of the ACM, (37, 3) 1990.
100
Is Software an Embodiment of the Platonic Ideal?
 The idealized “forms” of pure logic acquire the finite
characteristics of the physical stuff out of which they are
spun
 limited speed, limited capacity, limited availability,...
101
Real-World Design Issues
 Much of the complexity associated with these systems
is the result of the “intrusion” of the inherently complex
physical world into the idealized logical world of
software
 The real-world design dilemma:
 if the physical world intrudes on the logical world, how can
we separate the “logical” world of design from the “physical”
world of implementation to achieve portability?
102
 The Physics of Software
 The Logical and Engineering Viewpoints
 Quality of Service Concepts
 Engineering-Oriented Software Design
103
Logical Viewpoint
 Defines a technology-independent view of the software as a
network of distributed components interacting through interfaces
INSTRUCTOR
STATION
AIRFRAME
ATMOSPHERE
MODEL
CONTROL
SURFACES
GROUND
MODEL
ENGINES
104
PILOT
CONTROLS
Engineering Viewpoint
 Defines a view of a system based on a more technology
oriented specification
Processor
OS process
Processor
Ethernet LAN
OS process
stack
stack
TCP/IP socket
TCP/IP socket
OS process
stack
105
Viewpoints and Mappings
Logical View
INSTRUCTOR
STATION
AIRFRAME
ATMOSPHERE
MODEL
CONTROL
SURFACES
GROUND
MODEL
PILOT
CONTROLS
ENGINES
Realization
mappings
Engineering View
Processor
OS process
Processor
OS process
stack
Ethernet LAN
stack
TCP/IP socket
TCP/IP socket
OS process
stack
106
The Engineering Viewpoint
 The engineering viewpoint represents the “raw
material” out of which we construct the logical viewpoint
 the quality of the outcome is only as good as the quality of
the ingredients that are put in
 as in all true engineering, the quantitative aspects are often
crucial (How long will it take? How much will be required?…)
 The ability to accurately model the relationship between
the engineering and logical models is crucial
107
Realization Mappings
 A correspondence between elements of two distinct models
(logical and engineering)
 Semantics: the logical elements are implemented by the
corresponding engineering model elements
 logical elements can be viewed as “residing” on the corresponding
engineering elements
AIRFRAME
OS process1
Processor
CONTROL
SURFACES
Model 1
108
OS process1
Model 2
Model 3
Selecting a Level of Abstraction
 Intermediate levels may be abstracted out
 depends on the desired granularity of modeling
 affects the semantics of the realization relationship
AIRFRAME
OS process1
Processor
CONTROL
SURFACES
Model 1
OS process1
Model 2
Model 3
AIRFRAME
Processor
CONTROL
SURFACES
Model 1
109
Model 3
UML and Realization Mappings
 Through deployment diagrams
:Scheduler
:Planner
reservations
update
Generally not sophisticated
enough for modeling complex
realization relationships
110
Component
Node
:GUI
 The Physics of Software
 The Logical and Engineering Viewpoints
 Quality of Service Concepts
 Engineering-Oriented Software Design
111
Quality of Service
 We introduce quantitative characteristics through the
general notion of Quality of Service (QoS):
a specification (usually quantitative) of how well a service is
(to be) performed
 e.g. throughput, capacity, response time
 A QoS specification can be one of:
 offered QoS: the QoS that it provides to its clients
 required QoS: the QoS it requires from other components to
support its QoS obligations
112
Resources and Quality of Service
 Resource:
an element whose service capacity is limited, directly or
indirectly, by the finite capacities of the underlying physical
computing environment
 These capacities are expressed through QoS attributes
of the service or resource
Client
Resource Usage
S1
S1
OfferedQoS
RequiredQoS
{RequiredQoS  OfferedQoS}
113
Resource
Simple Example
 Concurrent tasks accessing a monitor with known response time
characteristics
Required QoS
Client1
Client2
access ( )
access ( )
{Deadline = 3 ms}
{Deadline = 5 ms}
myMonitor
{MaxExecutionTime = 4 ms}
Offered QoS
114
The Resource Model and Realization
Logical Model Element
CPU :
3 MIPs
Mem :
2MB
Bandw. :
70Mbit/s
client
required QoS values
resource usage (demand)
3MIPs
20MB
CPU
100Mbit/s
LAN
environment “services”
(offered QoS values)
resources
 This type of QoS framework has already been defined in a
standard UML profile: UML profile for scheduling, performance,
and time
115
The Real-Time UML Profile
 Defined within the OMG: “UML profile for scheduling,
performance, and time”
 Standard methods for UML modeling of:







116
Physical time
Timing specifications
Timing services and mechanisms
Modeling resources (logical and physical)
Concurrency and scheduling
Software and hardware infrastructure and their mapping
..including specific notations for the above where necessary
RT Profile: Guiding Principles
 Ability to specify quantitative information directly in UML models
 key to quantitative analysis and predictive modeling
 Flexibility:
 users can model their systems using modeling approaches and styles
of their own choosing
 open to existing and new analysis techniques
 Facilitate the use of quantitative analysis methods
 eliminate the need for a deep understanding of analysis methods
 as much as possible, automate the generation of analysis models and
the analysis process itself
117
Quantitative Methods for RT Systems
 Used to:
 predict system characteristics (detect problems early)
 analyze existing system
 synthesize elements of the model
 Methods considered for the profile:
 Schedulability analysis
will the system meet all of its deadlines?
 Performance analysis based on queueing theory
what kind of response will the system have under load?
118
Issues with Quantitative Methods
 Require uncommon and highly-specialized skills
 Software is notoriously difficult to model
 highly non-linear (detail often matters)
 models are frequently severely inaccurate and not trustworthy
 typical modeling process is highly manual:
System
Model
analysis
results
+
Actual
System
119
measurements
Desired Development Model
 Seamless integration of technologies and tools based on
standards for real-time modeling
Automated
model conversion
Model Editing
Tool
4
Model Analysis
Tool
3.1
5
Inverse automated
model conversion
120
How Do We Specialize UML?
 Typically used to capture semantics that cannot be specified
using UML itself
Integer
But, how can we
specify a clock?
Counter
ResetCounter()
Specialization
through regular
inheritance
121
Semantics:
an active counter whose
value changes
synchronously with the
progress of physical
time
Stereotyping UML Concepts
 Example: a “clock” stereotype based on the generic
UML Class concept
Integer
«clock»
MyTimePiece
SetTime()
122
Semantics:
an active counter whose
value changes
synchronously with the
progress of physical time
«clock» is declared as a
stereotype of the UML
Class concept
RT Profile Structure: Normative and Non-Normative Parts
General Resource Model
«profile»
RTresourceModeling
Client
etc.
Resource
«import»
«profile»
ADprofile
«import»
Specialized Analysis Domain Model
Analysis
Client
«metaclass»
Object
«stereotype»
etc.
Analysis
Resource
What (non-normative)
124
«metaclass»
Class
«stereotype»
ADresource
etc.
How (normative)
UML Real-Time Profile Structure
General Resource Modeling Framework
«profile»
RTresourceModeling
«import»
«import»
«profile»
RTconcurrencyModeling
«import»
«profile»
RTtimeModeling
«import»
«import»
Analysis Models
«profile»
SAProfile
«import»
«profile»
RSAprofile
125
Infrastructure Models
«profile»
PAprofile
«modelLibrary»
RealTimeCORBAModel
Instance- vs Class-Based Models
N2:Node
1
Node
N1:Node
N3:Node
1
N4:Node
 Practically all analysis methods are concerned with instancebased models
 However, it is often useful to associate QoS characteristics with
classes
 Used to define default values that may be overridden for specific
instances
 Need to apply a stereotype to both spec elements and instance
elements
126
Core Resource Model
+type Descriptor
1..n
Instance
0..n
0..n
ResourceInstance
+instance
+type
0..n
Resource
1..n
0..n
l
+offeredService
1..n
ResourceServiceInstance +instance
0..n
0..n
1..n
+type ResourceService
1
0..n
/
/
+offeredQoS
0..n
0..n
QoSvalue
QoScharacteristic
+instance
0..n
0..n
127
+offeredQoS
+type
1
0..n
Basic Resource Usage Model
EventOccurence
(from CausalityModel)
AnalysisContext
1
1..n
1..n
1..n
UsageDemand
0..n
1
0..1
1
+workload
+usedResources
ResourceUsage
ResourceInstance
1..n (from CoreResourceModel)
0..n
+usedServices
1..n
ResourceServiceInstance
0..n (from CoreResourceModel)
StaticUsage
128
DynamicUsage
Dynamic Usage Model
DynamicUsage
(from ResourceUsageModel)
Scenario
(from CausalityModel)
1..n
+usedResources
/
1..n
ResourceInstance
(from CoreResourceModel)
1..n
{ordered}
1..n
ActionExecution
+step
+successor
/
1..n
+usedServices
1..n
0..n
ResourceServiceInstance
(from CoreResourceModel)
0..n
+predecessor 0..n
0..n
0..n
+requiredQoS
0..n
+offeredQoS
QoSvalue
(from CoreResourceModel)
129
Static Usage Model
StaticUsage
(from ResourceUsageModel)
Client
+usedResources
ResourceInstance
1..n (from CoreResourceModel)
0..n
1..n
0..n
+requiredQoS
1..n
QoSvalue
(from CoreResourceModel)
+instance 0..n
+type 1
QoScharacteristic
(from CoreResourceModel)
130
Instance
(from CoreResourceModel)
+offeredQoS
0..n
/
General Time Model
TimingServices
TimedEvents
TimeModel
131
TimingMechanisms
Physical and Measured Time
Physical
Time
Clock
(from TimingMechanisms)
1
{ordered}
0..n
n
n
PhysicalInstant
TimeValue
+measurement
kind : {discrete, dense}
0..n
+start
1
1
n
1
+end
n
+s tart
n
Duration
+measurement
0..n
132
+referenceClock
0..n
1
+end
n
Tim eInterval
Performance Analysis Concepts
PerformanceContext
0..n
1
1
1..n
1..n
1..n
+resource
PResource
PScenario
0..n
0..n utilization
1 hostExecutionDemand
schedulingPolicy
responseTime
throughput
0..n
1
<<deploys>>
Workload
responseTime 1..n
priority
ClosedWorkload
population
externalDelay
OpenWorkload
occurrencePattern
+root
1
PStep
probabilty
+successor repetition
delay
0..n operations
interval
executionTime
+predecessor 0..n
133
{ordered}
+host 0..1
1..n
PProcessingResource
processingRate
contextSwitchTime
priorityRange
isPreemptible
PPassiveResource
waitingTime
responseTime
capacity
accessTime
Example: Web Video Application
Engineering Instance Model
vp : VideoPlayer
vw : VideoWindow
b : Browser
«GRMdeploys»
Logical Instance Model
«GRMdeploys»
:ClientWorkstation
vw : VideoWindow
ws : WebServer
: WebServerNode
vs : VideoServer
«GRMdeploys»
: VideoServerNode
b : Browser
: Internet
vp : VideoPlayer
ws : WebServer
Usage Scenario
b : Browser
ws : WebServer
vs : VideoServer
vp : VideoPlayer
vw : VideoWindow
vs : VideoServer
processSelection
initialPlayout
initializePlayer
confirm
sendFrame
showFrame
*[$N]
terminalPlayout
134
Example: Performance Requirements











135
Estimated video server processing demand per frame = 10 ms
Estimated viewer processing demand per frame = 15 ms (dev = 20 ms)
Assumed network delay distribution: exponential with mean = 10 ms
Measured packets per frame (LAN) = 65
Measured video server file operations per frame = 12
Max. number of concurrent users = $Nusers
Average inter-session times = 20 minutes
Frames in a video $N
Video frame intervval = 30 ms
Required confirmation delay: 95% < 500 ms
Required interval between frame displays = 99% < 30 ms
Example: Annotations for a Scenario
«PAcontext»
«PAclosedLoad»
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
bb :: Browser
Browser
ws
ws :: WebServer
WebServer
vs : VideoServer
vp : VideoPlayer
vw : VideoWindow
processSelection
processSelection
initialPlayout
confirm
confirm
«PAstep»
{PArespTime=
('req','percentile',95,500,'ms')}}
«PAstep»
{PAdemand=
('est','mean',1,'ms')}}
initializePlayer
«PAstep»
{PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
sendFrame
showFrame
«PAstep»
{PArep=$N,
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)}
*[$N]
terminalPlayout
«PAstep»
{PAinterval=
('req','percentile',99,30,'ms')}}
136
Example: More Annotations
«PAcontext»
vp : VideoPlayer
vw : VideoWindow
«GRMdeploys»
{PAschdPolicy=PR,
PArate=1,
PAutilization=$Util,
PActxtSwT=('est','mean',40,'us')}
«PAhost»
:ClientWorkstation
b : Browser
ws : WebServer
«GRMdeploys»
«PAhost»
: WebServerNode
vs : VideoServer
«GRMdeploys»
«PAhost»
: VideoServerNode
«PAcontext»
: Internet
vs : VideoServer
«PAstep»
send
frame
vp : VideoPlayer
{PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)}
«PAstep»
receive
frame
{PAinterval=
('req','percentile',99,30,'ms')}}
137
vw : VideoWindow
{PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
«PAstep»
show
frame
Example: Model Analysis
Video Application Model
Result:
a new model with
analysis variable
values set
{$Nusers}
{$Nusers = 7}
Performance
Analyzer
May include
additional
tool-specific
results encased
in UML Notes
138
Video Application Model
The Resource Model and Realization
Logical Model Element
CPU :
3 MIPs
Mem :
2MB
Bandw. :
70Mbit/s
client
required QoS values
resource demand
3MIPs
20MB
CPU
139
100Mbit/s
LAN
environment “services”
(offered QoS values)
resources
Modeling Realization with the RT Profile
 An association between models with explicit realization
mappings between model elements
Logical Model
A
Engineering Model
«GRMrealizes»
asc
X
Y
Z
B
Source element Dest. elements
Compact tabular form
A
X, Y
asc
Y
B
Z
deployment table
140
A stereotype of the
UML realizes relationship
Specifying Realization Mappings
 Captures the specifics of the realization mapping
 Either as a string (tag value) or as a table
Logical
Elements
<List of logical
model
elements>
Engineering
Elements
<List of
corresponding
engineering
model elements>
Mode
Linkage
<If there are multiple
engineering elements,
one of:>
{inclusive,
exclusiveStatic,
exclusiveDynamic}
L1
E1
141
…
<Interaction mode
between levels, one
of:>
{sync,
async,
replace}
Additional
Constraints
<Any additional
constraints that
apply to the
mapping>
L
sync = SW to SW
async = SW to SW
replace = SW to HW
En
E
 The Physics of Software
 The Logical and Engineering Viewpoints
 Quality of Service Concepts
 Engineering-Oriented Software Design
142
Engineering-Oriented Design (EOD)
 Analysis and design of software systems based on
 Use of models (Model-Driven Development)
 QoS specifications (accounting for physical properties)
 Quantitative analysis techniques and simulation
 Advantages:
 Higher reliability (simplification due to modeling)
 Ability to predict system characteristics (and major design
flaws) prior to full realization
 Portability!
143
Achieving Portability with EOD
 Dilemma: How can we account for the engineering
aspects of the system without prematurely and possibly
unnecessarily committing to a particular technology?
 Approach: Provide an abstract technology-independent
but quantified specification of the required
characteristics of the engineering model as part of the
logical model
144
The Required Environment
 A technology-neutral model of the minimal acceptable
environment required the logical model
Logical View
Required Environment
Engineering View (alternative A)
UNIX
Process
145
UNIX
Process
Engineering View (alternative B)
WinNT
Process
WinNT
Process
Required Environment Partitions
 Logical elements often share common QoS requirements
INSTRUCTOR
STATION
AIRFRAME
ATMOSPHERE
MODEL
CONTROL
SURFACES
GROUND
MODEL
ENGINES
146
PILOT
CONTROLS
QoS domain
(e.g.,failure unit,
uniform comm properties)
QoS Domains
 Specify a domain in which certain QoS values apply
universally:
 failure characteristics (failure modes, availability, reliability)
 CPU performance
 communications characteristics (delay, throughput, capacity)
 etc.
 The QoS values of a domain can be compared against
those of a concrete engineering environment to see if a
given environment is adequate for a specific model
147
Modeling QoS Domains in UML
 Similar to realization: mapping of logical elements to a
desired (required) engineering environment
Logical View
«GRMrequires»:
a specialization of the
“realizes” relationship
Required Environment
QoS1
A local “engineering” model
148
QoS2
QoS3
Example: QoS Domain for an Active Object
 Using a stereotype of Node
 in conjunction with the “required environment” relationship
Active class
R
readObj ()
Stereotype
GRMthreadEnv
UML base
concepts
Node,
Instance
«GRMrequires»
«GRMthreadEnv»
ThreadForR
{priority = 3; heap = 20 KB;
stack = 3 KB}
149
Environment expected
by instances of class R
Tags
priority [0..1] : Integer
heap [0..1] : Real
stack [0..1] : Real
Example: Task Allocation
 The allocation of logical model to engineering model elements
Task1
master : Master
d : DBaseServer
Task2
dBadmin : Admin
MainTask
Task3
poller : Poller
150
cs : CommServer
Example: UML Model of Allocation
LogicalPkgX
d : DBaseServer
master : Master
dBadmin : Admin
«GRMrequires»
poller : Poller
cs : CommServer
«GRMrequires»
EngineeringPkgY
Task1 : Task
«GRMrequires»
Task2 : Task
«GRMrequires»
Task3 : Task
EngineeringPkgZ
MainTask : Task
«import»
«GRMschedulableEntity»
Task
151
«GRMrequires»
Example: Completing the Mapping
 Final mapping to hardware (deployment)
EngineeringPkgY
Task1 : Task
«GRMrealize»
Task2 : Task
«GRMrealize»
Task3 : Task
«GRMrealize»
EngineeringPkgD
«SAProcessingResource»
Proc1
152
MainTask : Task
«GRMrealize»
Summary: Design and Engineering
 In complex real-world systems, the logical design is strongly
influenced by the characteristics of the engineering
environment
 There is a strong need to model the physical characteristics of our
software designs
 In particular, at the architectural level to detect potential “-ility”
catastrophies
 The QoS-based approach described here can serve as a basis
for:
 quantitative analysis of UML-based models
 a modeling standard that will facilitate automated exchange between
design and analysis tools
 Engineering-oriented design: A step towards transforming
software construction into a full-fledged engineering discipline
153
A Look Ahead at UML 2.0
UML 2.0
 Request for Proposal (RFP) issued in June 2000
 4 separate RFPs issued:
 Infrastructure RFP: a re-factoring of the UML specification
for simplification of the semantics and alignment with the
OMG Meta Object Facility (MOF)
 Superstructure RFP: user concepts
 OCL RFP: consolidate OCL semantics with UML semantics
(infrastructure)
 Diagram interchange RFP
 Final submissions due in April 2002
155
UML 2.0: Superstructure RFP
 Four principal areas:
 Architectural modeling capabilities
 Behavioral modeling: redefinition of activity graphs and new
structuring concepts for state machines
 Interaction modeling: more complex scenario modeling
(sequence diagrams)
 More precise specification of key UML relationships
(generalization/specialization, trace, realization)
 The architectural modeling capabilities ask for a more
elaborate way of expressing complex structured
classifiers (i.e., capsules, ports, connectors)
156
UML 2.0: Structured Classifiers
 Ability to model a classifier that consists of internal
parts, which may themselves be instances of structured
classifiers, interconnected via ports
 The definition of reusable interaction patterns
(protocols)
 Full forward compatibility of the basic class (diagram)
model
 will be able to use UML as before for class-association
modeling
 new capabilities are additive (used only if required)
 Consolidation of three overlapping concepts: composite
classifier, subsystem, component
157
UML 2.0: Classifiers, Subsystems, Components
 All three model complex run-time constructs
 Likely scenario:
 composite classifiers (capsules) are the fundamental
mechanism for modeling complex architectural elements
 subsystems and components will be consolidated
 Subsystem/component:
 a conceptual unit that takes on many different forms
throughout the development lifecycle (requirements element
with complex specs, composite classifier, unit of CM,
deployment/change unit)
158
Bibliography
 Cooper, R., Introduction to Queueing Theory, The Macmillan Company, 1972.
 IEEE Software Engineering Standards Committee, “IEEE Recommended Practice for
Architectural Description of Software-Intensive Systems, September, 2000.
 I. Jacobson, G. Booch, and J. Rumbaugh, “The Unified Software Development Process,”,
Addison-Wesley, 1999.
 Klein, M. et al., A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate
Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993.
 OMG, “The Unified Modeling Language” version 1.3, The Object Management Group,
August 1999.
 OMG, “UML™ Profile for Scheduling, Performance, and Time - Request for Proposal”,
The Object Management Group, March 1999 (doc ad/99-03-13).
 UML Real-Time Consortium, “Response to the OMG RFP for Schedulability, Performance,
and Time,” June, 2001 (OMG document ad/01-06-14).
 J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling Language Reference
Manual,”, Addison-Wesley, 1999.
 B. Selic, “Turning Clockwise: Using UML in the Real-Time Domain”, Communications of
the ACM, vol.42, no.10, October 1999 (pp.46-54).
 B. Selic, “A Generic Framework for Modeling Resources with UML,” IEEE Computer
vol.33, no.6, June 2000 (pp. 64-69).
 B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real-Time Systems,”
ObjecTime Limited and Rational Software Corp., March 1998. (http://www.rational.com)
159