Formal Specification of Topological Relations

26
Formal Specification of Topological Relations Erika Asnina, Janis Osis and Asnate Jansone Riga Technical University The 10th International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2012) July 8-11, 2012, Vilnius, Lithuania 1

description

Formal Specification of Topological Relations. Erika Asnina , Janis Osis and Asnate Jansone Riga Technical University The 10th International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2012) July 8-11, 2012, Vilnius, Lithuania. - PowerPoint PPT Presentation

Transcript of Formal Specification of Topological Relations

Page 1: Formal Specification of  Topological Relations

Formal Specification of Topological Relations

Erika Asnina, Janis Osis and Asnate JansoneRiga Technical University

The 10th International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2012)

July 8-11, 2012, Vilnius, Lithuania

1

Page 2: Formal Specification of  Topological Relations

Software Engineering (SE) VS Software Development (SD)

2

System

Software

• SE foresees the analysis of both the system and software.

• SD narrows it to the analysis of software and only a part of its interaction with the system.

Page 3: Formal Specification of  Topological Relations

Why?

• Main reasons of ignoring the proper analysis of the system are:– Time. First results must be delivered to the

client as fast as possible;– Deliverable items. The most important

deliverable item is software not specifications, designs, or results of the analysis;

– Finance. The proper system analysis requires more finance at the beginning of the project.

3

Page 4: Formal Specification of  Topological Relations

Is there a solution?

The solution could be ifsystem analysis and design models

are used directly for producing software code

MODEL-DRIVEN

SOFTWARE DEVELOPMENT

4

Page 5: Formal Specification of  Topological Relations

Model-Driven SD Principles

5

Computation Independent Model (CIM)

Platform Independent Model (PIM)

Platform Specific Model (PSM)

Code

Intuitive Manual Transformation

Automated M2M Transformation

Automated M2C Transformation

Page 6: Formal Specification of  Topological Relations

MDSD + System Analysis?

• System analysis is conducted at the computation independent level

• In order to make software engineering by model-driven, the CIM must also “drive” development, i.e., it must be included in the model transformation chain

• The CIM must be formal and transformable to design models

6

Page 7: Formal Specification of  Topological Relations

Model-Driven SD Principles

7

Computation Independent Model (CIM)

Platform Independent Model (PIM)

Platform Specific Model (PSM)

Code

Topological Functioning Model, Requirements Specification,

Data Vocabulary

Design Model (e.g., in UML)

Platform Specific Design Model (e.g., in UML profile for J2EE)

Code (e.g., J2EE / Java code)

Automated M2M Transformation

Automated M2C Transformation

Automated M2M Transformation

Page 8: Formal Specification of  Topological Relations

Topological Functioning Model(1)

• It is a computation independent model• It provides correspondence between system and

software models by means of mathematical continuous mapping between graphs

• It is a means for verification of requirements completeness, determination of shared functionality and derivation of use cases, integration of system knowledge that usually are expressed as a set of interrelated fragments, and derivation of system’s structure and behavior.

8

Sojenna
Pielabot ko teikt
Page 9: Formal Specification of  Topological Relations

Topological Functioning Model(2)

• A topological functioning modelA topological space (X, ). X is a finite set of system properties called functional features. is a set topology in the form of a digraph

• A digraph describes cause-and-effect relations among system functional features or properties

• Notation– nodes functional features– arcs cause-and-effect relations

9

Page 10: Formal Specification of  Topological Relations

The Challenge

The holistic nature of the TFM requires identification and analysis of all cause-and-effect relations,

which are important for system’s operation.

This intuitive work must be formalized!

10

Page 11: Formal Specification of  Topological Relations

TFM Cause-and-Effect Relations

• It has a time dimension, since a cause chronologically precedes an effect;

• In causal connections “something is allowed to go wrong”, whereas logical statements allow no exceptions;

• Causes may be sufficient or necessary (in other words, complete or partial) for generating an effect;

• Cause-and-effect relations involve multiple factors. Sometimes there are factors in series. Sometimes there are factors in parallel;

• The causality is universal. This means that there is no such a problem domain without causes and effects.

________________________________________________• Cause-and-Effect Relations Control Flows

11

Page 12: Formal Specification of  Topological Relations

System Functioning Controlled by Cause and Effect Relations

• When some phenomenon occurs in the external environment, a process starts. Conduction of functional feature begins with the initiation event (init), then functional feature (A) is executing, and after successful execution the termination event (terminated) occurs. Following control flow that is represented as a cause-and-effect relation (such as ones between A and B1, B1 and B2), the initiation event of other functional feature (B1) occurs, and so on till the phenomenon sent to the external environment, the process ends.

12

Page 13: Formal Specification of  Topological Relations

The Common Case of Cause and Effect Relations

• A functional feature starts if its preconditions are satisfied, and ends setting post-conditions.

• But completeness of post-conditions to satisfy a precondition of the effect depends on proper analysis of the system knowledge.

13

FF1

FF2

FF3 FF4

FF5

FF6

[preCond1]

[preCond2]

[preCond3] [preCond4]

[preCond5]

[preCond6]

[postCond1]

[postCond2]

[postCond3] [postCond4]

[postCond5]

[postCond6]

Page 14: Formal Specification of  Topological Relations

Formal Definition of a Cause and Effect Relation

• A unique tuple <C, E, N, S, Refs>, where– C (cause) is a functional feature that generates functional

feature E, this could not be empty;– E (effect) is a functional feature that is generated by

functional feature C, this could not be empty;– N is necessity of the functional feature C for generating

the functional feature E; the values are true or false;– S is sufficiency of the functional feature C; the values are

true or false;– Refs (references) is a set of unique tuples <Ref_Ids, LOp>,

where Ref_Ids is a set of tuples <C*, E*> of cause-and-effect relations that participate in logical operation LOp together.

14

Page 15: Formal Specification of  Topological Relations

Classical Logic• Logical operators LOp are operators from classical logic such as

conjunction (AND), disjunction (OR), and negation (NOT). Conjunction indicates synchronous occurrence of referenced causes. Disjunction indicates asynchronous occurrence of referenced causes.

• The necessity of the cause is determined when the occurrence of the effect indicates on the occurrence of the cause.

• The sufficiency of the cause is determined when the occurrence of the cause indicates on the occurrence of the effect.

• The necessary and sufficient cause is when the occurrence of the effect is possible if and only if the cause occurred, and occurrence of the effect indicates on the obligatory occurrence of the cause.

15

Page 16: Formal Specification of  Topological Relations

Possible Combinations• An incorrectly defined cause in a cause-and-effect relation

between functional features is when a cause is not necessary and not sufficient for generating an effect functional feature.

• Existence of logical operators between two causes (input cause-and-effect relations): – AND operator must be set between two causes if they all are necessary

but not sufficient;– OR operator must be set between two causes if they all are sufficient

but not necessary.• If every of more than one cause is both necessary and sufficient,

then these causes are joined by the logical operator XOR (exclusive OR).

• In general case, we must review all the combination of necessity and sufficiency of causes and elect those where both necessity and sufficiency (or at least sufficiency) are true.

16

Page 17: Formal Specification of  Topological Relations

Illustration: The Library TFM (1)

• f13: Taking back a book copy, {}, Lib;

• f14: Checking the term of loan of a book copy, {}, Lib;

• f15: Evaluating the condition of a book copy, {}, Lib;

• f16: Imposing a fine, {the loan term is exceeded, the lost book, or the damaged book}, Lib;

• f17: Returning the book copy to a book fund, {}, Lib;

• f18: Paying a fine, {imposed fine}, R;

• f19: Closing a fine, {paid fine}, Lib;

17

2728

2425 23

11

22

20

2116

19

15

18

1314

12

97

8

6

1 2 3 4 5

10

17

after

26

2728

2425 23

11

22

20

2116

19

15

18

1314 12

97

8

6

1 2 3 4 5

10

17

before

26

Page 18: Formal Specification of  Topological Relations

Illustration: The Library TFM (2)

• Functional Features– f13: Taking back a book copy, {}, Lib; – f14: Checking the term of loan of a book copy,

{}, Lib;– f15: Evaluating the condition of a book copy, {},

Lib;

• Case 1:– r13-14: C= f13, E= f14, N=true, S=true, Refs =

empty set;• Case 2:

– r14-15: C= f14, E= f15, N=false, S=false, Refs = empty set;

– The relation is removed. The new relation r13-15 is established.

18

2728

2425 23

11

22

20

2116

19

15

18

1314

12

97

8

6

1 2 3 4 5

10

17

after

26

2728

2425 23

11

22

20

2116

19

15

18

1314 12

97

8

6

1 2 3 4 5

10

17

before

26

Page 19: Formal Specification of  Topological Relations

Illustration: The Library TFM (3)• Functional Features

– f14: Checking the term of loan of a book copy, {}, Lib;– f15: Evaluating the condition of a book copy, {}, Lib;– f16: Imposing a fine, {the loan term is exceeded, the

lost book, or the damaged book}, Lib;– f18: Paying a fine, {imposed fine}, R; – f19: Closing a fine, {paid fine}, Lib;

• Case 3:– r14-16: C= f14, E= f16, N= false, S=true,

Refs = {r15-16; OR};– r15-16: C= f15, E= f16, N= false, S= true,

Refs = {r14-16; OR};

• Case 4:– r16-19: C= f16, E= f19, N= true, S=false,

Refs = {r18-19, AND};– r18-19: C= f18, E= f19, N=true, S= false,

Refs ={r16-19, AND};

19

2728

2425 23

11

22

20

2116

19

15

18

1314

12

97

8

6

1 2 3 4 5

10

17

after

26

2728

2425 23

11

22

20

2116

19

15

18

1314 12

97

8

6

1 2 3 4 5

10

17

before

26

Page 20: Formal Specification of  Topological Relations

Illustration: The Library TFM (4)• Functional Features

– f14: Checking the term of loan of a book copy, {}, Lib; – f15: Evaluating the condition of a book copy, {}, Lib; – f16: Imposing a fine, {the loan term is exceeded, the lost

book, or the damaged book}, Lib; – f17: Returning the book copy to a book fund, {}, Lib;

• Case 5:– r14-17: C= f14, E= f17, N= true, S = false, Refs = ?;– r15-17: C= f15, E= f17, N= true, S= false, Refs = ?;– r16-17: C= f16, E= f17, N=true, S= true, Refs = ?;

20

Sojenna
šito negribu likt
Page 21: Formal Specification of  Topological Relations

Illustration: The Library TFM (5)

• Case 5:– r14-17’: C= f14, E= f17, N= true, S = false, Refs = {r15-17’, ¬r16-

17’, AND} XOR {r16-17’,¬r15-17’, AND}; see rows 5 and 6.– r15-17’: C= f15, E= f17, N= true, S= false, Refs = {r14-17’,¬r16-

17’, AND} XOR {r16-17’, ¬r14-17’, AND}; see rows 3 and 6.– r16-17’: C= f16, E= f17, N = true, S= true, Refs = {¬r14-17’,

¬r15-17’, AND} XOR {r15-17, ¬ r14-17’, AND} XOR { r14-17’, ¬ r15-17’, AND}; see rows 2, 3, and 5.

21

Row f14 f15 f16 f17 Necessary Sufficient1 0 0 0 0 false false2 0 0 1 1 true true3 0 1 1 1 true true4 1 0 0 0 false false5 1 0 1 1 true true6 1 1 0 1 true true7 1 1 1 0 false false

Sojenna
f14: checking the termf15:evaluating the conditionf16: imposing a finef17: returning the book
Page 22: Formal Specification of  Topological Relations

The Source TFM “Before” and The Corresponding UML Activity Diagram

22

1615

13

14

17

Before

Take back a book copy

Check term of loan of book copy

Evaluate condition of book copy

Return book copy to book fund

Impose fine

[the loan term is exceeded]

[lost book OR damaged book]

Page 23: Formal Specification of  Topological Relations

The Source TFM “After” and The Corresponding UML Activity Diagram

23

16

14

13

15

17

After

Take back a book copy

Check term of loan of book copyEvaluate condition of book copy

Return book copy to book fund

Impose fine

[the loan term is exceeded] [lost book OR damaged book]

¬r14-16 OR ¬r15-16

r15-17' AND ¬r14-17' AND r16-17'

¬r14-17’ AND ¬r15-17’ AND r16-17

¬r15-17' AND r14-17' AND r16-17'

r15-17' AND r14-17' AND ¬r16-17'

Page 24: Formal Specification of  Topological Relations

Conclusions• The proposed formalization allows

– discovering of misunderstandings or mistakes in the already constructed TFM;

– defining synchronous and asynchronous occurrences of the causes automatically in a part of cases.

• It is a step towards – better understanding of the system functionality, and – automated M2M transformation starting from the

very beginning of the software development process.

24

Page 25: Formal Specification of  Topological Relations

Further Research Directions

• Model checking for the TFM– Model checking is a field where results of

analysis and modeling of system and software behavior are formally and automatically verified.

25

Page 26: Formal Specification of  Topological Relations

Thank You for Attention !

26