Tarski: A Platform for Automated Analysis of Dynamically ...

IntroductionApproach

DemonstrationConclusion and Future Work

Tarski: A Platform for Automated Analysis ofDynamically Configurable Traceability Semantics

Ferhat Erata1,2 Moharram Challenger1,4 Bedir Tekinerdogan1

Anne Monceaux3 Eray Tuzun5 Geylani Kardas4

1Information Technology Group, Wageningen University, The Netherlands2UNIT Information Technologies R&D Ltd., Izmir, Turkey

3System Engineering Platforms, AIRBUS Group Innovations, Toulouse, France4International Computer Institute, Ege University, Izmir, Turkey

5Academy Directorate, HAVELSAN Inc., Ankara, Turkey

3rd Workshop on Dependability at Izmir Institute of Technology

F. Erata et al. Traceability Analysis on Tarski Platform



Acknowledgements

Scientific and Technological Research Council of Turkey(TUBITAK), Technology and Innovation Funding ProgramsDirectorate (TEYDEB) under project# 9140014, 9150181Minister for the Economy, Industry and Digital Affairs ofFrance, Directorate-General for Enterprise (DGE) undercontract# 14293020European Cooperation in Science and Technology (COST)Action IC1404 ”Multi-Paradigm Modelling for Cyber-PhysicalSystems”




Exploitations

ITEA-ModelWriter: Synchronized Document Engineering Platformhttps://itea3.org/project/modelwriter.html

ITEA-ASSUME: Affordable Safe & Secure Mobility Evolutionhttps://itea3.org/project/assume.html

Source codes, datasets and screencasts are available at:https://github.com/ModelWriter/WP3


https://itea3.org/project/modelwriter.html

https://itea3.org/project/assume.html

https://github.com/ModelWriter/WP3



Outline1 Introduction

MotivationIndustrial Use Cases

2 ApproachTraceability Domain ModelFirst-order Relational Model and LogicType Annotation and Trace-RelationsFormal Semantics and Automated Analysis

3 DemonstrationFormal Specification of Traceability SemanticsTraceability ManagementFirst-order Model ManagementAutomated Analysis of Traceability

4 Conclusion and Future WorkF. Erata et al. Traceability Analysis on Tarski Platform




What is Traceability?Traceability can be defined as the degree to which a relationshipcan be established among work products (aka. artefacts) of thedevelopment 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.





Challenges of Traceability in Industry

Semantically meaningful traceabilitytraceability 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 ofdifferent projects.Different traceable elements and the relation types exist inindustrial settings,Likewise, different traceability analysis scenarios exists.Several industries demands formal proofs of Traceability.







Configuration of traceability (possibly dynamically)Traceability Semantics is often statically defined.The semantics cannot be easily adapted for the needs ofdifferent projects.

Different traceable elements and the relation types exist inindustrial settings,Likewise, different traceability analysis scenarios exists.Several industries demands formal proofs of Traceability.







Configuration of traceability (possibly dynamically)Traceability Semantics is often statically defined.The semantics cannot be easily adapted for the needs ofdifferent projects.Different traceable elements and the relation types exist inindustrial settings,

Likewise, different traceability analysis scenarios exists.Several industries demands formal proofs of Traceability.







Configuration of traceability (possibly dynamically)Traceability Semantics is often statically defined.The semantics cannot be easily adapted for the needs ofdifferent projects.Different traceable elements and the relation types exist inindustrial settings,Likewise, different traceability analysis scenarios exists.Several industries demands formal proofs of Traceability.





Airbus Group InnovationsSystem Installation Design Principles





Havelsan Aerospace Electronics IndustryApplication Lifecycle Management

DO-178CSoftware Considerations in Airborne Systems and EquipmentCertification

TraceabilityDO-178 requires a documented connection (called a trace) betweenthe certification artifacts. For example, a Low Level Requirement(LLR) traces up to a High Level Requirement (HLR). A traceabilityanalysis is then used to ensure that each requirement is fulfilled bythe source code, that each requirement is tested, that each line ofsource code has a purpose (is connected to a requirement), and soforth. Traceability ensures the system is complete.


Traceability Analysis Activities defined in DO-178




Traceability Domain ModelFirst-order Relational Model and LogicType Annotation and Trace-RelationsFormal Semantics and Automated Analysis









A conceptual model for traceability and its extension

1 .. * {ordered}

Trace-element

Trace-linkTrace-location

0..*

FileLocation TextLocation JavaLocationXMILocation

depend

require

satisfy

contain

...

generate

ContractRequirement SystemRequirement

ModelElement...

Traceability Information {unique} 1..*

source

...

{xor}

0..1

targets

elements

Requirement

EClassifier





Semantics of contain relation (represents decomposition)

1 .. * {ordered}

Trace-element


0..*


depend

require

satisfy

contain

...

generate


ModelElement...


source

...

{xor}

0..1

targets

elements

transitive, irreflexive, antisymmetric,injective relation

Requirement

EClassifier





Semantics of ContractRequirement

1 .. * {ordered}

Trace-element


0..*


depend

require

satisfy

contain

...

generate


ModelElement...


source

...

{xor}

0..1

targets

elements

Requirement

EClassifier

Disjoint subset of the set of Requirement, Domain and Co-domain of contain relation





Fragments of a traceability instance

e3: EClass

e2: EClass

f1: Field

m1: Method

c2: Class

ECore Design Document [Y]

Java Package [Z]

s1: SystemReq

s2: SystemReq

Requirement Document [X]

{(E1,E3)}

{(E2,E1)}

{(E3)}

{(U1)}

{(E2)}

{(S1)}

{(S2)}

{(E1)}

{ (F1, {(S1, E1)}) } = { (F1, S1), (F1, E1) } =

jre1: {(F1, S1, E1)}

{ (U1, { (S1), (S2) }) }

m2: Method

c3: Class

{(M2)}

{(C3)}

Java Package [W]ej

1: {(E2, M1)}

ej3: {(E3, P2)}

{(C3,M2)}

W = {(P2), (C3), (M2), (C3,M2)}Y = {(E1), (E2), (E3), (E2,E1), (E1,E3)}

X = {(U1), (S1), (S2), (U1,S1), (U1,S2)}

{(C1,M1)}

{(C1,F1)}

{(C1)}

{(C2)}

{(F1)}

{(M1)}

Z = {(P1), (C1), (C2), (F1), (M1), (C1,F1), (C1,M1)} + W

Trace-Relations = {(S1), (E1), (E2), (E3), (F1), (M1), (E2,M1), (E2,M2), (E3,P2), (F1,S1,E1), (P2)}

Formalization = ec: E ->(C + M + F) and ep: E -> P and fse: F -> S -> E

ej2: {(E2, M2)}

<<re

fin

es>>

u1: UserReq<<

ERef

eren

ce>>

e1: EClass

<<inherits>>

<<calls>>

c1: Class

{(P2)}

{(P1)}

f1.source

jre 1.ta

rgets[1]

jre1 .targets[0]





First-order relational model of the traceability instance

The universe of traceability of the current stateDT : {S1,E1,E2,E3,F1,M1,M2,P2}

The type signatureΣT : {REJ v E → C t M t F , RJRE v F → S → E}

The relational model under the signature ΣT

Mt : {S = {〈S1〉},E = {〈E1〉, 〈E2〉, 〈E3〉}, J ={〈F1〉, 〈M1〉, 〈M2〉, 〈P2〉},REJ = {〈E2,M1〉, 〈E2,M2〉, 〈E3,P2〉},RJRE = {〈F1,S1,E1〉}}





First-order Relational Logic (FOL + Relational Calculus)

. Relational Join and ∼ TransposeThe dot join and transpose operators ensure a uniform way ofnavigation between trace-locations through trace-links inconstraints.

∗ˆ(Reflexive) Transitive ClosureTransitive Closure allows the encoding of common reachabilityconstraints that otherwise could not be expressed in FOL, such aspreventing cyclic dependencies between trace-locations.

Domain and Range RestrictionsThe restriction operators are used to filter relations to a givendomain or range.





First-order Relational Logic (FOL + Relational Calculus)

. Relational Join and ∼ TransposeE .REJ = {〈E1〉, 〈E2〉, 〈E3〉}.{〈E2,M1〉, 〈E2,M2〉, 〈E3,P2〉}= {〈M1〉, 〈M2〉, 〈P2〉}J . ∼ REJ = {〈F1〉, 〈M1〉, 〈M2〉, 〈P2〉}.{〈M1,E2〉, 〈M2,E2〉, 〈P2,E3〉}= {〈E2〉, 〈E3〉}

∗ˆ(Reflexive) Transitive Closure{̂〈M1,E1〉, 〈E1,C1〉} = {〈M1,E1〉, 〈E1,C1〉, 〈M1,C1〉}

Domain and Range RestrictionsP <: RJE = {〈P2〉} <: {〈M1,E2〉, 〈M2,E2〉, 〈P2,E3〉} = {〈P2,E3〉}





Basic Type and SubType

⊥

⊤

Requirement Implementation

Code Executable

ExecutableObjectCode

ContractReq SystemReq

none = { }

univ = {r1,r2,r3,r4,i1,i2,i3}

denotes the set of all possible atoms

denotes empty set and is the type of no atoms

Top level signatures(basic type)

Extension signatures(subtype)

in in

Subset signatures

LowLevelReq{r1}

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.

{r1,r2}{r3}

{r1,r2,r3,r4}

{i1}

{i1,i2}

inin

{i1}

{i1,i2,i3}

The domain of discourse of any structure of that signature is then fragmented into disjoint subsets, one for every sort.

extends extends

extends





Relation Types

⊥

⊤

Requirement Implementation

Code Executable

ExecutableObjectCode

ContractReq SystemReq

none = { }

univ = {r1,r2,r3,r4,i1,i2,i3}

denotes the set of all possible atoms

denotes empty set and is the type of no atoms

in in

LowLevelReq{r1}

{r1,r2}

contain: ContractReq lone -> ContractReq

{r1,r2,r3,r4}

{i1}

{i1,i2}

inin

{i1}

{i1,i2,i3}

{r3} satisf

iedBy:

Syste

mReq -

> some

Imple

mentat

ion

refine: ContractReq one -> some SystemReq

{(r3,r1),(r3,r2)}





Formal Specification of an example configuration

1 abstract sig Artefact { depends : set Artefact}23 -- Locate@File4 one sig Specification extends Artefact {5 contract : some ContractRequirement}67 -- Locate@Text8 sig ContractRequirement extends Artefact {9 system : set SystemRequirement ,

10 contains : set ContractRequirement}1112 -- Locate@ReqIF13 sig SystemRequirement extends Artefact {14 satisfiedBy : set Implementation ,15 requires : set SystemRequirement ,16 refines : set SystemRequirement}





17 abstract sig Implementation extends Artefact {18 fulfills : lone ContractRequirement}1920 -- Locate@Java21 sig Code, Component extends Implementation {}2223 -- Locate@EMF24 sig Model extends Implementation {25 transforms , conforms : set Model,26 generates : set (Code ∪ Component)}2728 -- [email protected] fact {∀ i : Implementation | some i.˜satisfiedBy}





Automated analysis functions over Traceability Model

Consistency CheckingThe system checks whether the user model satisfies thespecification or not.

Reasoning about Trace-relationsIf the model is a partial (incomplete), the platform tries tocomplete the model with respect to the semantics declared in thespecification inferring new trace-relations on the model.

Trace-elements DiscoveryIf a de-synchronization occurs on one or more ends of a trace-linkprobably caused by a change such as deletion of a trace-location,we try to repair the broken link based on the specified semantics.





Reasoning about Trace-relations

30 -- [email protected] fact {∀ s : SystemRequirement , s' : s.*˜refines |32 s'.˜system = s.˜system}3334 -- [email protected] fact { ∀ s, s' : SystemRequirement |36 s' in s.refines =⇒ s in s'.requires }3738 -- [email protected] fact {∀ i : Implementation , s : i.˜satisfiedBy40 | i.fulfills = s.˜system }




Formal Specification of Traceability SemanticsTraceability ManagementFirst-order Model ManagementAutomated Analysis of Traceability









Configuration of User’s WorkspaceUser Traceability Framework Tarski Platform Alloy

Configuration of Eclipse Workspace

Formal Specification of the semantics alloy4compiler

User’s Workspace Traceability Management Adaptation of Tarski Platform to

Traceability Domain

First-order Model Management Abstract Syntax Tree

Automated Analysis of Traceability

Automated Analysis Decision Procedure

Interpretation Function

Alloy ParserAlloy Specification Eclipse Front-End

Analyze Custom Annotations

FunctionsConsistency Check

Reason about Relations

Trace Elements Discovery

uses

Synthesis

Internal Representation

KodKod API Call

Type hierarchy (sigs, fields) &

Semantics (facts)

KodKod Relational Model Finder

Functions

interprets

Analyzing TraceabilityReasoning about trace instance

Load/Update

Interface

First-order Relational Model

Relation

Interpreted Atom

Universe

Tuple

*

*

*

Traceability Information

**

1

from

to

elements*

Creating Trace Location

...

Text Fragments

EClasses, EObjects

XML Elements

Java Elements

Update/Delete Trace Location

Assigning Types

Loading/Updating Spec.

Trace Location

Trace Link

Traceability

*

The user can assign types to both trace locations and links using the relation names of the specification

generates

uses

uses

Model





Configuration of User’s Workspace





Type Hierarchy from the SpecificationUser Traceability Framework Tarski Platform Alloy




Traceability Domain










uses

Synthesis


KodKod API Call


Semantics (facts)


Functions

interprets


Load/Update

Interface


Relation

Interpreted Atom

Universe

Tuple

*

*

*


**

1

from

to

elements*


...

Text Fragments

EClasses, EObjects

XML Elements

Java Elements


Assigning Types


Trace Location

Trace Link

Traceability

*


generates

uses

uses

Model





Type Hierarchy from the Specification





Creating Trace-locations and Assigning TypesUser Traceability Framework Tarski Platform Alloy




Traceability Domain










uses

Synthesis


KodKod API Call


Semantics (facts)


Functions

interprets


Load/Update

Interface


Relation

Interpreted Atom

Universe

Tuple

*

*

*


**

1

from

to

elements*


...

Text Fragments

EClasses, EObjects

XML Elements

Java Elements


Assigning Types


Trace Location

Trace Link

Traceability

*


generates

uses

uses

Model





Assigning a Sub Type to a Trace-location





Assigning a binary Field Type to a Trace-link





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






...





Dynamic Configuration & Model Management





Reasoning about Trace-instance

...





Synthesis of Internal Representation

...




Should we consider also the temporal behavior of thetraceability? Interesting analysis scenarios exist in industryWe are not supporting ordered sets of Alloy which usually helpmodel the dynamic behaviour.First-order theory of relations might be a candidate fortraceability in Multi-pardigm Modeling for Cyber-physicalSystems. Preliminary results shows that the approach workson the synchronization of design rules with design/installationof physical components.However, DPLL(T) solvers does not currently exists for thisfragment of the theory.Alloy Language is too expressive for the domain of traceability.We’re working on the formalization of a First-order theory fortraceability and the development of a domain-specificlanguage for traceability.




Modeling and Reasoning Approaches


Tarski: A Platform for Automated Analysis of Dynamically ...

Documents

Transcript of Tarski: A Platform for Automated Analysis of Dynamically ...