Lecture 12: Proto-OCL, Modularisation & Design Patterns - - PowerPoint PPT Presentation
Softwaretechnik / Software-Engineering Lecture 12: Proto-OCL, Modularisation & Design Patterns 2017-07-03 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universitt Freiburg, Germany 12 2017-07-03 main Topic
– 12 – 2017-07-03 – main –
Albert-Ludwigs-Universität Freiburg, Germany
– 12 – 2017-07-03 – Sblockcontent –
2/66
(i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Modelling structure a) (simplified) class diagrams b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) d) Unified Modelling Language (UML)
(i) modularity, separation of concerns (ii) information hiding and data encapsulation (iii) abstract data types, object orientation (iv) Design Patterns
(i) 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 . . . VL 14 . . .
– 12 – 2017-07-03 – Scontent –
3/66
Model-View-Controller.
– 12 – 2017-07-03 – main –
4/66
– 11 – 2017-06-26 – Sod –
39/51
{1C 7 {p 7 , n 7 {5C}}, 5C 7 {p 7 , n 7 }, 1D 7 {p 7 {5C}, x 7 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 .
– 12 – 2017-07-03 – main –
5/66
– 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 7 {p 7 , n 7 {c}}}, c 7 {p 7 , n 7 }, d 7 {p 7 {c}, x 7 23}} where c D(C), d D(D), c 6= 1C. Intuition: different boxes represent different objects.
– 12 – 2017-07-03 – Scontent –
6/66
Model-View-Controller.
– 12 – 2017-07-03 – main –
7/66
– 12 – 2017-07-03 – Socl –
8/66 C D A
c 0,1 a 0,1
All D-instances having a link to the same C object should have links to the same A.
: A : D : C : D : A a c c a
Note: formally, it is a proper system state.
∀ d1 ∈ allInstancesC • ∀ d2 ∈ allInstancesC • c(d1) = c(d2) = ⇒ a(d1) = a(d2)
– 12 – 2017-07-03 – Socl –
9/66
C
x : Int
∀ c ∈ allInstancesC • x(c) = 27
F ::= c : τC | allInstancesC : 2τC | v(F) : τC → τ⊥, if v : τ ∈ atr(C) | v(F) : τC → τD, if v : D0,1 ∈ atr(C) | v(F) : τC → 2τD, if v : D∗ ∈ atr(C) | f(F1, . . . , Fn) : τ1 × · · · × τn → τ, if f : τ1 × · · · × τn → τ | ∀ c ∈ F1 • F2 : τC × 2τC × B⊥ → B⊥
∀ c ∈ allInstancesC• = (x(c), 27)
– 12 – 2017-07-03 – Socl –
10/66
∪ {⊥}, Iτ⊥ = D(τ) ˙ ∪ {⊥}, I2τC = D(C∗) ˙ ∪ {⊥}
∪ {⊥}, IZ⊥ = Z ˙ ∪ {⊥}
(assuming β is a type-consistent valuation of the logical variables),
, if IF(σ, β) ∈ dom(σ) ⊥ , otherwise (if not v : C0,1)
, if IF(σ, β) = {u′} ⊆ dom(σ) ⊥ , otherwise (if v : C0,1)
true , if IF2(σ, β[c := u]) = true for all u ∈ IF1(σ, β) false , if IF2(σ, β[c := u]) = false for some u ∈ IF1(σ, β) ⊥ , otherwise
– 12 – 2017-07-03 – Socl –
11/66
x1 true true true false false false ⊥ ⊥ ⊥ x2 true false ⊥ true false ⊥ true false ⊥ ∧I(x1, x2) true false ⊥ false false false ⊥ false ⊥ We assume common logical connectives ¬, ∧, ∨, . . . with canonical 3-valued interpretation.
∪ {⊥}) × (Z ˙ ∪ {⊥}) → Z ˙ ∪ {⊥}
+I(x1, x2) =
, if x1 = ⊥ and x2 = ⊥ ⊥ , otherwise We assume common arithmetic operations −, /, ∗, . . . and relation symbols >, <, ≤, . . . with monotone 3-valued interpretation.
isUndefinedI(x) =
, if x = ⊥, false , otherwise isUndefinedI is definite: it never yields ⊥.
– 12 – 2017-07-03 – Socl –
12/66 σ : 1C : C x = 13
C
x : Int
∀ c ∈ allInstancesC • x(c) = 27
Note: = is a binary function symbol, 27 is a 0-ary function symbol.
I∀ c ∈ allInstancesC • =(x(c), 27)(σ, ∅) = true, because... I=(x(c), 27)(σ, β), β := ∅[c := 1C] = {c → 1C} = =I( Ix(c)(σ, β), I27(σ, β) ) = =I( σ( Ic(σ, β) )(x), 27I ) = =I( σ( β(c) )(x), 27I ) = =I( σ( 1C )(x), 27I ) = =I( 13, 27 ) = true
...and 1C is the only C-object in σ: IallInstancesC(σ, ∅) = {1C}.
– 12 – 2017-07-03 – Socl –
13/66 σ : 1C : C x = 13 |
n
C
x : Int
n 0..1
∀ c : allInstancesC • x(n(c)) = 27
Ix(n(c))(σ, β), β = {c → 1C}
Iv(F)(σ, β) =
, if IF(σ, β) ∈ dom(σ) and σ(IF(σ, β))(v) = {u′} ⊥ , otherwise (if v : C0,1)
Iv(F)(σ, β) =
, if IF(σ, β) ∈ dom(σ) ⊥ , otherwise (if not v : C0,1)
– 12 – 2017-07-03 – Socl –
13/66 σ : 1C : C x = 13 |
n
C
x : Int
n 0..1
∀ c : C • x(n(c)) = 27
σ ( σ( Ic(σ, β) )(n) ) (x)
by the following rule: Iv(F)(σ, β) =
, if IF(σ, β) = {u′} ⊆ dom(σ) ⊥ , otherwise (if v : C0,1)
– 12 – 2017-07-03 – Socl –
14/66
OCL is the same — just with less readable (?) syntax.
Literature: (OMG, 2006; Warmer and Kleppe, 1999).
– 12 – 2017-07-03 – Socl –
15/66
TeamMember name : String age : Integer name : String Location participants 2..* meetings * title : String numParticipants : Integer start : Date duration: Time Meeting move(newStart : Date) 1 *
context Meeting
inv: self.participants->size() = numParticipants
context Location
inv: name="Lobby" implies meeting->isEmpty()
– 12 – 2017-07-03 – Socl –
16/66
Date: May 2006
Object Constraint Language
OMG Available Specification Version 2.0
formal/06-05-01
– 12 – 2017-07-03 – Socl –
17/66
text text can principally be everything, in particular comments and constraints. Sometimes, content is explicitly classified for clarity:
OCL:
F
C
... ...
F
stands for C
... ...
∀ self ∈ allInstancesC • F
Type: d : D_* Constraint: forall c in AllInstances_C . size( d( c ) ) = 3 or size( d( c ) ) >= 17 and size( d( c ) ) <= 21
– 12 – 2017-07-03 – Scontent –
18/66
Model-View-Controller.
– 12 – 2017-07-03 – main –
19/66
– 12 – 2017-07-03 – Salltogether –
20/66
(finite or infinite) computation paths of the form σ0
α1
− → σ1
α2
− → σ2 · · · where
The (possibly partial) function · : S → S is called interpretation of S.
Σ := ΣD
S
S :
C
x : Int
27C : C x = 0
τ
− →
27C : C x = 1
τ
− →
27C : C x = 3
τ
− →
27C : C x = 4
τ
− → . . .
F = ∀ c ∈ allInstancesC • x(c) < 4 then S does not satisfy the requirement.
– 12 – 2017-07-03 – Salltogether –
21/66
S , and
= F, if and only if for all σ0
α1
− − → σ1
α2
− − → σ2 · · · ∈ S and all i ∈ N0, IF(σi, ∅) = true.
= F, if and only if there exists σ0
α1
− − → σ1
α2
− − → σ2 · · · ∈ S and i ∈ N0, such that IF(σi, ∅) = false.
= F) does not imply S | = F.
– 12 – 2017-07-03 – Sttwytt –
22/66
S .
S
S satisfies a Proto-OCL constraint F if and only
if F evaluates to true in all system states of all the software’s com- putation paths.
– 12 – 2017-07-03 – Scontent –
23/66
Model-View-Controller.
– 12 – 2017-07-03 – main –
24/66
– 10 – 2017-06-22 – Sdesintro –
39/60
System Software System Component Software Component Module Interface Component Interface
consists of 1 or more " is a is a may be a has i s a n
Software Architecture Architecture Architectural Description Design
software architecture — The software architecture of a program or computing system is the structure or structures of the system which comprise software elements, the externally visi- ble properties of those elements, and the relationships among them.
(Bass et al., 2003)
is an is described by is the result of
– 12 – 2017-07-03 – main –
25/66
– 10 – 2017-06-22 – Sdesintro –
40/60
Design...
(i) structures a system into manageable units (yields software architecture), (ii) determines the approach for realising the required software, (iii) provides hierarchical structuring into a manageable number of units at each hierarchy level.
Oversimplified process model “Design”:
req. design design arch. designer
design
module spec. impl. impl. code programmer
implementation
– 12 – 2017-07-03 – main –
26/66
– 12 – 2017-07-03 – main –
27/66
– 12 – 2017-07-03 – Sdesprinc –
28/66
1.) Modularisation
2.) Separation of Concerns
functionality and interaction
3.) Information Hiding
which realise the component’s interface
4.) Data Encapsulation
instead of accessing data (variables, files, etc.) directly → many programming languages and systems offer means to enforce (some of) these principles technically; use these means.
– 12 – 2017-07-03 – Sdesprinc –
29/66 modular decomposition — The process of breaking a system into compo- nents to facilitate design and development; an element of modular program- ming.
IEEE 610.12 (1990)
modularity — The degree to which a system or computer program is com- posed of discrete components such that a change to one component has minimal impact on other components.
IEEE 610.12 (1990)
information on the implementation of other modules should not be necessary. The other modules should not be affected by implementation exchanges.
do not require modifications of the module interface.
As long as the interface does not change, it should be possible to test old and new versions of a module together.
– 12 – 2017-07-03 – Sdesprinc –
30/66
thus hard to understand and maintain.
into classes,
(features) like printing are realised as separate components,
components,
Example: logical flow of (logical) messages in a communication protocol (functional)
a certain technology (technical).
functionality to own components.
Example: different networking technology (wireless, etc.)
to need extensions or changes later to own components.
interaction
Example: most prominently graphical user interfaces (GUI), also file input/output
– 12 – 2017-07-03 – Sdesprinc –
31/66
One should also consider accessibility.
information hiding— A software development technique in which each module’s inter- faces reveal as little as possible about the module’s inner workings, and other modules are prevented from using information about the module that is not in the module’s in- terface specification. IEEE 610.12 (1990)
(e.g., how data is stored and accessed, how operations are implemented). In other words: information hiding is about making explicit for one component which data or operations other components may use of this component.
as long as the visible behaviour stays the same (e.g. the employed sorting algorithm). IOW: other components cannot (unintentionally) depend on details they are not supposed to.
– 12 – 2017-07-03 – Sdesprinc –
32/66
a component which offers operations to access (read, write, etc.) the data.
Real-World Example: Users do not write to bank accounts directly, only bank clerks do.
– 12 – 2017-07-03 – Sdesprinc –
32/66
a component which offers operations to access (read, write, etc.) the data.
Real-World Example: Users do not write to bank accounts directly, only bank clerks do.
– 12 – 2017-07-03 – Sdesprinc –
32/66
a component which offers operations to access (read, write, etc.) the data.
Real-World Example: Users do not write to bank accounts directly, only bank clerks do.
usually come at the price of worse efficiency.
than calling an operation to provide the value: there is an overhead of one operation call.
Example: if a sequence of data items is stored as a singly-linked list, accessing the data items in list-order may be more efficient than accessing them in reverse order by position. Good modules give usage hints in their documentation (e.g. C++ standard library). Example: if an implementation stores intermediate results at a certain place, it may be tempting to “quickly” read that place when the intermediate results is needed in a different context. → maintenance nightmare — If the result is needed in another context, add a corresponding operation explicitly to the interface.
Yet with today’s hardware and programming languages, this is hardly an issue any more; at the time of (Parnas, 1972), it clearly was.
– 12 – 2017-07-03 – Sdesprinc –
33/66
program evolution,
encapsulated data
– 12 – 2017-07-03 – Scontent –
34/66
Model-View-Controller.
– 12 – 2017-07-03 – main –
35/66
– 12 – 2017-07-03 – Sarch –
36/66
many clever, proved and tested designs
architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
Buschmann et al. (1996)
– 12 – 2017-07-03 – Sarch –
37/66 architectural pattern — An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
Buschmann et al. (1996)
(construction, extendibility, communication, dependencies, etc.),
thus is typically a central and fundamental design decision.
is used in a given software can
– 12 – 2017-07-03 – main –
38/66
– 12 – 2017-07-03 – Slayered –
39/66
A layer whose components only interact with components
A protocol-based layer hides all layers beneath it and defines a protocol which is (only) used by the layers directly above.
data packets frames bits
– 12 – 2017-07-03 – Slayered –
40/66
GNOME etc. Applications GTK+ GDK ATK Cairo GLib GIO Pango
– 12 – 2017-07-03 – Slayered –
40/66
GNOME etc. Applications GTK+ GDK ATK Cairo GLib GIO Pango
– 12 – 2017-07-03 – Slayered –
41/66
Desktop Host
presentation tier
Application Server
(business) logic tier data tier
Database Server
DBMS (Ludewig and Lichter, 2013)
user interface; presents information obtained from the logic layer to the user, controls interaction with the user, i.e. requests actions at the logic layer ac- cording to user inputs.
core system functionality; layer is designed without information about the presentation layer, may only read/write data according to data layer interface.
persistent data storage; hides information about how data is organised, read, and written, offers par- ticular chunks of information in a form useful for the logic layer.
– 12 – 2017-07-03 – Slayered –
42/66
data packets frames bits GNOME etc. Applications GTK+ GDK ATK Cairo GLib GIO Pango
Desktop Host
presentation tier
Application Server
(business) logic tier data tier
Database Server
DBMS (Ludewig and Lichter, 2013)
– 12 – 2017-07-03 – main –
43/66
– 12 – 2017-07-03 – Spipe –
44/66
Example: Compiler
lexical analysis (lexer) syntactical analysis (parser) semantical analysis code generation ASCII Tokens AST dAST
Sourcecode Objectcode Errormessages
– 12 – 2017-07-03 – Spipe –
44/66
Example: Compiler
lexical analysis (lexer) syntactical analysis (parser) semantical analysis code generation ASCII Tokens AST dAST
Sourcecode Objectcode Errormessages
Example: UNIX Pipes ls -l | grep Sarch.tex | awk ’{ print $5 }’
if the format is changed, or need to employ (costly) conversions.
– 12 – 2017-07-03 – main –
45/66
– 12 – 2017-07-03 – Smvc –
46/66
controller view model
sees uses change of visualisation manipulation
notification of updates access to data
https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5
– 12 – 2017-07-03 – Smvc –
46/66
controller view model
sees uses change of visualisation manipulation
notification of updates access to data
https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5
– 12 – 2017-07-03 – Smvc –
46/66
controller view model
sees uses change of visualisation manipulation
notification of updates access to data
https://commons.wikimedia.org/wiki/File:Maschinenleitstand_KWZ.jpg Dergenaue, CC-BY-SA-2.5
added and removed at runtime;
up-to-date in all views;
– 12 – 2017-07-03 – main –
47/66
– 12 – 2017-07-03 – Sdespat –
48/66
Design patterns ... are descriptions of communicating objects and classes that are cus- tomized to solve a general design problem in a particular context. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. (Gamma et al., 1995)
– 12 – 2017-07-03 – Sttwytt2 –
61/66
– 12 – 2017-07-03 – main –
62/66
– 12 – 2017-07-03 – main –
63/66
Alexander, C. (1979). The Timeless Way of Building. Oxford University Press. Alexander, C., Ishikawa, S., and Silverstein, M. (1977). A Pattern Language – Towns, Buildings, Construction. Oxford University Press. Booch, G. (1993). Object-oriented Analysis and Design with Applications. Prentice-Hall. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, E., and Stal, M. (1996). Pattern-Oriented Software Architecture – A System of Patterns. John Wiley & Sons. Dobing, B. and Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5):109–114. Gamma, E., Helm, R., Johnsson, R., and Vlissides, J. (1995). Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274. 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 (1990). IEEE Standard Glossary of Software Engineering Terminology. Std 610.12-1990. Jacobson, I., Christerson, M., and Jonsson, P. (1992). Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley. JHotDraw (2007). http://www.jhotdraw.org. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. Nagl, M. (1990). Softwaretechnik: Methodisches Programmieren im Großen. Springer-Verlag. 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. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Commun. ACM, 15(12):1053–1058. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1990). Object-Oriented Modeling and Design. Prentice Hall. Warmer, J. and Kleppe, A. (1999). The Object Constraint Language. Addison-Wesley. Züllighoven, H. (2005). Object-Oriented Construction Handbook - Developing Application-Oriented Software with the Tools and Materials Approach. dpunkt.verlag/Morgan Kaufmann.
– 12 – 2017-07-03 – Scontent –
64/66
Model-View-Controller.
– 12 – 2017-07-03 – Sumloutlook –
65/66
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
– 12 – 2017-07-03 – Sumloutlook –
65/66
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
http://wikimedia.org (CC nc-sa 3.0, User:AutumnSnow) http://wikimedia.org (CC nc-sa 3.0, User:AutumnSnow)
– 12 – 2017-07-03 – Sumloutlook –
65/66
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
http://wikimedia.org (Public domain, Johannes Fasolt)
– 12 – 2017-07-03 – Sumloutlook –
65/66
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
(Jacobson et al., 1992)
use case model domain
model analysis model design model
class...
implementation model
...
testing model
may be expressed in terms of structured by realized by implemented by tested in
Each “persuasion” selling books, tools, seminars...
– 12 – 2017-07-03 – Sumloutlook –
65/66
— Idea: learn from engineering disciplines to handle growing complexity.
Modelling languages: Flowcharts, Nassi-Shneiderman, Entity-Relation Diagrams
— Inflation of notations and methods, most prominent:
(Rumbaugh et al., 1990)
(Booch, 1993)
(Jacobson et al., 1992) Each “persuasion” selling books, tools, seminars...
Standards published by Object Management Group (OMG), “international, open membership, not-for-profit computer industry consortium”. Much criticised for lack of formality.
– 12 – 2017-07-03 – Sumloutlook –
66/66
Figure A.5 - The taxonomy of structure and behavior diagram
Diagram Structure Diagram Behavior Diagram Interaction Diagram Use Case Diagram Activity Diagram Composite Structure Diagram Class Diagram Component Diagram Deployment Diagram Sequence Diagram Interaction Overview Diagram Object Diagram State Machine Diagram Package Diagram Communication Diagram Timing Diagram
OCL
Dobing and Parsons (2006)