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
Software Engineering (SE) VS
Software Development (SD)
•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.
System
Software
2
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
Is there a solution?
The solution could be if
system analysis and design models
are used directly for producing
software code

MODEL-DRIVEN
SOFTWARE DEVELOPMENT
4
Model-Driven SD Principles
Computation Independent
Model (CIM)
Intuitive Manual Transformation
Platform Independent Model
(PIM)
Automated M2M
Transformation
Platform Specific Model
(PSM)
Automated M2C Transformation
Code
5
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
Model-Driven SD Principles
Computation Independent
Model (CIM)
Topological Functioning Model,
Requirements Specification,
Data Vocabulary
Automated M2M Transformation
Platform Independent Model
(PIM)
Design Model (e.g., in UML)
Automated M2M Transformation
Platform Specific Model
(PSM)
Platform Specific Design Model
(e.g., in UML profile for J2EE)
Automated M2C Transformation
Code
Code (e.g., J2EE / Java code)
7
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
Topological Functioning Model(2)
• A topological functioning model
A 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
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
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
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
The Common Case of
Cause and Effect Relations
[preCond1]
[preCond5]
FF1
[postCond1]
[preCond2]
FF2
[postCond2]
[preCond3]
[preCond4]
FF3
FF4
[postCond3]
[postCond4]
FF5
[postCond5]
[preCond6]
FF6
[postCond6]
• 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
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
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
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
Illustration: The Library TFM (1)
27
28
1
2
25
3
17
6
11
7
20
9
8
15
16
21
10
19
22
5
23
24
26
4
14
13
before
18
12
• f13: Taking back a book copy,
27
{}, Lib;
2
• f14:1 Checking
the3 term 4of loan5
of a book24 copy, {}, Lib;
23
25
6
• f15:26Evaluating the condition 11
17
7
of
a
book
copy,
{},
Lib;
20
9
• f16: Imposing a fine,
{the
loan
8
15
16
term is exceeded,
the lost 10
21
book, or the damaged
book},
18
19
14
Lib;
12
22
13
• f17: Returning the book copy
to aafter
book fund, {}, Lib;
• f18: Paying a fine, {imposed
fine}, R;
• f19: Closing a fine, {paid fine},
Lib;
17
28
27
1
2
25
28
Illustration:
The
Library
TFM
(2)
3
4
5
1
26
•6 Functional Features25
23
24
17
7
9
8
15
16
19
14
13
before
2
18
24
– 11
f13: Taking back a book26copy, {}, Lib;
17
– f14: Checking the
20 term of loan of a
book copy, {}, Lib;
– f15: Evaluating the condition
of a book
15
16
10copy, {}, Lib;
21
2
8
1
• Case 1:
14
12
– r13-14: C= f13,22
E= f14, N=true, S=true,
Refs = empty set;
• Case 2:
3
after
– 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
1
27
1
2
25
28
Illustration:
The
Library
TFM
(3)
3
4
5
1
23
24
26
17
8
15
16
19
14
13
before
2
• Functional Features
25
24
6
– f14: Checking the term of loan of a book copy, {}, Lib;
26
11
7
– f15: Evaluating the condition of a book copy, {},17
Lib;
20 loan term is exceeded, the
9 – f16: Imposing a fine, {the
lost book, or the damaged book}, Lib;
– f18:
10 Paying a fine, {imposed fine}, R; 15
21 fine}, Lib;
– f19: Closing a fine, {paid
18
• Case 3:
– 12
r14-16: C= f14, E= f16,22
N= false, S=true,
3
2
8
16
1
14
1
Refs = {r15-16; OR};
– r15-16: C= f15, E= f16, N= false, S= true,
Refs = {r14-16; OR};
after
• 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
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
Illustration: The Library TFM (5)
Row
1
2
3
4
5
6
7
f14
0
0
0
1
1
1
1
f15
0
0
1
0
0
1
1
f16
0
1
1
0
1
0
1
f17
0
1
1
0
1
1
0
Necessary
false
true
true
false
true
true
false
Sufficient
false
true
true
false
true
true
false
• Case 5:
– r14-17’: C= f14, E= f17, N= true, S = false, Refs = {r15-17’, ¬r1617’, 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’,¬r1617’, 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’, ¬r1517’, AND} XOR {r15-17, ¬ r14-17’, AND} XOR { r14-17’, ¬ r15-17’,
AND}; see rows 2, 3, and 5.
21
The Source TFM “Before” and The
Corresponding UML Activity Diagram
Before
13
Take back a book copy
14
Check term of loan of book copy
[the loan term is exceeded]
15
Evaluate condition of book copy
16
[lost book OR damaged book]Impose fine
Return book copy to book fund
17
22
The Source TFM “After” and The
Corresponding UML Activity Diagram
After
13
Take back a book copy
Evaluate condition of book copy
Check term of loan of book copy
¬r14-16 OR ¬r15-16
¬r14-17’ AND ¬r15-17’ AND r16-17
15
[lost book OR damaged book]
14
[the loan term is exceeded]
¬r15-17' AND r14-17' AND r16-17'
Impose fine
16
r15-17' AND ¬r14-17' AND r16-17'
r15-17' AND r14-17' AND ¬r16-17'
Return book copy to book fund
17
23
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
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
Thank You for Attention !
26