This work has been supported by the European Social Fund within the project «Support for the implementation of doctoral studies at Riga Technical University» Uldis s Doni nins ns Janis Osis ICEIS 2011, June 8-11, 2011 - Beijing, People’s Republic of China
Transformation from model to model takes significant place in Model Driven Architecture (MDA) MDA considers system from three viewpoints: ◦ computation independent, ◦ platform independent, and ◦ platform specific Despite the fact that each viewpoint has its own representing model, the transformation between CIM and PIM is fuzzy ◦ Reason of this might be that there is an opinion that requirements modeled in CIM often lack a good structure and therefore it is not possible to automate the CIM-to-PIM transformation
Lack of traceability within the CIM and lack of transformation from CIM to PIM leads in manual CIM-to-PIM conversion ◦ manual conversion depends much on designers’ personal experience and knowledge and therefore the quality of PIM can not be well controlled The structure quality of CIM can be improved by using Topological Functioning Model (TFM) as model to represent the CIM The main idea of this paper is to explore a case study of applying topological modelling approach in software project
Topological modelling approach for business systems modelling and software systems designing is a model-driven approach It combines Topological Functioning Model (TFM) and its formalism with elements and diagrams of TopUML (a profile based on Unified Modelling Language UML) ◦ Computation independent viewpoint is modeled and represented by TFM ◦ Platform independent viewpoint is modeled and represented by TopUML diagrams
Topological modelling approach consists of five steps: ◦ Construction of Topological Functioning Model ◦ Functional requirements validation ◦ Elaboration of problem domain objects graph ◦ Acquisition of sequence diagrams ◦ Development of Topological Class Diagram Information about changes Informal System Description Definition of Functioning Definition of Topology (System Theoretical Aspect) (Mathematical Aspect) Topological Functioning Model Topological Class Diagram
Main idea of this paper is to explore a case study of applying topological modelling approach in software project In this software project a service application was developed: ◦ Service application is aimed to synchronize enterprise employee data ◦ Synchronization is done by taking data from multiple data sources and placing in one central data storage ◦ The case study includes full software development life cycle at the time when this paper was written the implementation phase was completed and the software was forwarded to the maintenance phase, so the case study described in paper covers full implementation phase In order to better illustrate topological modelling approach and our case study, the paper is divided in two large parts: ◦ The first part gives theoretical basis for topological modelling approach. ◦ The second part explores in detail case study by showing how all the steps of topological modelling approach are implemented
Construction of TFM consists of three activities. Activi vity ty 1 : Definition of physical or business functional characteristics ◦ Definition of functional features is performed by problem domain analysis The problem domain needs to be fixed in the form of informal description of the business system functioning ◦ Each functional feature is a tuple <A, R, O, PrCond, PostCond, E, Cl, Op>
«(..) After configuration data is read, scheduler checks ks if import from source data base should uld be performed ormed. Import from source data base is perform ormed ed at specified time which is given in configuration data as parameter . If import shoul uld be p perform ormed ed 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. Data from source data bases has following structure: surname, forename, job title, address, e- mail address, telephone number, gender, start date, expiry date, department, and company code. If data structure is according to specification, then scheduler puts the read data into temporal internal table . After converting read data to temporal internal table every row from this table is import orted ed into target data base . (..)» During informal desciption analysis nouns are denoted by italic , verbs are denoted by bold, and action preconditions (or postconditions) are underlined
As a result of this action a set of functional features are defined At the lowest abstraction level one functional feature should describe only one atomic business action Atomic business action means that it cannot be further divided into set of business actions By using the topological characteristic (continuous mapping) of TFM, the abstraction level of functional features can be raised at any time when needed Within case study has been identified and defined 30 functional features Inner r or ID ID Object ct action Preco condit nditio ion Entity Externa rnal Reading all data from source If import should be 5 Scheduler Inner data base performed from source data base Checking if read data structure 6 Scheduler Inner is according to specification
Action ion 2 : Introduction of topology Θ, which means establishing cause and effect relations between functional features ◦ Cause-and-effect relations are repre- 2 3 9 sented as arcs of a 18 17 16 directed graph that 1 5 10 11 are oriented from a 4 6 12 14 15 cause vertex to an effect vertex 7 13 30 8 20 21 26 29 24 19 25 27 28 22 23
Topological Functioning Model (TFM) is a system functioning description embedded in topological space in form of a directed graph G( X, Θ ) taking into consideration topological and functional features ◦ X – functional features ◦ Θ – topology (cause and effect relations) between functional features TFM has a strong mathematical base ◦ Topological characteristics – connectedness, closure, neighborhood, and continuous mapping ◦ Functional characteristics – cause-effect relations, cycle structure, and inputs and outputs
Action ion 3 : Separation of the topological functioning model ◦ Separation is performed by applying the closure operation over a set of system’s inner functional features ◦ Construction of TFM can 2 3 9 be iterative 17 16 Iterations are needed if the 5 11 information collected for TFM development is 6 12 14 15 incomplete or inconsistent 7 13 or there have been introdu- ced changes in system 8 20 functioning or in software 26 29 24 19 25 requirements 27 28 22
After construction of TFM, the next step is the validation of functional requirements in conformance with the constructed TFM Functional features specify functionality that exists in the problem domain, but requirements specify functionality that should exist in the solution domain Therefore it is possible to make mappings between requirements and functional features of the TFM As a result As t of require rement ents s validati tion on, , both TFM and r require rement ents s are checked ed It is suggested to represent requirement mappings between functional requirements and functional features by using arrow predicates (an arrow predicate is a construct in universal categorical logic) There are five types of mappings and corresponding arrow predicates defined for ◦ mapping requirements onto TFM: One to One Many to One One to Many One to Zero, and Zero to One
Enterprise data synchronization system has following functional requirements: ◦ FR1 R1- Employee data synchronization should be done between input data sources and target data source. This requirement includes: FR1/1 /1 - By starting synchronization process a configuration information should be taken from configuration file; FR1/2 /2 - If needed, data from source data base should be taken; FR1/3 /3 - Data should be taken from import files in CSV format; FR1/4 /4 - If import CSV file is with wrong data structure, the processing of particular file should be skipped and faulty import file should be logged; FR1/5 /5 - All data obtained from either source data base or import files should be placed in target data base; and FR1/6 /6 - When importing data in target data base all rows from source data should be logged together with import status for each particular data row
Recommend
More recommend
