Consistency checking of UML business model/ Verslo modelio, isreiksto UML kalba, darnos tikrinimas.
UML is dominant modelling language for specifying, designing and documenting artefacts of business system (Chen and Motet 2009). Complete conceptual model includes a series of different aspect models for example, static structure model, states machines and etc. (Gudas 2009). The developed multiple view (aspect models) of IS can contain inconsistent or even contradictory specifications. Consistency means that the structures, features and elements that appear in one model are compatible and in alignment with the content of other models (Rozanski and Woods 2005). The consistency problem is widely discussed in the publications of recent years. It shows the importance of the question of ensuring consistency of IS model in design phase. Model consistency issue is particularly important within the scope of model-driven engineering (MDE) (Lucas et al. 2009). MDE puts models into the centre of the IS development process as the source of transformation to platform-specific models, which are used for code generation (Mokhati et al. 2007). Unambiguous models are necessary for the successful accomplishment of the tasks of model transformation and finally for code generation (Berkenkotter 2008). Correct working of software systems is very important for enterprises, because programs help to manage business systems, e.g. indicating problematic transport zones (Jakimavicius and Burinskiene 2009), monitoring sewage and analysis of water recourses (Dzemydiene and Dzindzalieta 2010; Kalibatiene and Vasilecas 2010) and etc.
The objective of this paper is to improve the consistency of IS models, expressed in UML. The main task is to extend the existing approaches of ensuring UML models consistency. Several consistency rules of UML model are presented. In the paper the tool supporting the proposed approach is introduced and the process of automated UML model checking is demonstrated.
The paper is organised as follows. Section 1 introduces the issue to be analysed. Section 2 briefly presents consistency types and approaches for ensuring UML model consistency. Section 3 introduces the suggested approach of ensuring UML model consistency based on set of rules and its implementation in NoMagic MagicDraw UML tool. Section 4 presents the experiment performed to evaluate the suggested approach. Section 5 concludes the paper.
2. Related Work
Consistency concept, its types and approaches of checking UML model consistency are presented in the section.
Several definitions of model consistency appear in existing literature. In general consistency means that the structures, features and elements that appear in one model are compatible with the content of other models (Rozanski and Woods 2005).
Consistency can be classified to vertical (inter-model), horizontal (intra-model), evolution, semantic or syntactic consistency.
Vertical or inter-model consistency is checked at different levels of abstraction between different aspect models (Lucas et al. 2009; Usman et al. 2008). Horizontal or intra-model consistency can be defined as matching ratio between models at the same level of abstraction (ISO/IEC 1997). Evolution consistency is validated between different versions of the same aspect model (Van Der Straeten et al. 2003).
All mentioned types of consistency can express syntactic or semantic conformance of different aspect models. Syntactic consistency expresses matching of model to the specifications of metamodel. Semantic consistency requires that model would be compatible to semantic meanings defined by metamodel (Lucas et al. 2009; Usman et al. 2008).
In this paper, we are concentrated on improving models syntactic horizontal consistency. The examples of horizontal consistency requirements are:
-- Inv1: Call message of sequence model should have operation assigned. It means the operation of object called in sequence model should appear in class model.
-- Inv2: Private operation of class model can not be called from foreign classifier in sequence model. Inv2 extends requirement Inv1. It requires that called operation in sequence model, that appear in class model would not be private. Because operation of private visibility is visible only to owner of this operation and foreign classes can not see and call it.
In the following section we discuss several issues that are also important for the area of consistency: the way how various consistency requirements can be expressed, the way how IS model is checked and etc.
2.2. Approaches in Ensuring UML Model Consistency
In this section approaches of ensuring UML model consistency are presented. UML was chosen because it is likely the most popular modelling language (Silingas and Butleris 2009) and there are many modelling tools supporting UML (Shen, Compton, Huggins 2002). The second reason UML was chosen it was developed by OMG (Object Management Group), which also introduce MDA (Model Driven Architecture). Consistency of UML model is especially important in MDA, for automatic transformation initial model to specific model and finally code generation tasks.
Approaches of checking UML model consistency are compared according to the following parameters:
-- Paradigm of ensuring consistency of UML model shows general approach used for ensuring consistency;
-- Technique, language or approaches used in the analyzed paper to ensure consistency;
-- Scope of constrained model elements shows if constraint is defined for
* one aspect model,
* relationship of different aspect models. Constraint on relationship requires that element of one aspect model would be in another aspect model too;
-- Abstraction level used for ensuring consistency defines if consistency is ensured
* at metamodel level of UML,
* at formal language level (consistency conflicts are detected by inference mechanism of formal language).
-- CASE tool used for the implementation and testing of suggested approach. The comparison of analyzed approaches on defined parameters is provided in the Table 1.
The analyzed approaches of checking UML model consistency can be divided to two groups. First group of approaches based on constraints. Constraints are defined for UML metamodel and UML models are checked according to these constraints. The authors of papers (Chen and Motet 2009; Berkenkotter 2008; Shen et al. 2002; Egyed 2007) suggest defining constraints for every different aspect model. But constraints among different models are not defined. The Eyged approach (Egyed 2007) uses constraints on relationships of different aspect models. But the defined consistency rules are hard coded to UML Analyzer tool and can not be analyzed. The second group of approaches is based on formal models (Mokhati et al. 2007; Van Der Sraeten et al. 2003; Pakalnickiene and Nemuraite 2007). Authors of these approaches propose transformation of semi-formal UML models to formal models. In this case it is suggested to detect consistency conflicts using inference mechanism of formal language. Despite of formal models are more precise, but they are less understandable in comparison with semi-formal languages, which can be presented using diagrams (Vavpotic and Bajec 2009).
The analysis of related work shows that the approaches solve inconsistency of models problem in some extent. Formal models are often too difficult to understand to be used in practice. Semi-formal UML models are widely used, but their constraints are proposed only for one model, relationships among models are not defined. The Egyed approach (Egyed 2007) includes constraints on relationships of different aspect models, but the defined consistency rules are hard coded to CASE tool and are not expressed in formal language, which would be independent from platform specific features. Despite of many results that have been achieved in the field of ensuring models consistency is still open and relevant.
The authors of this paper suggest extending the approach based on constraints of UML metamodel by adding consistency rules among different aspect models. Consistency rule means constraint on relationship of different aspect models. It is suggested consistency rules to express in OCL in order the approach would be more general and more applicable in various tools.
The following section presents the suggested approach in detail.
3. The Approach in Ensuring UML Model Consistency Based On the Rules
The following sections describe the suggested general framework of IS model, approach of ensuring UML model consistency, explain several proposed consistency rules in detail and presents the implementation of the approach.
3.1. The Suggested General Framework of IS Model
A review of existing literature indicates a wide variety of consistency definitions. Sometimes consistency term is used for expressing conformance of diagrams, sometimes of models. In this section the authors of paper suggest general framework of IS model. The main purpose of this suggestion is contributing more clearness to concept of consistent model, emphasising IS model relationships with consistency, aspect models and diagrams concepts.
Fig. 1 shows the place of horizontal, evolution and vertical consistency in IS model graphically. Remark that all horizontal relationships of models are not displayed for reasons of clarity.
IS model consists of several different aspect models. Developing models of higher level is based on lower level models. The authors of (Bajec et al. 2003; Bajec and Krisper 2005) propose method how to keep motivation aspect model (business rules) at the business level inline with the rules that are implemented at the system level.
[FIGURE 1 OMITTED]
Every aspect model can be visualised by several different diagrams. Every diagram is based on model. It means if model is consistent, diagram also is consistent. Therefore the main issue is to ensure consistency of IS model.
The presented general framework of IS model enables clear conception of horizontal, vertical and evolution consistency of IS model and diagrams.
3.2. The Suggested Approach of Ensuring UML Model Consistency
In this section we present our approach of ensuring UML model consistency. The some details of approach are presented in Table 2.
It is necessary to mention that constraints are also defined in specification of UML metamodel (OMG 2007), but they constrains only separate aspect model. In our suggested approach constraints are on relationships of different aspect models and separate aspect models too.
The reasons why we suggested:
-- to check consistency of UML model,
-- to define constraints on relationships at metamodel level,
-- to express consistency rules in OCL are explained bellow.
We proposed checking consistency of IS model, which consists of several different aspect models, presented in semi-formal language, in this case in UML:
-- Do not perform additional UML model transformation to formal model task. The formal model allows detecting inconsistencies, by inferences mechanisms of formal language, but transformation task requires additional time,
-- Besides UML is more understandable and more usable in practice than formal modelling languages.
It is also suggested defining constraints on relationships of different aspect model at metamodel level (Vasilecas and Dubauskaite 2009). Sometimes constraints are called consistency rules. The ensuring consistency in higher level makes the consistency rules more usable, because meta-level constraints are independent from specific implementation platform (Bajec and Vavpotic 2008). It is necessary to stress that at metamodel level we suggest defining only general constraints on different aspect models and their relationships, while domain specific consistency rules are defined for every model of specific IS. More information about domain specific rules are presented the papers (Vasilecas and Lebedys 2007; Nemuraite et al. 2008; Smaizys and Vasilecas 2009). The authors of (Vasilecas and Lebedys 2007) research derivation of domain rules from IS models, and usage them for data validation. While the paper (Nemuraite et al. 2008) presents method for checking aspect model based on rules.
We suggested to express consistency rules of UML model in OCL. The main reasons for choosing this language are:
-- OCL is part of UML. According to OMG OCL specification Object Constraint Language is used to describe expressions on UML models (OMG 2006),
-- OCL is formal language. It means the constraints can be interpreted unambiguously. The structure, relationships of elements of proposed approach is shown in Fig. 2 using UML class diagram.
Consistency of IS model, expressed in UML, is checked according to defined consistency rules. Consistency rules describe conditions that all UML models must satisfy them to be considered valid (Egyed 2007). Consistency rules, expressed in OCL, constrain every aspect model, and relationships of different aspect model. Aspect model is part of IS model. Consistency rules are defined for UML metamodel. IS model also conforms to UML metamodel. Diagrams, that visualizes all or part of IS model, are based on UML metamodel too. Diagrams are included to our suggested approach of IS consistency, because developer often models information system using diagrams, but in order diagrams would present unambiguous aspects of IS system, first of IS model should be consistent.
[FIGURE 2 OMITTED]
The process of checking IS model consistency is presented by authors of this paper (Dubauskaite and Vasilecas 2009b). The main activities are checking model according consistency rules and appending list of violations of consistency. The removing of detected consistency conflicts can allow to improve consistency of UML model.
Detecting consistency conflicts in design phase can help to minimize the cost of correction of inconsistencies during the development process compared with cost of correction of conflicts detected in late phases of IS development.
The novelty of the work lies in the fact we suggest new method for ensuring consistency of information system model:
-- we proposed to check consistency of original semi-formal UML model,
-- the approach includes both constraints (consistency rules) on relationships of different aspect model and constraint on different aspect models,
-- these consistency rules are expressed explicitly in OCL,
-- consistency rules are defined for UML metamodel.
3.3. Consistency Rules of UML Model
In this section we provide three examples consistency rules that illustrate the usage of the suggested method. According to our suggested the method of ensuing consistency of IS model consistency rules have to be defined for every aspect model and for relationships of different aspect models.
Examples of suggested consistency rules for relationships of different aspect model elements are presented in the Table 3. Consistency rule for relationship of different aspect model defines coherence of elements from different aspect models. The main aspects
of information system are static and behaviour aspect. Therefore consistency rules are provided for relationships of static and behaviour models. According to suggested approach consistency rules are defined for metamodel of UML. The related elements of static structure model and behaviour structure models are defined in 2nd and 3rd column of Table 3. The 1st column of Table 3 shows identification number of consistency rule, which is defined in column 4.
Consistency rule ID1 requires defining transition of states by specifying operation, which execution causes the changes of state.
The Fig. 3 bellow shows elements of UML metamodel for IS Class and Protocol State Machines models that are associated by consistency rule ID 1. Dashed lines with arrows present relationships of UML metamodel and IS model. Elements of different aspect models associated by consistency rule 1 are showed using dashed line without arrows. According to UML metamodel, which part is in Fig. 3 operation is not mandatory for protocol transition. But in practical situations it is need to know what operation execution causes the transition of states.
After analysis of UML metamodel specification and specific information system models we come to a conclusion, that it is necessary to define operation, which determine movement of object from one state to another state. Operation is defined in class model. Therefore consistency rule ID1 associates two different aspect models: class and state models.
[FIGURE 3 OMITTED]
Consistency rule ID2 constrains a protocol state machine. This model presents the possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions (OMG 2007). In this manner context--class, which operations can be called and their execution determines changes of states of object have to be defined. The source of this constraint is UML superstructure specification provided by OMG (OMG 2007).
The Fig. 4 shows elements of UML metamodel and IS model, associated by consistency rule ID 2.
According to consistency rule ID3 the type of lifeline should be defined.
Type of lifeline shows associated class. When matching class in known then can be checked:
-- If message of lifeline has associated operation of class (Inv1),
-- If called message has public visibility (only public operations can be called by other objects) (Inv2) and etc.
We derived consistency rule ID3 concluding results of analysis of UML metamodel specification and MagicDraw UML tool. The constraints enumerated above this paragraph (Inv1 and Inv2) are implemented in MagicDraw UML tool. They illustrate the necessity of our suggested consistency rule ID3. According to UML metamodel (Fig. 5) lifeline can be associated or not associated with a class (class is type of object). Therefore violation of consistency rule ID3 should be warning, but not error.
More details about our suggested approach and consistency rules are provided in (VeTIS 2009).
The software prototype, which implements our proposed approach and includes consistency rules, is presented in next section.
[FIGURE 4 OMITTED]
[FIGURE 5 OMITTED]
3.4. The Implementation of Suggested Approach
There are commercial and non-commercial tools supporting checking of IS models. The known possibilities to check UML model consistency using MagicDraw UML and other CASE tools was presented in our paper (Dubauskaite and Vasilecas 2009a). The functionality of analysed tools is limited to validate only one aspect model and they usually do not allow ensuring consistency among several different aspect models. Therefore MagicDraw UML tool was extended with UML consistency constraints module, which contains consistency rules of different aspect models. MagicDraw UML is extensible tool, it can incorporate new consistency rules not only as module but also as plug-in.
Fig. 6 provides the specification of consistency rule ID1.
Consistency rule is expressed in OCL 2.0 (Specification part of Fig. 6), defined for element ProtocolTransition of UML metamodel (Constraint element part of Fig. 4). Implemented consistency rule ID1 relates state machine (more exactly transition of states) and class models (operation of class).
All implemented consistency rules are presented in documentation of project of business rules solutions for IS development (VeTIS 2009).
[FIGURE 6 OMITTED]
The tool do not automatically resolves consistency conflicts, because it does not know whether an inconsistency is tolerable or what choice of fixing inconsistencies is the best. However a tool can be assistant that help to find violations of consistency.
The usage of implemented prototype of consistency module of MagicDraw UML tool is presented in next section.
A simple experiment is presented in this section to illustrate usage of suggested approach and demonstrate the functionality of created software prototype.
First activity of UML model consistency checking process is developing of the method with consistency rules and implementation it in a CASE tool (Dubauskaite and Vasilecas 2009b). Our suggested constraints, presented in section 3.3 are implemented as module of MagicDraw UML tool.
The prototype of UML consistency constraints module can be reused in test or real project by importing the developed consistency module to standard MagicDraw UML tool (Fig. 7).
Second step of ensuring consistency of UML model is validating developed concrete IS model according to every consistency rule. If consistency rule is detected list of consistency violations is appended with message of error or warning. Left column of Fig. 8 provides UML model, developed using MagicDraw UML 15.5 tool.
The UML test model consists of static structure model and behaviour model. Behaviour model is visualized by protocol states diagram. The diagram represents possible states of a class Door. Door is a part of lift business system. Accurate modelling of business system is necessary in order software, which is developed or generated automatically according to model, manages business system correctly. The process of checking of business model, expressed using UML, is executed automatically (activated by command validate model). The detected consistency conflicts are shown in bottom of right column in validation results section of Fig. 8.
[FIGURE 7 OMITTED]
The last step of ensuring consistency of UML model is modifying of IS model according to detected consistency conflicts.
If method close of class Door is added to transition of door protocol states model then consistency of lift system model would be improved.
The experiment shows that the suggested approach is able to detect inconsistencies automatically in such way makes easer work of designer. Beside detected and fixed consistency conflicts in earlier phases of IS life cycle allows to reduce cost of IS development.
[FIGURE 8 OMITTED]
5. Conclusions and Future Work
The analysis of related work showed that the majority of the existing approaches use constraints for one aspect model. Second biggest group of approaches suggest the using of the formal languages, nonetheless the fact that formal techniques are not yet very popular in the industrial software development community. Formal models are often not enough understandable for software engineers. Semi-formal UML models are widely used, but their constraints usually are for only one model, integrity requirements and constraint for relationships of different aspect models usually are not defined. The approach proposed by Egyed (Egyed 2007) uses some constraints on relationships of different aspect models. But the defined consistency rules are hard coded to the CASE tool UML Analyser and are not formally expressed using language, which would be platform independent.
Despite of many results that have been achieved by different groups of researchers in the field, the issue of ensuring models consistency is still open and relevant.
Based on the researched performer we suggest approach of ensuring UML model consistency, which consist of four elements: (1) checking consistency of original semi-formal UML model, (2) includes constraints on relationships of different aspect models, (3) these consistency rules are expressed explicitly in OCL and (4) defined on metamodel of UML. Checking consistency of original UML model allows not performing additional task of UML model transformation to formal model, in such a way time for detecting consistency conflicts is shortened. UML is more understandable for IS engineers and more usable in practice than formal modelling languages. The suggested approach allows detecting consistency conflicts of different aspect models according to predefined constraints on relationships. Consistency rules expressed in OCL and defined on metamodel are unambiguous, more general and more applicable in various tools.
Our proposed approach was tested using some different consistency rules of static structure and behaviour aspect models and implementing them in consistency control module which was developed for MagicDraw UML tool (No Magic 2010). The experiment showed that usage of the suggested approach allows detecting inconsistencies of different aspects models.
The following step of research is expanding the approach by extending the set of the consistency rules. Next, we intend to create a method for fixing detected inconsistencies of UML model.
Received 22 April 2010; accepted 7 December 2010
Bajec, M.; Krisper, M. 2005. A methodology and tool support for managing business rules in organisations, Information Systems 30(6): 423-443. doi:10.1016/j.is.2004.05.003
Bajec, M.; Vavpotic, D. 2008. A framework and tool-support for reengineering software development methods, Informatica 19(3): 321-344.
Bajec, M.; Krisper, M.; Rupnik, R. 2003. Tracking Business Rule Evolution to Support Is Maintenance, in ICEIS 2003, 527-530.
Berkenkotter, K. 2008. Reliable UML Models and Profiles, Electronic Notes in Theoretical Computer Science (ENTCS) 217: 203-220. doi:10.1016/j.entcs.2008.06.050
Chen, Z.; Motet, G. 2009. A Language-Theoretic View on Guidelines and Consistency Rules of UML. Model-Driven Architecture Foundations and Applications, LNCS 5562: 66-81. doi:10.1007/978-3-642-02674-4_6
Chiorean, D.; Pasca, M.; Carcu, A.; Botiza, C.; Moldovan, S. 2004. Ensuring UML models consistency using the OCL Environment, Electronic Notes in Theoretical Computer Science (ENTCS) 102: 99-100. doi:10.1016/j.entcs.2003.09.005
Dubauskaite, R.; Vasilecas, O. 2009a. UML taisykliu modeliu darnos tikrinimo galimybes, naudojant MagicDraw UML ir PowerDesigner irankius [Checking Consistency of UML Models Using Magic-Draw UML and PowerDesigner Tools], in Adomenas, G. P.; Ceikiene, N.; Kulvietis, G. et al. (Eds.). Informatika: 12-osios Lietuvos jaunuju mokslininku konferencijos "Mokslas--Lietuvos ateitis" pranesimu rinkinys [Informatics: Proc. of the 12th conference of Lithuanian's researchers]. Vilnius: Technika (in press).
Dubauskaite, R.; Vasilecas, O. 2009b. Ensuring Models Consistency in the OMT, Booch, and OOSE Object-Oriented Methods, Information Sciences 50: 160-167.
Dzemydiene, D.; Dzindzalieta, R. 2010. Development of architecture of embedded decision support systems for risk evaluation of transportation of dangerous goods, Technological and Economic Development of Economy 16(4): 654-671. doi:10.3846/tede.2010.40
Egyed, A. 2007. Fixing inconsistencies in UML design models, in Proc. of the 29th International Conference on Software Engineering (ICSE), 292-301. doi:10.1109/ICSE.2007.38
Gudas, S. 2009. Enterprise Knowledge Modelling Domains and Aspects, Technological and Economic Development of Economy 14(2): 281-293. doi:10.3846/1392-8619.2009.15.281-293
ISO/IEC. 1997. Information Technology--Software quality characteristics and metrics--Part 3: Internal Metrics, International Organization for Standardization and International Electrotechnical Commission.
Jakimavicius, M.; Burinskiene, M. 2009. A GIS and multi-criteria-based analysis and ranking of transportation zones of Vilnius city, Technological and Economic Development of Economy 15(1): 39-48. doi:10.3846/1392-8619.2009.15.39-48
Kalibatiene, D.; Vasilecas, O. 2010. Ontology axioms for the implementation of business rules, Technological and Economic Development of Economy (16)3: 471-486. doi:10.3846/tede.2010.29
Lucas, F. J.; Molina, F.; Toval, A. 2009. A systematic review of UML model consistency management, Information and Software Technology 51: 1631-1645. doi:10.1016/j.infsof.2009.04.009
Mokhati, F.; Gagnon, P.; Badri, M. 2007. Verifying UML Diagrams with Model Checking: A Rewriting Logic Based Approach, in Proc. of the Seventh International Conference on Quality Software, 356-362. doi:10.1109/QSIC.2007.4385520
Nemuraite, L.; Ceponiene, L.; Vedrickas, G. 2008. Representation of business rules in UML&OCL models for developing information systems, Lecture Notes in Business Information Systems 15: 182-196. doi:10.1007/978-3-540-89218-2_14
No Magic. 2010. Magic Draw tool [cited 16 February 2010]. Available from Internet: <http://www.magicdraw.com/>.
OMG. 2006. OCL 2.0 Specification [cited 29 October 2009]. Available from Internet: <http://www.omg.org/spec/OCL/2.0/PDF>.
OMG. 2007. OMG Unified Modelling Language (OMG UML), Superstructure, v2.1.2, OMG Document: formal/2007-11-04 [cited 1 April 2009]. Available from Internet: <http://www.omg.org/docs/formal/07-11-02.pdf>.
Pakalnickiene, E.; Nemuraite, L. 2007. Checking of conceptual models with integrity constraints, Information Technology and Control 36(3): 285-294.
Rozanski, N.; Woods, E. 2005. Software System Architecture. London: Addison-Wesley. 546 p.
Shen, W.; Compton, K.; Huggins, J. K. 2002. A Toolset for Supporting UML Static and Dynamic Model Checking, in Proc. of the 26th International Computer Software and Applications Conference (COMPSAC 2002), Prolonging Software Life: Development and Redevelopment, Oxford, England, IEEE Computer Society, 147-152.
Silingas, D.; Butleris, R. 2009. Towards Implementing a Framework Modelling Software Requirements in MagicDraw UML, Information Technology and Control 38(2): 153-164.
Simmonds, J.; Bastarrica, M. C. 2005. Description Logics for Consistency Checking of Architectural Features in UML 2.0 Models. DCC Technical Report TR/DCC-2005-1, Departamento de Ciencias de la Computacion, Santiago, Chile.
Smaizys, A.; Vasilecas, O. 2009. Business Rules Based Agile ERP Systems Development, Informatica 20(3): 439-460.
Usman, M.; Nadeem, A.; Kim, T.; Cho, E. 2008. A Survey of Consistency Checking Techniques for UML model, in Proc. of 2008 Advanced Software Engineering and Its Applications, 57-62. doi:10.1109/ASEA.2008.40
Van Der Straeten, R.; Simmonds, J.; Mens, T.; Jonckers, V. 2003. Using Description Logic to Maintain Consistency between UML Models, in P. Stevens et al. (Eds.). "UML" 2003--the Unified Modeling Language. Modeling Languages and Applications. 6-th International Conference. San Francisco, CA, USA, October 2003. Proceedings 2863: 326-340.
Vasilecas, O.; Dubauskaite, R. 2009. Ensuring Consistency of Information System Rules Models, in Stoilov, T.; Rachev, B. (Eds.). Proc. of the International Conference on Computer Systems and Technologies "CompSysTech'09", VI.6.1-VI.6.8.
Vasilecas, O.; Lebedys, E. 2007. Application of Business Rules for Data Validation, Information Technology and Control 36(3): 273-277.
Vavpotic, D.; Bajec, M. 2009. An approach for concurrent evaluation of technical and social aspects of software development methodologies, Information and Software Technology 51(2): 528-545. doi:10.1016/j.infsof.2008.06.001
VeTIS. 2009. Business Rules Solutions for Information Systems Development. Project reg. No. B-07042, Lithuanian State Science and Studies Foundation.
Olegas VASILECAS. Prof., Dr Habil O. Vasilecas is full time Professor at the Information System Department, and senior researcher, and head of Information Systems Research Laboratory in Vilnius Gediminas Technical University. He is author of more than 200 research papers and 5 books in the field of databases and information systems development. His research interests: knowledge, including business rule and ontology, based information systems development. He delivered lectures in 7 European universities including London, Barcelona, Athens and Ljubljana. O. Vasilecas carried out an apprenticeship in Germany, Holland, China, and last time in Latvia and Slovenia universities. He supervised 6 successfully defended doctoral theses and now is supervising 7 doctoral students. He was leader of many international and local projects. Last time he leaded VGTU part of "Business Rules Solutions for Information Systems Development (VeTIS)" project carried out under High Technology Development Program.
Ruta DUBAUSKAITE. Doctoral student and full time lector at the Information System Department in Vilnius Gediminas Technical University. She participated in the High Technology Development Program Project "Business Rules Solutions for Information Systems Development (VeTIS)". She is author of 11 papers in the field of information systems development. Research interests: consistency of information system model and consistent conceptual modelling based on rules.
Rok RUPNIK. Dr. assistant professor of Information Systems at University of Ljubljana, Faculty of Computer and Information Science. He received his Master in Information Systems Engineering from University of Ljubljana, Slovenia, in 1998, and his Ph.D. in Mobile applications from University of Ljubljana, Slovenia, in 2002. His research interests include IT governance, Information Systems Development Methodologies, Mobile Applications, Data Mining, and project management. His articles have appeared in proceedings of many international conferences and journals. He had an important role in various information systems development and other projects. He has strong practical and teaching interests in project management, Information Systems Strategic Planning, developing Data Mining applications and other areas. He is a member of AIS (Association of Information Systems), senior member of PMI (Project Management Institute) Slovenian Chapter, member of ACM and a member of IEEE. In 2009 he received PMP (Project Management Professional) certificate by PMI (Project Management Institute).
Olegas Vasilecas (1), Ruta Dubauskaite (2), Rok Rupnik (3)
(1, 2) Information System Department, Vilnius Gediminas Technical University, Sauletekio al. 11, LT-10223 Vilnius, Lithuania (3) Faculty of Computer and Information Science, University of Ljubljana, Trzaska 25, 1000 Ljubljana, Slovenia
E-mails: (1) firstname.lastname@example.org (corresponding author); (2) email@example.com; (3) firstname.lastname@example.org
Table 1. Comparison of approaches in ensuring UML model consistency No. Paradigm of Author Year [reference] consistency ensuring 1 Use of constraints Chen and Motet 2009 2 Berkenkotter 2008 3 Chiorean et al. 2004 4 Egyed 2007 5 Pakalnickiene and Nemuraite 2007 6 Use of inference Mokhati et al. 2007 mechanism of formal language 7 Van Der Straeten et al. 2003 8 Simmonds and Bastarrica 2005 No. Technique of Scope of constrained ensuring consistency model elements 1 Controlling grammar one aspect model in XMI format 2 OCL one aspect model 3 OCL one aspect model 4 Consistency rules hard relationship of different coded to UML Analyzer tool aspect models 5 OCL one aspect model 6 Rewriting logic (Maude) relationship different aspect models 7 Description logic relationship different aspect models 8 Description logic relationship different aspect models No. Abstraction level CASE tool used for ensuring consistency 1 Metamodel of UML -- 2 Metamodel of UML USE tool 3 Metamodel of UML OCLE 4 Metamodel of UML Rational Rose with integrated UML Analyzer 5 Metamodel of UML MagicDraw UML 6 Formal language Maude, modelCheck function 7 Formal language Loom 8 Formal language Poseidon for UML, MCC plug-in Table 2. Consistency ensuring of UML model Paradigm of consistency ensuring Use of constraints Technique of consistency ensuring OCL Abstraction level used for Metamodel of UML ensuring consistency Scope of constrained model elements Relationships of different aspect models and different aspect models CASE tool (used and extended) MagicDraw UML Table 3. Examples of suggested consistency rules Associated elements by consistency rule ID Element of UML Element of UML Consistency rule metamodel for metamodel for static behaviour structure aspect model aspect model 1 Operation of Protocol Protocol class of static Transition transition of structure (Protocol- protocol state model. Static Transition), of model has to be structure model protocol state defined by can be model. Protocol operation visualized by state model class diagram graphically can be represented by protocol state machine diagram 2 Class of static Element of Context of structure model protocol state protocol states model has to be ProtocolStateMachine defined 3 Class of static Lifeline of The type of structure model sequence model, lifeline should which can be be specified represented graphically by sequence diagram
|Printer friendly Cite/link Email Feedback|
|Author:||Vasilecas, Olegas; Dubauskaite, Ruta; Rupnik, Rok|
|Publication:||Technological and Economic Development of Economy|
|Date:||Mar 1, 2011|
|Previous Article:||Modelling for evaluations of call center for public traffic and transport systems/ Viesojo transporto sistemos valdymo centro veiklos modeliavimas.|
|Next Article:||Mobile service usage behavior in Korea: an empirical study on consumer acceptance of innovative technologies/Mobiliojo rysio paslaugu naudojimas...|