Abstraction Patterns in Model-Based Engineering

Size: px

Start display at page:

Download "Abstraction Patterns in Model-Based Engineering"

Solomon Atkinson
5 years ago
Views:

1 Abstraction Patterns in Model-Based Engineering Bran Selic Malina Software Corp., Canada Zeligsoft (2009) Ltd., Canada Simula Research Labs, Norway University of Toronto, Canada Carleton University, Canada

2 What is Abstraction? A human defence mechanism for coping with overwhelming complexity Often, it is our only mechanism for dealing with complexity SYSTEM 2

3 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? 3

4 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) 4

5 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 5

essential properties of interest for a given set of concerns We don

6 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 everything at once What we do see is adjusted to human understanding 6

7 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) 7

8 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 8

9 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! 9

10 What About Software Modeling? PH reached X start Current PH Monitor PH Control PH stop Raise PH Input valve control bubbles and arrows, as opposed to programs, never crash -- B. Meyer UML: The Positive Spin American Programmer,

11 The Prevalent Attitude to Modeling We don t do modeling here...it s a waste of time But... 11

$start «sc_method» producer out1 producer void generate_data() {for (int i=0; i<10; i++) {out1 = i;}} producer NotStarted start Started refine NotStarted start /generate_data( )$

12 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! start «sc_method» producer out1 producer void generate_data() {for (int i=0; i<10; i++) {out1 = i;}} producer NotStarted start Started refine NotStarted start /generate_data( ) Started St1 St2 12

A Unique Feature of Software A software model and the software being modeled share

versatile automation technology Software has the unique property that it allows us

13 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 13

The Model-Based Engineering (MBE) Approach An approach to system and

Based on two time-proven ideas: (1) ABSTRACTION (2) AUTOMATION S1

e2/action2 e1/action1 S2 S3 e2/action2 Realm of tools switch (state) {

break; case 3:action3; newstate( 1 ); break;} switch (state) { break;

14 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: (1) ABSTRACTION (2) AUTOMATION S1 e3/action3 S1 e3/action3 Realm of modeling languages e1/action1 S2 S3 e2/action2 e1/action1 S2 S3 e2/action2 Realm of tools switch (state) { case 1:action1; newstate( 2 ); break; case 2:action2; newstate( 3 ); break; case 3:action3; newstate( 1 ); break;} switch (state) { case 1:action1; newstate( 2 ); break; case 2:action2; newstate( 3 ); break; case 3:action3; newstate( 1 ); break;} 14

$producer void generate_data() {for (int i=0; i<10; i++) {out1 = i;}} NotStarted start Started St1 St2 /generate_data( )$ The computer offers a uniquely capable abstraction device: Software can be represented from any desired viewpoint at any

The computer offers a uniquely capable abstraction device: Software can be represented from any desired viewpoint at any

15 But, if the Model is the System do we not lose the abstraction value of models? producer void generate_data() {for (int i=0; i<10; i++) {out1 = i;}} NotStarted start Started St1 St2 /generate_data( ) The computer offers a uniquely capable abstraction device: Software can be represented from any desired viewpoint at any desired level of abstraction The abstraction is inside the system and can be extracted automatically Provided that the abstraction process is tracked and recorded 15

16 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 refinement Implementation (L0) Model 16

17 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 Level N Model Level N-1 Model... abstraction refinement abstraction refinement Implementation (L0) Model 17

18 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 18

A Useful Formalism: Featured Graphs Nodes: structural or

..} p 1 1 {f 1 1, f 1 2,...} e 12 {f 12 1, f 12 2,.

<Nodes, Edges> n Nodes; n = <id, Ftrs(n), Pins(n)> e Edges;

19 A Useful Formalism: Featured Graphs Nodes: structural or behavioural components n 1 p 1 3 p 2 1 n 2 {f 2 1, f 2 2,...} p 1 1 {f 1 1, f 1 2,...} e 12 {f 12 1, f 12 2,...} p 2 2 p 1 2 Features: fine-grained attributes e 13 {f 23 1, f 23 2,...} Edges: information flows, communication channels FG = <Nodes, Edges> n Nodes; n = <id, Ftrs(n), Pins(n)> e Edges; e = <id, Ftrs(e), Srcs(e), Dests(e)> p 3 1 p 3 2 n 3 {f 3 1, f 3 2,...} p 3 3 Pins: connection points (e.g., ports, pins) 19

20 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 AbsGraph element and a corresponding RefGraph element refelem RefGraph mapping Mappings mapping = <abselem, refelem> abselem AbsGraph Each refgraph element is covered by a mapping to ensure that nothing is overlooked 20

high-level component Cross-over connectors map to a port-connector combination cx1 e 1 Glass Box gb' p 1 p 2 c2 e

21 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 Cross-over connectors map to a port-connector combination cx1 e 1 Glass Box gb' p 1 p 2 c2 e 2 abstraction cx2 Everything fully inside the box maps to a single abstract component cx1 e 1 c1 e p 1 c3 2 p 2 cx2 c4 21

Structural Pattern: Black Line Abstracts a collection of elements realizing a communications path into a single edge (connector) Could be multipoint Cross-over connectors

22 Structural Pattern: Black Line Abstracts a collection of elements realizing a communications path into a single edge (connector) Could be multipoint Cross-over connectors map to connector end points A B abstraction Everything fully inside the box maps to a single abstract connector Connector Glass Box e A 1 e C1 2 e C2 3 C3 e 4 C4 e 5 B 22

connector AbsCmp1 e' abstraction AbsCmp2

23 Structural Pattern: Cable Group of connectors between that share the same source and sink components All concrete connectors map to a single high-level connector AbsCmp1 e' abstraction AbsCmp2 Apply Pattern RefCmp1 e 1 e 2 e 3... RefCmp2 e n 23

24 Structural Pattern: Port Group Multiple concrete ports (possibly different types) merged into a single abstract port Often combined with Cable pattern AbsCmp p' abstraction p 1 RefCmp p 2 p 3... p n 24

25 A Common Structural Pattern: Layering What does it actually mean? Caster Blooper Geezer Super Framework Glooger Sneezer Dooper Framework Bizbaz FOO POO PURR RUF GRUMP 25

Platform Layering Distinguishing characteristics Upper layer:

potentially shared services used to implement the upper layer =

the platform layer for their implementation Application 1

.. File System Multitasking System IPC System.

26 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 Application 1 Application 2 a11 a12 a21 a22... File System Multitasking System IPC System... Operating Platform System Lower layer entities do not depend on the upper layer entities, but do participate in their implementation 26

Structural Pattern: Platform Layering A composition of multiple

(usually not shown) e' app plat Black Box pattern Black Box

platform layers components abstraction Application Glass Box a1

27 Structural Pattern: Platform Layering A composition of multiple pattern applications Cable pattern for cross-over connectors (usually not shown) e' app plat Black Box pattern Black Box pattern for application and for application and platform platform layers components abstraction Application Glass Box a1 e 1 a2 b2 e 5 b1 e 7 e 2 e 4 e 6 serva e 6 servc e3 servb Platform Glass Box 27

The Semantics of Layering Layering requires

(service) interfaces Application Glass Box a1 e 1

28 The Semantics of Layering Layering requires distinguishing between two categories of interfaces Implementationspecific interfaces (service access points) Implementationindependent (service) interfaces Application Glass Box a1 e 1 a2 b2 e 5 b1 e 7 e 2 e 4 e 6 serva e 6 servc e3 servb Platform Glass Box 28

29 The 3-Dimensional Component Model Peer interface Service Servce Access Points 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 29

be described by a single vertical layer stack Level 7

30 The Dimensions of Layering In most systems, layering is a complex multidimensional relationship Real systems cannot be described by a single vertical layer stack Level 7 Level 6 Level 5 Level 4 Network Link Hardware Operating system 30

31 Failed Representations of Layering Staircase model Toaster model Application Specialized Services General Services Operating System 31

32 Behavioural Pattern: Summary Message (1) A high-level message abstracts a low-level protocol Syntactically equivalent to the Cable pattern Caller Phone System Initiate Call abstraction Caller Phone System Off Hook Dialtone 1 st Digit 2 nd Digit... Last Digit Ringtone 32

diagram but is in the abstract model abstraction Glass Box A

33 Hybrid Pattern: Layered Communication Combination of structural and behavioural patterns a' m' b' This connector is not shown in this diagram but is in the abstract model abstraction Glass Box A Connector Glass Box Glass Box B a1 a2 c1 c2 b2 b1 m1 m2 m3 m6 m4 m5 Glass Box m 33

34 Behavioural Pattern: Summary State Syntactically similar to the Black Box pattern t6 S5 t1 S1 AbsS May involve the Summary Message pattern S1 abstraction t1 S2 t5 S5 t2 t6 S3 t4 S4 Glass State 34

35 Behavioural Pattern: Group Transition Involves a Summary State pattern followed by a syntactical equivalent of the structural Cable pattern t' S1 S e' abstraction t e1 S2 S1 t e2 S3 t e3 S4 35

36 Behavioural Pattern: Summary Activity Syntactical equivalent of Black Box f1 AbsA f2 A1 A6 abstraction Glass Activity A3 A1 f1 A2 f2 A6 A4 A5 36

37 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 37

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

38 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 38

39 THANK YOU QUESTIONS, COMMENTS, ARGUMENTS... 39

Modeling Software Architectures with UML 2

Modeling Software Architectures with UML 2 Bran Selic IBM Distinguished Engineer IBM Canada 2006 IBM Corporation Outline IBM Rational Software On Software Architecture and MDD Requirements for Modeling