Lecture 11: Structural Software Modelling 2017-06-26 Prof. Dr. - - PowerPoint PPT Presentation
Softwaretechnik / Software-Engineering Lecture 11: Structural Software Modelling 2017-06-26 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universitt Freiburg, Germany 11 2017-06-26 main Topic Area Architecture
– 11 – 2017-06-26 – main –
2017-06-26
Albert-Ludwigs-Universität Freiburg, Germany
– 11 – 2017-06-26 – Sblockcontent –
2/51
(i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Unified Modelling Language (UML) (iv) Modelling structure a) (simplified) class diagrams b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) (v) Principles of Design a) modularity b) separation of concerns c) information hiding and data encapsulation d) abstract data types, object orientation (vi) Modelling behaviour a) communicating finite automata b) Uppaal query language c) basic state-machines d) an outlook on hierarchical state-machines
VL 10 . . . VL 11 . . . VL 12 . . . VL 13 . . .
– 11 – 2017-06-26 – Scontent –
3/51
– 11 – 2017-06-26 – main –
4/51
– 10 – 2017-06-22 – Smodel –
45/60
piece of land.
have a door.
into living room.
have a window.
budget.
http://wikimedia.org (CC nc-sa 3.0, Ottoklages)
http://wikimedia.org (CC nc-sa 3.0, Bobthebuilder82)
Observation (1): Floorplan abstracts from certain system properties, e.g. ...
architects can efficiently work on appropriate level of abstraction
– 11 – 2017-06-26 – main –
5/51
– 10 – 2017-06-22 – Smodel –
45/60
piece of land.
have a door.
into living room.
have a window.
budget.
http://wikimedia.org (CC nc-sa 3.0, Ottoklages)
http://wikimedia.org (CC nc-sa 3.0, Bobthebuilder82)
Observation (2): Floorplan preserves/determines certain system properties, e.g.,
(such as windows). find design errors before building the system (e.g. bathroom windows)
– 11 – 2017-06-26 – main –
6/51
– 11 – 2017-06-26 – main –
7/51
– 10 – 2017-06-22 – Smodel –
43/60
A model is a concrete or mental image (Abbild) of something
Three properties are constituent: (i) the image attribute (Abbildungsmerkmal), i.e. there is an entity (called original) whose image or archetype the model is, (ii) the reduction attribute (Verkürzungsmerkmal), i.e. only those attributes of the original that are relevant in the modelling context are represented, (iii) the pragmatic attribute, i.e. the model is built in a specific context for a specific purpose.
– 11 – 2017-06-26 – main –
8/51
– 11 – 2017-06-26 – Sswmodel –
9/51 view — A representation of a whole system from the perspective of a related set of concerns.
IEEE 1471 (2000)
viewpoint — A specification of the conventions for constructing and using a view. A pat- tern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
IEEE 1471 (2000)
– 11 – 2017-06-26 – Sswmodel –
10/51
Logical View Development View Process View Physical View Scenarios
end-user functionality programmers, software management integrators, performance, scalability system engineers, topology, communication
Newer proposals (Ludewig and Lichter, 2013): system view: how is the system under development integrated into (or seen by) its environment; with which other systems (including users) does it interact how. static view (∼ developer view): components of the architecture, their interfaces and relations. Possibly: assignment of development, test, etc.
dynamic view (∼ process view): how and when are components instantiated and how do they work together at runtime. deployment view (∼ physical view): how are component instances mapped onto infrastructure and hardware units.
“Purpose of architecture: support functionality; functionality is not part of the architecture.” ?!
– 11 – 2017-06-26 – Sswmodel –
11/51
http://products.bosch-mobility-solutions.com/en/de/driving_safety/ driving_safety_systems_for_commercial_vehicles/electronic_systems_1/ electronic_systems_3.html — Robert Bosch GmbH
Example: modern cars
For, e.g., a simple smartphone app, process and physical view may be trivial or determined by the employed framework (→ later) — so no need for (extensive) particular documentation.
– 11 – 2017-06-26 – Sswmodel –
12/51
finite) set S of (finite or infinite) computation paths of the form σ0
α1
− − → σ1
α2
− − → σ2 · · · where
The (possibly partial) function · : S → S is called inter- pretation of S.
structure of S
behaviour of S (Harel, 1997) proposes to distinguish constructive and reflective descriptions
“constructs [of description] contain information needed in executing the model or in translating it into executable code.” → how things are computed.
“[description used] to derive and present views of the model, statically or during execution,
→ what should (or should not) be computed. Note: No sharp boundaries! (would be too easy...)
– 11 – 2017-06-26 – Sswmodel –
13/51
(Σ × A)ω
Analyst
Tron Joystick? ... Keyboard? Control Player colour score direction speed Gameplay Render OpenGL? ... aalib? AI? Segment x0, y0 x1, y1 colour Engine areawidth areaheight
1..∗ notify update 0..∗ head world 1..∗Main External inputs
Game Logic
(Physics) Engine
Output
notify update ? ?
e s resigned
X/
LSC: name AC: true AM: invariant I: permissive User Game
– 11 – 2017-06-26 – Sblockcontent –
15/51
(i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Unified Modelling Language (UML) (iv) Modelling structure a) (simplified) class diagrams b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) (v) Principles of Design a) modularity b) separation of concerns c) information hiding and data encapsulation d) abstract data types, object orientation (vi) Modelling behaviour a) communicating finite automata b) Uppaal query language c) basic state-machines d) an outlook on hierarchical state-machines
VL 10 . . . VL 11 . . . VL 12 . . . VL 13 . . .
– 11 – 2017-06-26 – Scontent –
16/51
– 11 – 2017-06-26 – main –
17/51
... so, off to “ ‘technological paradise’ where [...] everything happens according to the blueprints”.
(Kopetz, 2011; Lovins and Lovins, 2001)
– 11 – 2017-06-26 – main –
18/51
– 11 – 2017-06-26 – Sumlsig –
19/51
C
v1 : T1 . . . vn : Tn f1(T1,1, . . . , T1,n1) : T1,0 . . . fm(Tm,1, . . . , Tm,nm) : Tm,0
D
class class name typed attributes typed methods attributes compartment methods compartment where
– 11 – 2017-06-26 – Sumlsig –
20/51 C
n : C∗ p : C0,1
D
x : Int p : C0,1 f(Int) : Bool get_x() : Int x : Int p : C0,1
Alternative notation for C0,1 and C∗ typed attributes:
C D
x : Int f(Int) : Bool get_x() : Int
0..1 ×
0..1 ×
0..∗ ×
Alternative lazy notation for alternative notation:
C D
x : Int f(Int) : Bool get_x() : Int p 0..1 p 0..1 n 0..∗
And nothing else! This is the concrete syntax of class diagrams for the scope of the course.
– 11 – 2017-06-26 – Sumlsig –
21/51
S = (T, C, V, atr , F, mth) where
Note: Inspired by OCL 2.0 standard OMG (2006), Annex A.
– 11 – 2017-06-26 – Sumlsig –
22/51
S = (T, C, V, atr , F, mth) where
S0 = ({Int, Bool}, {C, D}, {x : Int, p : C0,1, n : C∗}, {C → {p, n}, D → {p, x}}, {f : Int → Bool, get_x : Int}, {C → ∅, D → {f, get_x}})
– 11 – 2017-06-26 – Sumlsig –
23/51 C D
x : Int f(Int) : Bool get_x() : Int
p 0..1 p 0..1 n 0..∗
S = (T, C, V, atr , F, mth)
– 11 – 2017-06-26 – Sumlsig –
24/51
S0 = ({Int, Bool}, {C, D}, {x : Int, p : C0,1, n : C∗}, {C → {p, n}, D → {p, x}}, {f : Int → Bool, get_x : Int}, {C → ∅, D → {f, get_x}})
C
n : C∗ p : C0,1
D
x : Int p : C0,1 f(Int) : Bool get_x() : Int x : Int p : C0,1
C D
x : Int f(Int) : Bool get_x() : Int
0..1 ×
0..1 ×
0..∗ × C D
x : Int f(Int) : Bool get_x() : Int
p 0..1 p 0..1 n 0..∗ D
x : Int f(Int) : Bool get_x() : Int
C p 0..1 p 0..1 n 0..∗ C
n : C∗ p : C0,1
D
x : Int p : C0,1 f(Int) : Bool get_x() : Int x : Int p : C0,1
C D
x : Int f(Int) : Bool get_x() : Int
p 0..1 p 0..1 n 0..∗
– 11 – 2017-06-26 – main –
25/51
– 11 – 2017-06-26 – Scdatwork –
26/51
provide rules which map (parts of) the code to class diagram elements.
1
package pac ;
2 3
import pac .D;
4 5
public c lass C {
6 7
public D n ;
8 9
public void print_nx ( ) {
10
System . out . p r i n t f (
11
"%i \n" , n . get_x ( ) ) ; } ;
12 13
public C ( ) { } ;
14
}
1
package pac ;
2 3
import pac . C ;
4 5
public c lass D {
6 7
private int x ;
8 9
public int get_x ( )
10
{ return x ; } ;
11 12
public D ( ) { } ;
13
}
pac
C
print_nx(); C();
D
x : int get_x() : int; D(); n 0..1
– 11 – 2017-06-26 – Scdatwork –
27/51
– 11 – 2017-06-26 – Scdatwork –
28/51
Tron Joystick? ... Keyboard? Control Player
colour score direction speed
Gameplay Render OpenGL? ... aalib? AI? Segment
x0, y0 x1, y1 colour
Engine
areawidth areaheight
1..∗ notify update 0..∗ head world 1..∗
→ show only the most relevant classes and attributes (for the given purpose).
→ use multiple class diagrams with a manageable number of classes for different purposes.
– 11 – 2017-06-26 – Scdatwork –
29/51
(Ambler, 2005)
– 11 – 2017-06-26 – main –
30/51
– 11 – 2017-06-26 – Sumlstruc –
31/51
S = (T, C, V, atr , F, mth) is a domain function D which assigns to each type a domain, i.e.
∀ C, D ∈ C : C = D → D(C) ∩ D(D) = ∅,
We use D(C ) to denote
C∈C D(C); analogously D(C∗).
Note: We identify objects and object identities, because both uniquely determine each other (cf. OCL 2.0 standard).
– 11 – 2017-06-26 – Sumlstruc –
32/51
Wanted: a structure for signature S0 = ({Int, Bool}, {C, D}, {x : Int, p : C0,1, n : C∗}, {C → {p, n}, D → {p, x}}, {f : Int → Bool, get_x : Int}, {C → ∅, D → {f, get_x}})
A structure D maps
D(Int) = Z D(C) = N+ × {C} ∼ = {1C, 2C, 3C, ...} D(D) = N+ × {D} ∼ = {1D, 2D, 3D, ...} D(C0,1) = D(C∗) = 2D(C) D(D0,1) = D(D∗) = 2D(D)
– 11 – 2017-06-26 – Sumlstruc –
33/51
A system state of S wrt. D is a type-consistent mapping σ : D(C ) (V (D(T ) ∪ D(C∗))). That is, for each u ∈ D(C), C ∈ C , if u ∈ dom(σ)
We call u ∈ D(C ) alive in σ if and only if u ∈ dom(σ). We use ΣD
S to denote the set of all system states of S wrt. D.
– 11 – 2017-06-26 – Sumlstruc –
34/51 S0 = ({Int, Bool}, {C, D}, {x : Int, p : C0,1, n : C∗}, {C → {p, n}, D → {p, x}}, {f : Int → Bool, get_x : Int}, {C → ∅, D → {f, get_x}}) D(Int) = Z, D(C) = {1C, 2C, 3C, ...}, D(D) = {1D, 2D, 3D, ...} A system state is a partial function σ : D(C ) (V (D(T ) ∪ D(C∗))) such that
– 11 – 2017-06-26 – Scontent –
35/51
– 11 – 2017-06-26 – main –
36/51
– 11 – 2017-06-26 – Sod –
37/51 S0 = ({Int, Bool}, {C, D}, {x : Int, p : C0,1, n : C∗}, {C → {p, n}, D → {p, x}}, {f : Int → Bool, get_x : Int}, {C → ∅, D → {f, get_x}}), D(Int) = Z
σ = {1C → {p → ∅, n → {5C}}}, 5C → {p → ∅, n → ∅}, 1D → {p → {5C}, x → 23}}
Concrete Syntax:
id : class v1 = d1 . . . vn = dn id : class r
mandatory
1C : C p = ∅ n = {1D} 5C : C p = ∅ n = ∅ 1D : D p = {1D} x = 23
This is an object diagram.
1C : C p = ∅ 5C : C p = ∅ n = ∅ 1D : D x = 23 n p
1C : C 5C : C 1D : D x = 23 n p | p | p | n
– 11 – 2017-06-26 – Sod –
38/51
Definition. Let σ ∈ ΣD
S be a system state and u ∈ dom(σ) an alive object of class C in σ.
We say r ∈ atr(C) is a dangling reference in u if and only if r : C0,1 or r : C∗ and u refers to a non-alive object via v, i.e. σ(u)(r) ⊂ dom(σ).
Example:
1C : C p = ∅ 5C : C X 1D : D x = 23 n p
– 11 – 2017-06-26 – Sod –
39/51
{1C → {p → ∅, n → {5C}}, 5C → {p → ∅, n → ∅}, 1D → {p → {5C}, x → 23}}
p = ∅ 5C : C p = ∅ n = ∅ 1D : D x = 23 n p
What about the other way round...?
1C : C 5C : C 1D : D x = 23 n
1C : C 5C : C 1D : D
→ we may omit information.
1C : C p = ∅ 5C : C p = ∅ n = ∅ 1D : D x = 23 n p
then we can uniquely reconstruct a system state σ.
– 11 – 2017-06-26 – Sod –
40/51
If the object diagram
1C : C p = ∅ : C p = ∅ n = ∅ : D x = 23 n p
is considered as complete, then it denotes the set of all system states {1C → {p → ∅, n → {c}}}, c → {p → ∅, n → ∅}, d → {p → {c}, x → 23}} where c ∈ D(C), d ∈ D(D), c = 1C. Intuition: different boxes represent different objects.
– 11 – 2017-06-26 – main –
41/51
– 11 – 2017-06-26 – Sodatwork –
42/51
BaseNode
parent : BaseNode∗ prevSibling : BaseNode∗ nextSibling : BaseNode∗ firstChild : BaseNode∗ lastChild : BaseNode∗
Node
data : T Node( data : T)
Iterator
Forest
appendTopLevel( data: T ) appendChild( parent : Iterator, data : T ) remove( it : Iterator ) depth( it : Iterator ) : int end() : Iterator begin() : Iterator empty() : bool size() : int
node begin_it end_it
– 11 – 2017-06-26 – Sodatwork –
43/51
: Iterator : Forest : Iterator A : Node E : Node end : BaseNode B : Node C : Node F : Node D : Node
begin_it end_it node node firstChild parent firstChild parent nextSib prevSib lastChild firstChild parent nextSib prevSib lastChild firstChild parent nextSib prevSib
BaseNode
parent : BaseNode∗ prevSibling : BaseNode∗ nextSibling : BaseNode∗ firstChild : BaseNode∗ lastChild : BaseNode∗
Node
data : T Node( data : T)
Iterator
Forest
appendTopLevel( data: T ) appendChild( parent : Iterator, data : T ) remove( it : Iterator ) depth( it : Iterator ) : int end() : Iterator begin() : Iterator empty() : bool size() : int
node begin_it end_it
– 11 – 2017-06-26 – Sodatwork –
44/51
: M ctime = 27 : N data = d1 : M ctime = 5 : N data = d2 : N data = d3 : N data = d4 : M ctime = 9 : N data = d5 | | | | |
– 11 – 2017-06-26 – Scontent –
45/51
– 11 – 2017-06-26 – Sttwytt –
49/51
(together with a structure D)
S .
S
– 11 – 2017-06-26 – main –
50/51
– 11 – 2017-06-26 – main –
51/51
Ambler, S. W. (2005). The Elements of UML 2.0 Style. Cambridge University Press. Booch, G. (1993). Object-oriented Analysis and Design with Applications. Prentice-Hall. Dobing, B. and Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5):109–114. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274. Harel, D. (1997). Some thoughts on statecharts, 13 years later. In Grumberg, O., editor, CAV, volume 1254 of LNCS, pages 226–231. Springer-Verlag. Harel, D., Lachover, H., et al. (1990). Statemate: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering, 16(4):403–414. IEEE (2000). Recommended Practice for Architectural Description of Software-Intensive Systems. Std 1471. Jacobson, I., Christerson, M., and Jonsson, P. (1992). Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley. Kopetz, H. (2011). What I learned from Brian. In Jones, C. B. et al., editors, Dependable and Historic Computing, volume 6875 of
Kruchten, P. (1995). The “4+1” view model of software architecture. IEEE Software, 12(6):42–50. Lovins, A. B. and Lovins, L. H. (2001). Brittle Power - Energy Strategy for National Security. Rocky Mountain Institute. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. OMG (2006). Object Constraint Language, version 2.0. Technical Report formal/06-05-01. OMG (2007). Unified modeling language: Superstructure, version 2.1.2. Technical Report formal/07-11-02. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1990). Object-Oriented Modeling and Design. Prentice Hall. Schumann, M., Steinke, J., Deck, A., and Westphal, B. (2008). Traceviewer technical documentation, version 1.0. Technical report, Carl von Ossietzky Universität Oldenburg und OFFIS.