Formal Analysis of Problem Domain Workflows Uldis Donins Riga Technical University Baltic DB & IS 2012, July 8-11, Vilnius, Lithuania This work has been supported by the European Social Fund within the project «Support for the implementation of doctoral studies at Riga Technical University».

Introduction The way software is built still remains surprisingly primitive (Jones, 2009) –by meaning that major software applications are cancelled, overrun their budgets and schedules, and often have hazardously bad quality levels when released This is due that the very beginning of software development lifecycle is too fuzzy and lacking a good structure The structure quality of problem domain analysis can be improved by using Topological Functioning Model (TFM) This research introduces a new element in TFM – logical relations which hold an important information required to transform TFM into other diagram types (e.g., Activity or Use Case diagrams) 2

TFM within Model Driven Architecture (MDA) The main purpose of the MDA is to separate the viewpoints in specifications and strengthen the analysis and design role in the project development MDA defines three specification viewpoints and their corresponding models: –Computation Independent Model (CIM) –Platform Independent Model (PIM) –Platform Specific Model (PSM) CIMPIMPSM code ? ? TFM Activity diagram 3

Components of TFM TFM consists of the following components: –Functional features –Topological relationships (i.e., cause-and-efffect relationships) –Preconditions –Postconditions –Logical relations 4

Functional Features: Definition Represents action (i.e., functions) of a problem and solution domain Each functional feature X id is specified by unique tuple: –X id =, where Id is an unique identifier of functional feature, A is object action R is result of this action O is an object affected by this action PrCond is a set of preconditions PostCond is a ser of postconditions E is an entity involved in execution of this activity Cl is a class which will include action A Op is an operation that implements action A Reflected as vertices of a directed graph 5

Functional Features: Example Informal problem domain description: –«(..) If import should be performed from source data base, then scheduler reads all data from source data base by using query statement given in configuration file. After all data is read, scheduler checks if read data structure is according to specification. (..)» –During informal desciption analysis nouns are denoted by italic, verbs are denoted by bold, and action preconditions (or postconditions) are underlined Functional features: IDObject actionPreconditionEntity Inner or External 5Reading all data from source data base If import should be performed from source data base SchedulerInner 6Checking if read data structure is according to specification SchedulerInner 6

Topological Relationships Reflects cause-and-effect relationships between functional features –Relates cause and effect functional features –Directed from cause functional feature to effect functional feature Each topological relationship T id is and unique tuple: –T id =, where Id – unique identifier of topological relation, X c – cause functional feature, X e – effect functional feature, L out – set of logical relationships between topological relationships on outgoing arcs of cause functional feature X c (optional), and L in – set of logical relationships between topological relationships on incoming Represented as arcs of a directed graph that are oriented from a cause vertex to an effect vertex 7

Example of TFM 8

Pre- and Post- Conditions Each precondition and postcondition is a condition C id described by unique tuple: –C id =, where  Id – identifier of condition,  Cond – condition or an atomic business rule, and  oCond – identifier of opposite condition, i.e., C i = ¬C j Condition is considered as an atomic business rule. Allows to reason about problem and solution domain functioning characteristics –Decision making –Paralell activities 9

Logical Relations Logical relation L id shows the logical relationship between two or more topological relationships T id It specifies: –conjunction (and), –disjunction (or), and –exclusive disjunction (xor) The type of logical relation denotes system functioning behavior Each logical relation is a unique tuple: –L id =, where Id – identifier of logical relationship, T – set of topological relationships belonging to this logical relationship, and Rt – logical relationship type (and, or, xor). Between topological relationships exist two kinds of logical relationships – one kind is between arcs that are outgoing from functional features and the other kind is between arcs that are incoming to functional features. 10

Example of Logical Relations 11

Logical Relations L out Depending on the relationship type of logical relation on outgoing topological relationships T id from cause functional feature X c, system execution behaviour is defined as follows: –and – system executes in parallel by executing all functional features X e of topological relationships T id participating in this logical relation L id, –or – system can be executed in parallel by executing one, part of or all functional features X e of topological relationships T i participating in this logical relation L id, and –xor – only one functional feature X e of topological relationships T id participating in this logical relation L id is executed. The rules for identification of logical relations L out between outgoing arcs of functional features are based on analysis of preconditions of effect functional features. 12

Logical Relations L in Depending on the relationship type of logical relation on incoming topological relationships T id of effect functional feature X e, system execution behavior is defined as follows: –and – system is executing in parallel thus effect functional feature X e can be executed only when all direct predecessor functional features (i.e., all cause functional features X c in the distance d=1) of topological relationships T i participating in logical relation L id are executed, –or – system can be executing in parallel by executing one, part of or all cause functional features X c of effect functional feature X e at the distance d=1 of topological relationships T i participating in this logical relation, and –xor – only one cause functional feature X c of effect functional feature X e at the distance d=1 of topological relationships T id participating in this logical relation L id is executed. Relation type of logical relation L in is denoted by corresponding logical relation L out and the inputs and outputs of TFM 13

Example of Logical Relations Identification (1) To better illustrate identification of TFM logical relations a case study is used in which an enterprise data synchronization system is developed 14

Example of Logical Relations Identification (2) IDObject actionPrecondition 19Checking if data from a particular row already exists in target data base - 20Updating existing data in target data base C 1 : If data from the particular row exists 22Insert new data in target data baseC 2 : If data from the particular row does not exist 25Logging data row from temporal table - To better understand identification of logical relations a small fragment of TFM is used consisting of four functional features: C 1 = ¬C 2 → exclusive disjunction between topological relationships 19→20 and 19→22 Functional feature 25 has no preconditions → conjunction between topological relationship 19→20 and 19→25, and 19→22 and 19→25. 15

Example of Logical Relations Identification (3) 16

Application of TFM Logical Relations Application of TFM logical relations within topological functioning modelling allows formally developing Activity diagrams representing workflows in problem domain. 17 XOR AND

Example of TFM to Activity Diagram Transformation 18

Conclusions This research introduces a new element into TFM – logical relations –Within each logical relation can participate two or more logical relationships –Each logical relation has a type – conjunction (and), disjunction (or), or exclusive or (xor) –Logical relations exist between topological relationships and denote the system functioning behavior. Logical relations in TFM are crucial when transforming TFM into other diagrams –Thus the analysis of logical relations takes an important part of TFM development and problem domain specification –Depending on logical relation type system functioning behavior is specified by means of decision making, merging, forking, and joining. In addition this research shows that by adding additional efforts at the very beginning of software development life cycle it is possible to create a model that contains sufficient and accurate information of problem domain. –By “sufficient” meaning that this model can be transformed into other diagrams without major re-analysis of problem domain and –By “accurate” meaning that the model precisely reflects the functioning and structure of the system. 19

Thank You for Attention!