Formal Analysis of Problem Domain Workflows

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

2. 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 problemdomainanalysiscan be improved by using Topological Functioning Model (TFM) • This research introduces a new element in TFM – logical relations which hold animportant information required to transform TFM into other diagram types (e.g., Activity or Use Case diagrams) 2

3. TFM withinModelDrivenArchitecture (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 definesthree specification viewpoints and their corresponding models: • Computation Independent Model (CIM) • Platform Independent Model (PIM) • Platform Specific Model (PSM) code ? CIM PIM PSM ? Activitydiagram TFM 3

4. Componentsof TFM • TFM consistsofthefollowingcomponents: • Functionalfeatures • Topologicalrelationships (i.e., cause-and-efffectrelationships) • Preconditions • Postconditions • Logicalrelations 4

5. FunctionalFeatures: Definition • Representsaction (i.e., functions) of a problemandsolutiondomain • Eachfunctional feature Xid is specified by unique tuple: • Xid = <Id, A, R, O, PrCond, PostCond, E, Cl, Op>, where • Id isanunique identifier of functionalfeature, • 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

6. FunctionalFeatures: Example • Informalproblemdomaindescription: • «(..) If import shouldbe performed from source data base, then schedulerreads all data from source data base by using query statement given in configuration file. After all datais read, schedulerchecks if read data structure is according to specification. (..)» • Duringinformaldesciptionanalysisnouns are denoted by italic, verbs are denoted by bold, and action preconditions (or postconditions) are underlined • Functionalfeatures: 6

7. TopologicalRelationships • Reflectscause-and-effectrelationshipsbetweenfunctionalfeatures • Relatescauseandeffectfunctionalfeatures • Directedfromcausefunctionalfeature to effectfunctionalfeature • EachtopologicalrelationshipTidisanduniquetuple: • Tid = <Id, Xc, Xe, Lout, Lin>, where • Id – unique identifier of topological relation, • Xc – cause functional feature, • Xe – effect functional feature, • Lout – set of logical relationships between topological relationships on outgoing arcs of cause functional feature Xc (optional), and • Lin – set of logical relationships between topological relationships on incoming • Representedas arcs of a directed graph that are oriented from a cause vertex to an effect vertex 7

8. Exampleof TFM 8

9. Pre-and Post- Conditions • Each precondition and postcondition is a condition Cid described by unique tuple: • Cid = <Id, Cond, oCond>, where • Id – identifier of condition, • Cond – condition or an atomic business rule, and • oCond – identifier of opposite condition,i.e., Ci = ¬Cj • Condition isconsidered as an atomic business rule. • Allows to reasonaboutproblemandsolutiondomainfunctioningcharacteristics • Decisionmaking • Paralellactivities 9

10. LogicalRelations • Logical relation Lid shows the logical relationship between two or more topological relationships Tid • It specifies: • conjunction (and), • disjunction (or), and • exclusive disjunction (xor) • The type of logical relation denotes system functioningbehavior • Each logical relation is a unique tuple: • Lid = <Id, T, Rt>, 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

11. ExampleofLogicalRelations 11

12. LogicalRelationsLout • Depending on the relationship type of logical relation on outgoing topological relationships Tid from cause functional feature Xc, system execution behaviour is defined as follows: • and– system executes in parallel by executing all functional features Xe of topological relationships Tidparticipating in this logical relation Lid, • or– system can be executed in parallel by executing one, part of or all functional features Xe of topological relationships Ti participating in this logical relation Lid, and • xor– only one functional feature Xe of topological relationships Tid participating in this logical relation Lid is executed. • The rules for identification of logical relations Lout between outgoing arcs of functional features are basedonanalysisofpreconditionsofeffectfunctionalfeatures. 12

13. LogicalRelationsLin • Depending on the relationship type of logical relation on incoming topological relationships Tid of effect functional feature Xe, system execution behavior is defined as follows: • and– system is executing in parallel thus effect functional feature Xe can be executed only when all direct predecessor functional features (i.e., all cause functional features Xc in the distance d=1) of topological relationships Ti participating in logical relation Lid are executed, • or– system can be executing in parallel by executing one, part of or all cause functional features Xc of effect functional feature Xe at the distance d=1 of topological relationships Ti participating in this logical relation, and • xor– only one cause functional feature Xc of effect functional feature Xe at the distance d=1 of topological relationships Tid participating in this logical relation Lid is executed. • Relation type of logical relation Lin is denoted by corresponding logical relation Lout and the inputs and outputs of TFM 13

14. ExampleofLogicalRelationsIdentification (1) • To better illustrate identification of TFM logical relations a case study is used in which an enterprise data synchronization system is developed 14

15. ExampleofLogicalRelationsIdentification(2) To better understand identification of logical relations a small fragment of TFM is used consisting of four functional features: • C1= ¬C2→exclusivedisjunctionbetweentopologicalrelationships19→20 and 19→22 • Functionalfeature 25 has no preconditions → conjunctionbetween topological relationship 19→20 and 19→25, and 19→22 and 19→25. 15

16. ExampleofLogicalRelationsIdentification(3) 16

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

18. Exampleof TFM to ActivityDiagramTransformation 18

19. 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

20. ThankYouforAttention!