Tarski: A Platform for Automated Analysis of Dynamically Configurable Traceability Semantics

Transcription

1 Tarski: A Platform for Automated Analysis of Dynamically Configurable Traceability Semantics Ferhat Erata 1,2 Moharram Challenger 1,4 Bedir Tekinerdogan 1 Anne Monceaux 3 Eray Tuzun 5 Geylani Kardas 4 1 Information Technology Group, Wageningen University, The Netherlands 2 UNIT Information Technologies R&D Ltd., Izmir, Turkey 3 System Engineering Platforms, AIRBUS Group Innovations, Toulouse, France 4 International Computer Institute, Ege University, Izmir, Turkey 5 Academy Directorate, HAVELSAN Inc., Ankara, Turkey 3rd Workshop on Dependability at Izmir Institute of Technology

2 Acknowledgements Introduction Scientific and Technological Research Council of Turkey (TUBITAK), Technology and Innovation Funding Programs Directorate (TEYDEB) under project# , Minister for the Economy, Industry and Digital Affairs of France, Directorate-General for Enterprise (DGE) under contract# European Cooperation in Science and Technology (COST) Action IC1404 Multi-Paradigm Modelling for Cyber-Physical Systems

3 Exploitations Introduction ITEA-ModelWriter: Synchronized Document Engineering Platform ITEA-ASSUME: Affordable Safe & Secure Mobility Evolution Source codes, datasets and screencasts are available at:

4 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

5 Outline Introduction Motivation Industrial Use Cases 1 Introduction Motivation Industrial Use Cases 2 3 4

6 Motivation Industrial Use Cases What is Traceability? Traceability can be defined as the degree to which a relationship can be established among work products (aka. artefacts) of the development process. What is case-based or project-based traceability configuration? Rigorously specification the semantics of traceability elements. Why is Reasoning about Traceability important? Richer and precise automated traceability analysis. Compliance and Certification in automotive and aviation industries.

7 Motivation Industrial Use Cases Challenges of Traceability in Industry Semantically meaningful traceability traceability relations should have a rich semantic (meaning) instead of being simple bi-directional referential relation Configuration of traceability (possibly dynamically) Traceability Semantics is often statically defined.

8 Motivation Industrial Use Cases Challenges of Traceability in Industry Semantically meaningful traceability traceability relations should have a rich semantic (meaning) instead of being simple bi-directional referential relation Configuration of traceability (possibly dynamically) Traceability Semantics is often statically defined. The semantics cannot be easily adapted for the needs of different projects.

9 Motivation Industrial Use Cases Challenges of Traceability in Industry Semantically meaningful traceability traceability relations should have a rich semantic (meaning) instead of being simple bi-directional referential relation Configuration of traceability (possibly dynamically) Traceability Semantics is often statically defined. The semantics cannot be easily adapted for the needs of different projects. Different traceable elements and the relation types exist in industrial settings,

10 Motivation Industrial Use Cases Challenges of Traceability in Industry Semantically meaningful traceability traceability relations should have a rich semantic (meaning) instead of being simple bi-directional referential relation Configuration of traceability (possibly dynamically) Traceability Semantics is often statically defined. The semantics cannot be easily adapted for the needs of different projects. Different traceable elements and the relation types exist in industrial settings, Likewise, different traceability analysis scenarios exists. Several industries demands formal proofs of Traceability.

11 Outline Introduction Motivation Industrial Use Cases 1 Introduction Motivation Industrial Use Cases 2 3 4

12 Airbus Group Innovations System Installation Design Principles Motivation Industrial Use Cases

13 Airbus Group Innovations System Installation Design Principles Motivation Industrial Use Cases

14 Airbus Group Innovations System Installation Design Principles Motivation Industrial Use Cases

15 Motivation Industrial Use Cases Havelsan Aerospace Electronics Industry Application Lifecycle Management DO-178C Software Considerations in Airborne Systems and Equipment Certification Traceability DO-178 requires a documented connection (called a trace) between the certification artifacts. For example, a Low Level Requirement (LLR) traces up to a High Level Requirement (HLR). A traceability analysis is then used to ensure that each requirement is fulfilled by the source code, that each requirement is tested, that each line of source code has a purpose (is connected to a requirement), and so forth. Traceability ensures the system is complete.

16 Traceability Analysis Activities defined in DO-178

17 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

18 A conceptual model for traceability and its extension Traceability elements Information {unique} 1..* Trace-element depend {xor} 0..* Trace-location 0..1 targets source 1.. * {ordered} Trace-link require satisfy XMILocation FileLocation TextLocation JavaLocation contain generate... ModelElement Requirement... EClassifier ContractRequirement... SystemRequirement

19 Semantics of contain relation (represents decomposition) Traceability elements Information {unique} 1..* XMILocation 0..* Trace-location Trace-element targets {xor} 1.. * {ordered} 0..1 source Trace-link transitive, irreflexive, antisymmetric, injective relation FileLocation TextLocation JavaLocation depend require satisfy contain generate... ModelElement Requirement... EClassifier ContractRequirement... SystemRequirement

20 Semantics of ContractRequirement Traceability elements Information {unique} 1..* Trace-element depend {xor} 0..* Trace-location 0..1 targets source 1.. * {ordered} Trace-link require satisfy XMILocation FileLocation TextLocation JavaLocation contain generate... Disjoint ModelElement subset of the set of Requirement, Domain and Co-domain of contain relation Requirement... EClassifier ContractRequirement... SystemRequirement

21 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

22 Fragments of a traceability instance X = {(U1), (S1), (S2), (U1,S1), (U1,S2)} Requirement Document [X] {(U1)} u1: UserReq {(S1)} <<refines>> ECore Design Document [Y] {(E1,E3)} e3: EClass s1: SystemReq s2: SystemReq { (U1, { (S1), (S2) }) } {(E1)} e1: EClass <<EReference>> <<inherits>> {(E2,E1)} e2: EClass {(E3)} {(S2)} {(E2)} Y = {(E1), (E2), (E3), (E2,E1), (E1,E3)} Z = {(P1), (C1), (C2), (F1), (M1), (C1,F1), (C1,M1)} + W Java Package [Z] { (F1, {(S1, E1)}) } = { (F1, S1), (F1, E1) } = jre 1 : {(F1, S1, E1)} ej 1 : {(E2, M1)} ej 2 : {(E2, M2)} ej 3 : {(E3, P2)} {(C1,F1)} f1: Field {(F1)} Java Package [W] {(M2)} {(C3,M2)} m2: Method {(C1)} c2: Class {(C1,M1)} m1: Method {(C3)} c3: Class {(C2)} {(M1)} W = {(P2), (C3), (M2), (C3,M2)}

23 First-order relational model of the traceability instance The universe of traceability of the current state D T : {S 1, E 1, E 2, E 3, F 1, M 1, M 2, P 2 } The type signature Σ T : {R EJ E C M F, R JRE F S E} The relational model under the signature Σ T M t : {S = { S 1 }, E = { E 1, E 2, E 3 }, J = { F 1, M 1, M 2, P 2 }, R EJ = { E 2, M 1, E 2, M 2, E 3, P 2 }, R JRE = { F 1, S 1, E 1 }}

24 First-order Relational Logic (FOL + Relational Calculus). Relational Join and Transpose The dot join and transpose operators ensure a uniform way of navigation between trace-locations through trace-links in constraints. ˆ(Reflexive) Transitive Closure Transitive Closure allows the encoding of common reachability constraints that otherwise could not be expressed in FOL, such as preventing cyclic dependencies between trace-locations. Domain and Range Restrictions The restriction operators are used to filter relations to a given domain or range.

25 First-order Relational Logic (FOL + Relational Calculus). Relational Join and Transpose E.R EJ = { E 1, E 2, E 3 }.{ E 2, M 1, E 2, M 2, E 3, P 2 } = { M 1, M 2, P 2 } J. R EJ = { F 1, M 1, M 2, P 2 }.{ M 1, E 2, M 2, E 2, P 2, E 3 } = { E 2, E 3 } ˆ(Reflexive) Transitive Closure ˆ{ M 1, E 1, E 1, C 1 } = { M 1, E 1, E 1, C 1, M 1, C 1 } Domain and Range Restrictions P <: R JE = { P 2 } <: { M 1, E 2, M 2, E 2, P 2, E 3 } = { P 2, E 3 }

26 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

27 Basic Type and SubType univ = {r 1,r 2,r 3,r 4,i 1,i 2,i 3 } The domain of discourse of any structure of that signature is then fragmented into disjoint subsets, one for every sort. denotes the set of all possible atoms {r 1,r 2,r 3,r 4 } Requirement Top level signatures (basic type) Implementation {i 1,i 2,i 3 } extends extends Extension signatures (subtype) in Subset signatures in {r 3 } ContractReq {r 1,r 2 } SystemReq {i 1,i 2 } Code {i 1 } Executable extends in in {r 1 } LowLevelReq {i 1 } ExecutableObjectCode Subtype (also subtype polymorphism or inclusion polymorphism) defines a subtyping relation, it is reflexive (meaning A<:A for any type A) and transitive (meaning that if A<:B and B<:C then A<:C). This makes it a preorder on types. denotes empty set and is the type of no atoms none = { }

28 Relation Types Introduction univ = {r 1,r 2,r 3,r 4,i 1,i 2,i 3 } denotes the set of all possible atoms {r 3 } {r 1,r 2,r 3,r 4 } Requirement {r 1,r 2 } Implementation in satisfiedby: SystemReq -> some Implementation {i 1,i 2,i 3 } in ContractReq SystemReq {i 1,i 2 } Code {i 1 } Executable refine: ContractReq one -> some SystemReq contain: ContractReq lone -> ContractReq {(r 3,r 1 ),(r 3,r 2 )} in in {r 1 } LowLevelReq {i 1 } ExecutableObjectCode denotes empty set and is the type of no atoms none = { }

29 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

30 Formal Specification of an example configuration 1 abstract sig Artefact { depends: set Artefact} Locate@File 4 one sig Specification extends Artefact { 5 contract: some ContractRequirement} Locate@Text 8 sig ContractRequirement extends Artefact { 9 system: set SystemRequirement, 10 contains: set ContractRequirement} Locate@ReqIF 13 sig SystemRequirement extends Artefact { 14 satisfiedby: set Implementation, 15 requires: set SystemRequirement, 16 refines: set SystemRequirement}

31 17 abstract sig Implementation extends Artefact { 18 fulfills: lone ContractRequirement} Locate@Java 21 sig Code, Component extends Implementation {} Locate@EMF 24 sig Model extends Implementation { 25 transforms, conforms: set Model, 26 generates: set ( Code Component)} Semantics@SystemRequirement. satisfiedby 29 fact { i: Implementation some i. satisfiedby}

32 Automated analysis functions over Traceability Model Consistency Checking The system checks whether the user model satisfies the specification or not. Reasoning about Trace-relations If the model is a partial (incomplete), the platform tries to complete the model with respect to the semantics declared in the specification inferring new trace-relations on the model. Trace-elements Discovery If a de-synchronization occurs on one or more ends of a trace-link probably caused by a change such as deletion of a trace-location, we try to repair the broken link based on the specified semantics.

33 Reasoning about Trace-relations system 31 fact { s: SystemRequirement, s': s.* refines 32 s'. system = s. system} Reason@SystemRequirement. requires 35 fact { s, s': SystemRequirement 36 s' in s. refines = s in s'. requires } Reason@Implementation. fulfills 39 fact { i: Implementation, s: i. satisfiedby 40 i. fulfills = s. system }

34 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

35 Configuration of User s Workspace User Traceability Framework Tarski Platform Alloy Configuration of Eclipse Workspace Loading/Updating Spec. Alloy Specification Formal Specification of the semantics Functions Load/Update Eclipse Front-End Analyze Custom Annotations uses alloy4compiler Alloy Parser User s Workspace Adaptation of Tarski Platform to Creating Trace Location Traceability Traceability Domain Text Fragments EClasses, EObjects XML Elements Java Elements... Update/Delete Trace Location Assigning Types 1 * Trace Location * to from * Trace Link Traceability Information Interpretation Function Interface interprets Model * Relation * Tuple * elements Universe * Interpreted Atom First-order Relational Model uses Abstract Syntax Tree Type hierarchy (sigs, fields) & Semantics (facts) uses generates Automated Analysis of Traceability Analyzing Traceability The user can assign types to both trace locations and links using the relation names of the specification Reasoning about trace instance Functions Consistency Check Reason about Relations Trace Elements Discovery Automated Analysis Synthesis Internal Representation Decision Procedure KodKod API Call KodKod Relational Model Finder

36 Configuration of User s Workspace

37 Type Hierarchy from the Specification User Traceability Framework Tarski Platform Alloy Configuration of Eclipse Workspace Loading/Updating Spec. Alloy Specification Formal Specification of the semantics Functions Load/Update Eclipse Front-End Analyze Custom Annotations uses alloy4compiler Alloy Parser User s Workspace Adaptation of Tarski Platform to Creating Trace Location Traceability Traceability Domain Text Fragments EClasses, EObjects XML Elements Java Elements... Update/Delete Trace Location Assigning Types 1 * Trace Location * to from * Trace Link Traceability Information Interpretation Function Interface interprets Model * Relation * Tuple * elements Universe * Interpreted Atom First-order Relational Model uses Abstract Syntax Tree Type hierarchy (sigs, fields) & Semantics (facts) uses generates Automated Analysis of Traceability Analyzing Traceability The user can assign types to both trace locations and links using the relation names of the specification Reasoning about trace instance Functions Consistency Check Reason about Relations Trace Elements Discovery Automated Analysis Synthesis Internal Representation Decision Procedure KodKod API Call KodKod Relational Model Finder

38 Type Hierarchy from the Specification

39 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

40 Creating Trace-locations and Assigning Types User Traceability Framework Tarski Platform Alloy Configuration of Eclipse Workspace Loading/Updating Spec. Alloy Specification Formal Specification of the semantics Functions Load/Update Eclipse Front-End Analyze Custom Annotations uses alloy4compiler Alloy Parser User s Workspace Adaptation of Tarski Platform to Creating Trace Location Traceability Traceability Domain Text Fragments EClasses, EObjects XML Elements Java Elements... Update/Delete Trace Location Assigning Types 1 * Trace Location * to from * Trace Link Traceability Information Interpretation Function Interface interprets Model * Relation * Tuple * elements Universe * Interpreted Atom First-order Relational Model uses Abstract Syntax Tree Type hierarchy (sigs, fields) & Semantics (facts) uses generates Automated Analysis of Traceability Analyzing Traceability The user can assign types to both trace locations and links using the relation names of the specification Reasoning about trace instance Functions Consistency Check Reason about Relations Trace Elements Discovery Automated Analysis Synthesis Internal Representation Decision Procedure KodKod API Call KodKod Relational Model Finder

41 Assigning a Sub Type to a Trace-location

42 Assigning a binary Field Type to a Trace-link

43 Selecting a Trace-Location from the co-domain of the type

44 Traceability Information...

45 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

46 First-order Relational Model...

47 Dynamic Configuration & Model Management

48 Outline Introduction 1 Introduction Motivation Industrial Use Cases 2 3 4

49 Reasoning about Trace-instance...

50

51 Synthesis of Internal Representation...

52 Should we consider also the temporal behavior of the traceability? Interesting analysis scenarios exist in industry We are not supporting ordered sets of Alloy which usually help model the dynamic behaviour. First-order theory of relations might be a candidate for traceability in Multi-pardigm Modeling for Cyber-physical Systems. Preliminary results shows that the approach works on the synchronization of design rules with design/installation of physical components. However, DPLL(T) solvers does not currently exists for this fragment of the theory. Alloy Language is too expressive for the domain of traceability. We re working on the formalization of a First-order theory for traceability and the development of a domain-specific language for traceability.

53 Modeling and Reasoning es