Seamless Model Driven Development and Tool Support for Embedded Software-Intensive Systems

Transcription

1 Seamless Model Driven Development and Tool Support for Embedded Software-Intensive Systems Computer Journal Lecture - 22nd June 2009 Manfred Broy Technische Universität München Institut für Informatik D Munich, Germany

2 The role of modelling in software & systems engineering Software & systems engineering means capturing the requirements domain specific functional, logical, technical, methodological specification of the system s overall functionality design of a solution in terms of an architecture specifying the components implementing the components verification of the components and integrating them into the system and verifying the integration verification of the system further evolution These are complex error prone tasks! Manfred Broy 2

3 The role of modelling in software & systems engineering (S&SE) Modelling helps for: expressing and documenting the requirements specifying the system describing the architecture specifying the components their composition and interaction modelling the components verifying of the components and integrating them into the system and verifying the verifying the system further evolution Manfred Broy 3

4 The roots of modelling in S&SE Graphical description: Early approaches: SADT, Structured Analysis (SA) Later: SDL, ADLs, OOA/D, ROOM Today: UML, SysML Programming and programming languages Programming concepts: types (as basis for data models) Programming logics Object oriented programming concepts Formal description techniques as modelling concepts Predicate Logic Based Specification Abstract Data Types State Machines (Mealy,... ) Temporal Logic Process Algebras (CCS, CSP,... ) Models of distributed concurrent systems (Unity, TLA,... ) Manfred Broy 4

5 On models and modelling What is a model? An abstraction! What kind of models? Informal: language, informal diagrams,... Semiformal: formalized graphical or textual presentation languages Mathematical: in terms of mathematical theories Formal models: formalized syntax, semantics and logics How do we use models? for understanding - Gedankenmodell for specification, design and documentation for analysis, validation, simulation, verification, certification for generation of implementation, tests, for reuse Manfred Broy 5

6 What do we model Domain specific tautologies, ontologies, data models,... laws, rules, System specific data interface behaviour architecture state temporal... Technical Protocols CPUs... We concentrate on digital (discrete) models in the following Manfred Broy 6

7 Modelling and engineering Support of development processes support in various phases of development integrated support between phases of development Support of engineering principles levels of abstraction separation of concerns encapsulation modularity Tool support Manfred Broy 7

8 The five areas of modelling Mathematical Models Logical Theories Methodology Description Techniques Tools Manfred Broy 8

9 Informal requirements formalisation S Specification, Sverification, architecture... Requirements Engineering Validation Formalized system requirements in terms of service taxonomies architecture S1 S2 S3 S4 System delivery System verification R S Integration R = R1 R2 R3 R4 R1 R deliver R2 R4 R3 S1 Architecture design Architecture verification S S1 S2 S3 S4 S4 S2 S3 realization R1 integration R2 R4 R3 Component implementation verification R1 S1 R2 S2 R3 S3 R4 S4 Manfred Broy 9

10 Ingredients for Integration Coherent Theory Modelling (data/interface/state/interaction/architecture) Refinement Verification Consistent Terminology Tractable Description Techniques Formulas/Logics Diagrams/Graphics Tables Comprehensive Architecture Structuring Flexible Development Process Phases (Requirements/Design/Implementation/Test/Integration) Artefact Model (concept) Methods Process models Powerful Tools Artefact Model (tool support) Automation for documentation, analysis, verification, generation Manfred Broy 10

11 The Big Picture Tool Development Process Artefact Model Terminology Architecture Methods Description Techniques Theory Manfred Broy 11

12 What has to be modelled? Data states and their attributes messages, events, signals Requirements and specifcations Functional Nonfunctional - Quality Models System Architecture Structure Components/interfaces Hierarchy Hardware/Software/Deployment Software Architecture Modules Tasks Test Cases Development Processes Development Steps Refactoring Code generation Quality attributes Systems Manfred Broy 12

13 Abstraction Abstraction Towards a comprehensive theory of system modelling: meta model Abstraction Composition Refinement Time Feature model Interface model: components Input and output uses Implementation uses Composition Refinement Time Process transition model: Events, actions and causal relations Implementation State transition model: States and state machines uses Data model: Types/sorts and characteristic functions Is sub-feature Composition Refinement Time Hierarchy and architecture Composition Refinement Time Manfred Broy 13

14 What is a (discrete) system? A system has a scope a behavior a structure and distribution a black box view: an interface and an interface behaviour input and output via ports, channels, events, messages, signals a glass/white box view: architecture state and state transition quality profile Manfred Broy 14

15 Towards a uniform model: Basic system model component System class: distributed, reactive systems kc LM lc cl Control cr rc RM component name channel channel name System consists of named components (with local state) named channels driven by global, discrete clock Manfred Broy 15

16 Basic Model Timed Streams: Semantic Model for Black-Box-Behavior eq E qe Q Message set: M = {a, b, c,...} t t+1 t+2 t+3 infinite channel history <a,d,a,b> <> Messages transmitted at time t Manfred Broy 16

17 The Basic Behaviour Model: Streams and Functions C set of channels Type: C TYPE type assignment x : C (IN\{0} ) channel history for messages of type M r C or IH[C] set of channel histories for channels in C Manfred Broy 17

18 System interface model Channel: Identifier of Type stream I = { x 1, x 2,... } set of typed inpu t channels O = { y 1, y 2,... } set of typed outpu t channels Interface behavior f : I r r O x 1 : S 1 x n : S n Set of interfaces: IF[I O] M f M y 1 : T 1 y m : T m Manfred Broy 18

19 System interfaces (I O) syntactic interface with set of input channels I and of output channels O F : I r ( O r ) semantic interface for (I O) with timing prop erty addressing causality (let x, z I r, y O r, t IN): x t = z t {y t+1: y F(x)} = {y t+1: y F(z)} x t prefix of history x with t finite sequences A system is a total behavior I O Component interface Manfred Broy 19

20 Example: Component interface specification A transmission component TMC TMC in x: T out y: T x ~ y Spec name Input channel x:t Output channel x ~ y ( m T: {m} x = {m} y ) TMC x ~ y y:t Specifying assertion Manfred Broy 20

21 State model for systems/components Σ set of states, initial state σ Σ State transition function: State machine (infinite Moore automaton): (Δ, σ) Interface abstraction Abs : SM IF Δ: (Σ (I M * )) (Σ (O M * )) Abs(, ) = F wher e The state machine concept has to fit to the interface model F ( z ˆx) = { s ˆy: y F (x) ( ', s) (, z) } Set of all states machines: SM Manfred Broy 21

22 Composition and Decomposition of Systems F 1 IF[I 1 O 1 ] F 2 IF[I 2 O 2 ] I 1 \C 2 C F 1 1 F 2 O 2 \C 2 C 1 = O 1 I 2 C 2 = O 2 I 1 I = I 1 \C 2 I 2 \C 1 O = O 1 \C 1 O 2 \C 2 O 1 \C 1 C 2 I 2 \C 1 F 1 F 2 IF[I O], (F 1 F 2 ).x = {z O: x = z I z O 1 F 1 (z I 1 ) z O 2 F 2 (z I 2 )} Manfred Broy 22

23 Interface specification composition rule x1 F1 F2 F1 z12 F2 y2 y1 z21 x2 F1 in x1, z21: T out y1, z12: T P1 F2 in x2, z12: T out y2, z21: T P2 F1 F2 in x1, x2: T out y1, y2: T z12, z21: P1 P2 Manfred Broy 23

24 Composition of Specifications into Architectures Input channels Composed component spec in x 1 : M 1, x 2 : M 2,... out y 1 : N 1, y 2 : N 2,... Composed Component P 1 Output channels Internal channels x 1 : M 1 y 1 : N 1 c 1, c 2,... : P 1... P n c 1 : T 1 c 2 : T 2 P 3 P 2 P 4 y 2 : N 2 x 2 : M 2 y 2 : N 2 x 3 : M 3 System composition = logical und Channel Hiding = existential quantification Manfred Broy 24

25 An example of an essential property... Interface abstraction distributes for state machines over composition Abs((Δ1, σ1) (Δ2, σ2) ) = Abs((Δ1, σ1)) Abs((Δ2, σ2)) Manfred Broy 25

26 Vertical Refinement r r F: I ( Compositionality O ) of refinement is refined by a behavior k: F k -> IF F ˆ r r F ˆ : I ( O ) if we write x r I : ˆ F.x F.x F -> IF ˆ F ˆ F Manfred Broy 26

27 Levels of abstraction I F 1 O 1... A I I 2 O 2 abstract level R Property refinement O implies interaction refinement... F concrete level ˆ Compositionality of interaction refinement Given refinement pairs Refinement of State Machines Α Ι : I r 2 ( I r r Given two state machine (Δ k, Λ k ) for k := 1, 2 where Λ k is a set Λ k of pairs 1 )(σ R I : I r O 2 ( O r 0, y 0 ) and Δ k is a state transition function composition 1 ) R O : O r Δ k : (Σ k (I k M * )) (Σ k (O k M* )) we call Δ 2 a refinement of Δ 1 if there exists a mapping F ˆ r I r O abs: Σ 2 Σ 1 such that Theorems Interaction refinement distributes over Abstractions of interaction refinements of implementations are interaction refinements of abstractions r r I O Time abstraction is interaction abstraction Interaction abstraction is a Galois connection {(abs.σ, A O.y 0 ) : (σ 0, y 0 ) Λ 2 } Λ 1 F ˆ and for each reachable state σ Σ 2 of the state machine (Δ 2, Λ 2 ) we have B Δ2 (σ, y 0 ) A I Þ B Δ1(abs.σ, A O.y 0 ) Þ R O r I r O Manfred Broy 27

28 The comprehensive model Usage function hierarchy service taxonomy Logical architecture Technical architecture Software architecture conceptional architecture Tasks T1 T2 T3 T4... Deployment T1... T2... T3 T4... Hardware architecture Manfred Broy 28

29 The overall goal Provide a formal model for the comprehensive architecture and all of its views In this talk: concentration on the conceptional architecture The foundation The basic system model: components System specification and verification System composition Service taxonomy Logical architecture Relationship between service taxonomy and logical architecture Manfred Broy 29

30 A screen shot from AutoFocus Manfred Broy 30

31 What we got Formal notion of a system with input and output represented by a relation between input and output histories are specified by history assertions can be used as a component to form a large system can be de-composed into an architecture of components Formal notion of a service/feature/system function with input and output represented by a relation between input and output histories are specified by history assertions can be used as a sub-service to form a large system can be de-combined into an taxonomy of services Every component can be de-combined into its taxonomy of its sub-services the sub-services can be related by service dependency relations Manfred Broy 31

32 Concluding Remarks Today software & systems engineering is too much orientated towards the technical architecture and solutions/implemention in the beginning We need a comprehensive architectural model-based view onto systems including requirements for dealing with complex multi-functional systems The models allow for Separation of concerns Separation technical aspects from application aspects Technical architectures are modelled along the same theory Code and test cases can be generated from the models Manfred Broy 32