Page 1
© Copyright Malina Software
Abstraction Patterns in Model-Based Engineering
Bran SelicMalina Software Corp., CanadaZeligsoft (2009) Ltd., CanadaSimula Research Labs, NorwayUniversity of Toronto, CanadaCarleton University, Canada
[email protected]
Page 2
© Copyright Malina Software2
What is ―Abstraction‖?
A human defence mechanism for coping with overwhelming complexity
Often, it is our only mechanism for dealing with complexity
SYSTEM
Page 3
© Copyright Malina Software3
Abstraction: A Fundamental Engineering Skill
The ability to see the forest (i.e., the system as a whole) despite the trees (i.e., technological detail)
It seems to be less common than people might expect
...particularly among software people
Many programmers but few ―architects‖
• Agile development and ―big design‖ perceived as mutually exclusive
• E.g., M. Fowler: ―Is design dead?‖
Requires an interest in and a concern for the system and its purpose (users)
Can abstraction be taught?
Page 4
© Copyright Malina Software4
Background: Definitions
ABSTRACTION: A process by which ―higher‖ concepts are derived from the usage and classification of literal (―real‖ or ―concrete‖) concepts, first principles, and/or other abstractions [Wikipedia]
ABSTRACTION (computer science): a mechanism and practice to reduce and factor out details so that one can focus on a few concepts [Wikipedia]
Two approaches:
Relaxionist: By weakening of constraints
Reductionist: By removing ―irrelevant‖ detail
• Relevance is a function of viewpoint (set of concerns)
Page 5
© Copyright Malina Software5
For Our Purposes...
ABSTRACTION : Selective reduction of information of a system which preserves its salient properties relative to a given set of concerns
Refinement is the inverse process
In engineering: abstraction modeling
Page 6
© Copyright Malina Software6
Engineering Models
ENGINEERING MODEL: A selective representation of some system that captures accurately and concisely all of its essential properties of interest for a given set of concerns
• We don’t see everythingat once
• What we do see is adjusted to human understanding
Page 7
© Copyright Malina Software7
Why Do Engineers Build Models?
To understand
…the interesting characteristics of an existing or desired (complex) system and its environment
To predict
…the interesting characteristics of the system by analysing its model(s)
To communicate
…their understanding and design intent (to others and to oneself!)
To specify
...the implementation of the system (models as blueprints)
Page 8
© Copyright Malina Software8
The Trouble with Models
―The devil is in the details‖
Leaving out something crucial
Underestimating its relevance
Accidental oversight
Inaccurate and untrustworthy models
Exacerbated by the common practice of NOT documenting the abstraction process
Page 9
© Copyright Malina Software9
Characteristics of Useful Engineering Models
Purposeful:
Constructed to address a specific set of concerns/audience
Abstract
Emphasize important aspects while removing irrelevant ones
Understandable
Expressed in a form that is readily understood by observers
Accurate
Faithfully represents the modeled system
Predictive
Can be used to answer questions about the modeled system
Cost effective
Should be much cheaper and faster to construct than actual system
To be useful, engineering models must satisfy at least these characteristics!
Page 10
© Copyright Malina Software10
What About Software Modeling?
―…bubbles and arrows, as opposed to programs, …never crash‖
-- B. Meyer―UML: The Positive Spin‖
American Programmer, 1997
MonitorPH
RaisePH
ControlPH
PH reached X
Current PH
start
stop
Input valvecontrol
Page 11
© Copyright Malina Software11
The Prevalent Attitude to Modeling
We don’t do modeling here...it’s a waste of time
But...
Page 12
© Copyright Malina Software12
refine
NotStarted
Started
start
producer
Modern Model-Based Software Engineering
Models can be refined continuously until the application is fully specified the model becomes the system that it was modeling!
«sc_method»
producerstart out1
NotStarted
Started
start
producer
St1 St2
void generate_data(){for (int i=0; i<10; i++) {out1 = i;}}
/generate_data( )
Page 13
© Copyright Malina Software13
A Unique Feature of Software
A software model and the software being modeled share the same medium—the computer
Which also happens to be our most advanced and most versatile automation technology
Software has the unique property that it allows us to directly evolve models into implementations without fundamental discontinuities in the expertise, tools, or methods!
High probability that key design decisions will be preserved in the implementation and that the results of prior analyses will be valid
Page 14
© Copyright Malina Software14
The Model-Based Engineering (MBE) Approach
An approach to system and software development in which software models play an indispensable role
Based on two time-proven ideas:
switch (state) {
case‘1:action1;
newState(‘2’);
break;
case‘2:action2;
newState(‘3’);
break;
case’3:action3;
newState(‘1’);
break;}
(2) AUTOMATION
S1
S3
S2
e1/action1
e2/action2
e3/action3
switch (state) {
case‘1:action1;
newState(‘2’);
break;
case‘2:action2;
newState(‘3’);
break;
case’3:action3;
newState(‘1’);
break;}
(1) ABSTRACTION
S1
S3
S2
e1/action1
e2/action2
e3/action3
Realm of modelinglanguages
Realm of tools
Page 15
© Copyright Malina Software15
NotStarted
Started
start
producer
St1 St2
But, if the Model is the System…
…do we not lose the abstraction value of models?
void generate_data(){for (int i=0; i<10; i++) {out1 = i;}}
/generate_data( )
Started
• The computer offers a uniquelycapable abstraction device:
Software can be representedfrom any desired viewpoint atany desired level of abstraction
The abstraction is inside the systemand can be extracted automatically
Provided that the abstraction process is tracked and recorded
Page 16
© Copyright Malina Software16
Successive Levels of Abstraction
Higher-level models are needed at all times both during and following development
Not just during design
For maintenance and system evolution
Level N Model
Level N-1 Model
refinement
Implementation (L0) Model
. . .
refinement
Page 17
© Copyright Malina Software17
Tracking Refinement/Abstraction
If the relationships between models at different levels of abstraction are explicitly tracked and recorded, it is possible to:
Validate the abstraction/refinement steps
Reconstruct (automatically) an abstract model from a more concrete one
Implementation (L0) Model
. . .
refinement
refinement
abstraction
abstraction
Level N-1 Model
Level N Model
. . .
Page 18
© Copyright Malina Software18
The Abstraction Patterns Catalogue
A starter catalogue to be used by architects and developers
Precise definition of patterns expressed using a graph-based formalism (featured graphs)
Suitable for various graph-based modeling languages such as UML
Patterns for:
Structure
Behaviour
Also included are temporal patterns
Page 19
© Copyright Malina Software19
A Useful Formalism: Featured Graphs
FG = <Nodes, Edges>
n Nodes; n = <id, Ftrs(n), Pins(n)>
e Edges; e = <id, Ftrs(e), Srcs(e), Dests(e)>
n1
{f11, f1
2,...}p1
1
n2
{f21, f2
2,...}
p22
n3
{f31, f3
2,...}
p33
p13
p12
p21
p31
p32
e13
{f231, f23
2,...}
e12{f121, f12
2,...}
Features: fine-grained attributes
Edges: information flows, communication channels Pins:
connection points (e.g., ports, pins)
Nodes: structural or behaviouralcomponents
Page 20
© Copyright Malina Software20
Abstraction/Refinement Patterns
Patterns used by architects and designers
Each pattern consists of a refinement graph, an abstract graph, and a formally defined set of mappings between them
Pattern = <RefGraph, Mappings, AbsGraph>
Each mapping is a pair comprising a single AbsGraphelement and a corresponding RefGraph element
refElem RefGraph | mapping Mappingsmapping = <absElem, refElem>absElem AbsGraph
Each refGraph element is covered by a mapping to ensure that nothing is overlooked
Page 21
© Copyright Malina Software21
Structural Pattern: Black Box
Based on a common meta-pattern that appears in different forms in both structure and behaviour modeling
Synthesizes a network of tightly-coupled concrete components and renders them as a single high-level component
Glass Box
gb'cx2’cx1’
p1’ p2’
e2’e1’
c1
c2
c3
c4
cx2cx1
p1p2
e1e2
abstraction
―Cross-over‖ connectors map to a port-connector combination Everything fully
inside the box maps to a single abstract component
Page 22
© Copyright Malina Software22
Structural Pattern: Black Line
Abstracts a collection of elements realizing a communications path into a single edge (connector)
Could be multipoint
Connector Glass Box
C1 C2
A’ B’
A C4 BC3e1 e2 e3 e4 e5
abstraction
―Cross-over‖ connectors map to connector end points
Everything fully inside the box maps to a single abstract connector
Page 23
© Copyright Malina Software23
Structural Pattern: Cable
Group of connectors between that share the same source and sink components
AbsCmp2AbsCmp1e'
RefCmp2
Apply
Pattern
e1
e2
e3
en
...
RefCmp1
abstraction
All concrete connectors map to a single high-level connector
Page 24
© Copyright Malina Software24
Structural Pattern: Port Group
Multiple concrete ports (possibly different types) merged into a single abstract port
Often combined with ―Cable‖ pattern
RefCmp
p1
p2
p3
pn
.
.
.
AbsCmp p'
abstraction
Page 25
© Copyright Malina Software25
A Common Structural Pattern: Layering
What does it actually mean?
Bizbaz
RUF
Sneezer
Glooger
Caster
POOFOO
GRUMP
Dooper Framework
Super Framework
Blooper
Geezer
PURR
Page 26
© Copyright Malina Software26
Platform
Application 1 Application 2
. . .Application 1
a11 a12
Application 2
a21 a22
Platform Layering
Distinguishing characteristics
Upper layer: realizes some higher-level functionality
Lower layer: a set of potentially shared services used to implement the upper layer = ―platform‖
Example: Upper layer entities depend on the services of the platform layer for their implementation
Upper layer entities depend on the services of the platform layer for their implementation
Operating System
FileSystem
Multitasking System
IPCSystem
. . .
Lower layer entities do notdepend on the upper layer entities, but do participate in their implementation
Page 27
© Copyright Malina Software27
Application Glass Box
Structural Pattern: Platform Layering
A composition of multiple pattern applications
Platform Glass Box
a2
servA
a1 b2 b1e1
e2
e3
e4
e5
app’
plat’
e'
servB
abstraction
e6e7
servCe6
Black Box pattern for application and platform components
Black Box pattern for application and platform layersCable pattern for
cross-over connectors (usually not shown)
Page 28
© Copyright Malina Software28
The Semantics of Layering
Layering requires distinguishing between two categories of interfaces
Application Glass Box
Platform Glass Box
a2
servA
a1 b2 b1e1
e2
e3
e4
e5
servB
e6e7
servCe6
Implementation-independent (service) interfaces
Implementation-specific interfaces(service access points)
Page 29
© Copyright Malina Software29
The 3-Dimensional Component Model
―To understand the capabilities of a black-box component it is sufficient to know its interface‖
This may mean that we have to know its layer interfaces as well
Peer interfacePeer interface
Servce AccessPointsService AccessPoints
Page 30
© Copyright Malina Software30
Hardware
Link
Network
Level 4
Level 5
Level 6
Level 7
The Dimensions of Layering
In most systems, layering is a complex multidimensional relationship
Real systems cannot be described by a single vertical layer stack
Operatingsystem
Page 31
© Copyright Malina Software31
Failed Representations of Layering
Staircase model
Operating System
Application
General Services
Specialized Services
Toaster model
Page 32
© Copyright Malina Software32
Behavioural Pattern: Summary Message (1)
A high-level message abstracts a low-level protocol
Syntactically equivalent to the Cable pattern
Caller PhoneSystem
Initiate Call
Caller PhoneSystem
Off Hook
Dialtone
1st Digit
2nd Digit
Last Digit
...
Ringtone
abstraction
Page 33
© Copyright Malina Software33
Hybrid Pattern: Layered Communication
Combination of structural and behavioural patterns
Glass Box BGlass Box A
m'
a' b'
Glass Box m’
Connector Glass Box
abstraction
a1 a2 c1 b1b2c2
m1m2
m3
m6
m4m5
This connector is not shown in this diagram but is in the abstract model
Page 34
© Copyright Malina Software34
Behavioural Pattern: Summary State
Syntactically similar to the Black Box pattern
S1
S3
S4
S2
t2
t4
t5
t1
S5
t6
S1’
t1’S5’
AbsSt6’
Glass State
abstractionMay involve the Summary Message pattern
Page 35
© Copyright Malina Software35
Behavioural Pattern: Group Transition
Involves a Summary State pattern followed by a syntactical equivalent of the structural Cable pattern
S4
S1
t
S3
S2
t
t
e1
e2
e3
abstraction
S1’ S’e'
t'
Page 36
© Copyright Malina Software36
Behavioural Pattern: Summary Activity
Syntactical equivalent of Black Box
Glass Activity
A1 A2
A5
A4
A3
A6f1 f2
A1’ A6’AbsAf1’ f2’
abstraction
Page 37
© Copyright Malina Software37
Temporal Abstraction Patterns
For reducing the complexity of time
Not inherently graph based
Time Compression
Duration abstracted as an instant
Logical Time
Duration abstracted away entirely
Only time order is preserved
Discrete Time
Time discretized into equidistant intervals
Often combined with time compression: all behaviour is compressed to the instant when the current interval ends
Page 38
© Copyright Malina Software38
Summary
Abstraction is the primary tool for dealing with overwhelming complexity
With model-based engineering methods, we are taking greater advantage of the power of abstraction in software development…but, the actual process involved is rarely documented
Difficult to identify faulty abstractions and faulty refinements
…and difficult to reconstitute abstract views of an implemented system
A formalism for describing the abstraction process combined with a catalogue of widely used and proven abstraction patterns can help us mitigate and possibly eliminate these issues
Page 39
© Copyright Malina Software39
– THANK YOU –QUESTIONS, COMMENTS,
ARGUMENTS...