Seamless Model- and Method-Based Software & Systems Engineering Scientific Foundations Manfred Broy Technische Universität München Institut für Informatik D-80290 Munich, Germany
Challenges in Software & Systems Development • • Cost Terminology • Complexity • Modelling concepts ◊ Size ◊ artefacts ◊ Complex relationships • ◊ description techniques Systematic development ◊ semantic foundations ◊ Process • ◊ System quality Development methods • Key Challenges • Artefact models ◊ Requirements ◊ relationship between • Functional artefacts • Quality • Constraints • Tools ◊ Specification ◊ Automation • Functionality ◊ Architecture • Interfaces • Components ◊ Quality FOSE ETH Zürich November 2010 Manfred Broy 2
Perspectives • Front loading ◊ Emphasis on requirements, specification, and architecture ◊ Early quality control • Domain engineering ◊ Concentration on domain and use specific requirements ◊ Use case • Artefact orientation ◊ Document every development artefact in a repository ◊ Define relationships (tracing) and rules of consistency • Software & system evolution • Product line engineering ◊ Reuse ◊ Systematic generation of software FOSE ETH Zürich November 2010 Manfred Broy 3
Approach: foundations by theory Idea • develop theories in terms of mathematics and logics that capture • essential concepts in software & systems engineering • reflects the terminology • proves or disproves ideas and concepts • validates/verifies methods • can be the basis of automation • supports views ◊ abstraction ◊ structuring FOSE ETH Zürich November 2010 Manfred Broy 4
Systems: the model Systems • boundaries x 2 : T 2 x 3 : T 3 y 1 : T’ 1 • typed channels System y 2 : T’ 2 x 1 : T 1 I = { x 1 : T 1 , x 2 : T 2 , ...} O = { y 1 : T’ 1 , y 2 : T’ 2 , ...} x 4 : T 4 • syntactic interface y 3 : T’ 3 (I » O) y 4 : T’ 4 x 5 : T 5 • streams STREAM[T] = {IN → T*} • histories for channels set C IH[C] = {C → STREAM[T]} • interface behaviour [I » O] = {IH[I] → ℘ (IH[O])} FOSE ETH Zürich November 2010 Manfred Broy 5
Three levels of specification • System level requirements (functional requirements) ◊ a list of requirements in terms of system properties • System level functional specification ◊ a decomposition of the system functionality into a hierarchy of (sub-)functions ◊ a specification of the (sub-)functions by properties ◊ feature interactions specified via a mode concept • Architecture specification ◊ a decomposition of the system into a sub-systems (components) ◊ their connections via their sub-interfaces ◊ interface specification by interface properties FOSE ETH Zürich November 2010 Manfred Broy 6
Three levels of specification: examples • System level requirements (functional requirements) ◊ “the car must not accelerate its speed without users control” • System level functional specification ◊ “the acc (adaptive cruise control) accelerates the car up to the speed selected by the user, provided no obstacles are recognized in front” • Architecture specification ◊ “the radar signal based sensor measures the distance in m/s to the car in front and sends it to the acc monitor every 100 ms” FOSE ETH Zürich November 2010 Manfred Broy 7
Three levels of specification: logical model • System level requirements (functional requirements) R = ∧ {R i : 1 ≤ i ≤ n} • System level functional specification Q = ∧ {Q i : 1 ≤ i ≤ m} • Architecture specification P = ∧ {P i : 1 ≤ i ≤ k} • Correctness Functional specification: Q ⇒ R Architecture (let be m 1 , ... mode channels): P ⇒ ∃ m 1 , ... : Q FOSE ETH Zürich November 2010 Manfred Broy 8
System level requirements specification x 1 :T 1 y 1 :T’ 1 SysSpc ... ... x m :T m y n :T’ n The R i express functional requirements and are called interface assertions FOSE ETH Zürich November 2010 Manfred Broy 9
Example: System level requirements specification x:T FairMIX y:T z:T FOSE ETH Zürich November 2010 Manfred Broy 10
System level requirements • The system interface behaviour F is specified by the system requirements specification R = {R i : 1 ≤ i ≤ n} where the R i are interface assertions FOSE ETH Zürich November 2010 Manfred Broy 11
Functional view: Functional decomposition • The system interface behaviour F as specified by the system requirements specification R = {R i : 1 ≤ i ≤ n} is structured ◊ into a set of sub-interfaces for sub-functions F 1 , ... , F k ◊ that are specified independently by introducing a number of mode channels to capture feature interactions ◊ each F i sub-function is described by a syntactic interface and an interface assertion Q i such that ∧ {Q i : 1 ≤ i ≤ k} ⇒ R FOSE ETH Zürich November 2010 Manfred Broy 12
Sub-types between interfaces For syntactic interfaces (I ! O) and (I’ ! O’) where I’ subtype I and O’ subtype O we call (I’ " O’) a sub-type of (I ! O) and write: (I’ ! O’) subtype (I ! O) x 2 : T 2 x 3 : T 3 y 1 : T’ 1 y 2 : T’ 2 x 1 : T 1 x 4 : T 4 y 3 : T’ 3 y 4 : T’ 4 x 5 : T 5 FOSE ETH Zürich November 2010 Manfred Broy 13
Combination of sub-functions The combination of sub-functions F 1 ! IF[I 1 ! O 1 ], F 2 ! IF[I 2 ! O 2 ] into a super-function F 1 " F 2 ! IF[I 1 # I 2 ! O 1 # O 2 ] such that both F 1 and F 2 are a sub-functions of F 1 " F 2 FOSE ETH Zürich November 2010 Manfred Broy 14
Combining Functions Given two functions F 1 and F 2 in isolation We want to combine them into a function F 1 ⊕ F 2 FOSE ETH Zürich November 2010 Manfred Broy 15
Combining Functions Their isolated combination FOSE ETH Zürich November 2010 Manfred Broy 16
Combining Functions If the two services F 1 and F 2 have feature interaction we typically get: We explain the functional combination F 1 ⊗ F 2 as a refinement step FOSE ETH Zürich November 2010 Manfred Broy 17
Interface specification composition rule FOSE ETH Zürich November 2010 Manfred Broy 18
The steps of function combination Given the isolated function F 1 We construct a refinement F’ 1 And combine F’ 1 with a refinement F’ 2 of F 2 FOSE ETH Zürich November 2010 Manfred Broy 19
Applying projections - functional slicing • identifying sub-functions - functional slicing • identifying sub-interface behaviour • Given some behaviour F ∈ [I » O] a set of behaviours F k ∈ [I’ k » O’ k ] with [I k » O k ] subtype [I’ k » O’ k ] I = ∪ { I k : 1 ≤ k ≤ m}, O ∪ { O k : 1 ≤ k ≤ m} is called a functional decomposition if F = ⊗ { F k : 1 ≤ k ≤ m} FOSE ETH Zürich November 2010 Manfred Broy 20
Relation views: tracing Interface assertion Safety Priority Component Function R 1 ... Yes high R 2 ... No medium R n ... no low FOSE ETH Zürich November 2010 Manfred Broy 21
Relating logical views • Let p be a properties and R be a set of properties • a subset R’ ⊆ R is called guarantor for p in R if ∧ R’ ⇒ p • Classifying guarantors ◊ A guarantor R’ for p is called minimal, if every strict subset of R’ is not a guarantor ◊ a minimal guarantor is called unique if there does not exist a different minimal guarantor. ◊ A property q ∈ R is called weak guarantor for p in R if it occurs in some minimal guarantor of p in R ◊ A property q ∈ R is called strong guarantor for p in R if it occurs in every guarantor of p in R Cf. Primimplikanten a la Quine FOSE ETH Zürich November 2010 Manfred Broy 22
Relationship: req spec to function spec - tracing system level reqs R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 . . . R k sub-function reqs Q 1 Q 2 Q 3 ... Q n Red: Q i is strong guarantor of R j Yellow: Q i is weak guarantor of R j Green: Q i is not a weak guarantor of R j FOSE ETH Zürich November 2010 Manfred Broy 23
Architecture • Composition F = F 1 ⊗ F 2 ⊗ F 3 x 3 : T 3 y 3 : T’ 3 y 8 : T’ 8 F 2 x 2 : T 2 x 8 : T 8 F 1 y 8 : T’ 8 x 1 : T 1 y 7 : T’ 7 x 7 : T 7 x 8 : T 8 x 2 : T 2 x 3 : T 3 y 3 : T’ 3 y 6 : T’ 6 x 6 : T 6 F 1 y 8 : T’ 8 x 1 : T 1 F F 2 x 8 : T 8 y 6 : T’ 6 x 6 : T 6 y 7 : T’ 7 x 7 : T 7 y 6 : T’ 6 x 6 : T 6 y 7 : T’ 7 x 7 : T 7 F 3 y 4 : T’ 4 F 3 y 4 : T’ 4 x 4 : T 4 x 4 : T 4 x 5 : T 5 y 5 : T’ 5 x 5 : T 5 y 5 : T’ 5 FOSE ETH Zürich November 2010 Manfred Broy 24
Relationship: architecture to requirements system level reqs R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 R 9 . . . R k sub-system reqs P 1 P 2 P 3 ... P n Red: P i is strong guarantor of R j Yellow: P i is weak guarantor of R j Green: P i is not a weak guarantor of R j FOSE ETH Zürich November 2010 Manfred Broy 25
Relating components with system level functional specs • Given a ◊ Functional structuring of the system level functionality ◊ A component architecture ◊ A functional decomposition of each of the components • we relate ◊ each sub-function at the system level functionality with the component level ◊ each sub-function at the system level functionality with the sub-functions at the component level FOSE ETH Zürich November 2010 Manfred Broy 26
Recommend
More recommend
