evaluation of some of the current uml tools - CiteSeerX

EVALUATION OF SOME OF THE CURRENT UML TOOLS Gasso Wilson Mwaluseke Professor Jonathan P. Bowen South Bank University April 10, 2002

1

INTRODUCTION

There are several UML tools on the market today that describe the semantics, notations and constructs of UML. Most of these tools base their descriptions on the meta-model (i.e. the layer above the model) [5] of UML. This UML document (version 1.1) is claimed to provide a complete semantics that is expressed in a precise way using meta-models and a mixture of natural language and an adaptation of formal techniques that improves precision while maintaining readability. The meta-models do capture a precise notion of the (abstract) syntax of the UML modelling techniques but they do little in the way of answering questions related to the interpretation of non-trivial UML structures. It does not help that the semantic meta-model is expressed in a subset of the notation that one is trying to interpret. The meta-models can serve as precise description of the notation and are therefore useful in implementing editors and they can be used as a basis to define semantics, but they cannot serve as a precise description of the meaning of UML constructs [34]. The UML architects claim that the state of the practice in formal specifications does not yet address some of the more difficult language issues that the UML introduces whereas the precise UML group(pUML) believes that much can be gained by using formal techniques to explore the semantics of UML though text based formal techniques tend to produce models that are difficult to read and interpret as a result of which may hinder the understanding of UML concepts.

2

Some criteria for UML tools

Most of the current UML tools are evaluated on the following criteria: 1. Repository Support. A repository is necessary for the sharing of component design designs between developers. A repository is generally built

1

on top of a database, which provides data sharing and concurrency control features. By providing locking and read-only access, the repository permits one developer to own the model while allowing others to read the model and its components, as well as to incorporate these components into their own designs [13]. The tool should allow the developer or user to pull in only the components that are wanted from another model without having to import the entire model. Another way to build a repository is on top of the source code for a project, using a source-code control system to provide concurrency control. This provides a higher degree of synchronisation between the code and the model. A further benefit is the elimination of the data source. Changes to any component should be automatically propagated to any design which imports the component. 2. Round-Trip Engineering. This is the ability to both forward and reverse engineer source codes (e.g., Java, C++, CORBA IDL ( CORBA Interactive Data Language) etc.). It is a complex requirement that vendors support with varying degrees of success. Given the model, the tool should be able to generate the language code and likewise given the language code, the tool should be able to generate the model. 3. HTML Documentation. The object modelling tool should provide seamless generation of HTML documentation for an object model and its components. HTML documentation provides a static view of the object model for any developer using the model can refer to quickly in a browser without having to launch the modelling tool itself. Moreover, by producing HTML as documentation, the number of required licenses for the modelling tool can be reduced by the number of people that need read-only access to the model information. The HTML documentation should include a bitmap picture of each of the diagrams in the model and should provide navigation throughout the model through the use of hyperlinks. 4. Full UML Support. The tool must support all diagrams of UML which include Use case, Class, Collaboration, Sequence, Package, Statecharts and Activity Diagrams. 5. Pick Lists for Classes and Methods. The modelling tool must be able to provide pick lists in several key interfaces: • Collaboration and Sequence Diagrams: The tool should allow an object to be assigned to a class from a list of classes in the model. It should allow messages sent between objects to be chosen from a valid list of methods for the object or class which is receiving the message. • Class diagram : The tool should allow the importing of classes from other packages or models based on selection of a class from a list of classes in the package. 2

6. Data Modelling Integration. The Object modelling tool should allow integration with data modelling facilities. For example, the UML tool should provide a feature allowing an object model to be transformed into DDL, which is the SQL needed to create tables for classes. Also, the UML tool should be able to support the export of metadata to a data modelling tool which can import the metadata and use it as a basis for a data model. 7. Versioning. The modelling tool must allow versions to be saved so that when subsequent iterations are begun, the previous version is available for restoration. 8. Model Navigation. The modelling tool should provide strong navigational support to allow a developer to navigate through all the diagrams and classes in the model. The tool should allow ease of navigation to the source code for a class when round-trip engineering is being used. 9. Printing Support. Print preview and scaling functionality should be supported to allow ease of fitting the diagram to the desired number of pages. 10. Diagram Views. The UML modelling tool should facilitate customization of the view of a class and its details. The full signature of the methods should be allowed to be shown or hidden easily, depending on the level of detail desired. The visibility of attributes and methods (private, public, protected) should be used to select what to show or hide on the diagram. 11. Exporting Diagrams. The modelling tool should be capable of exporting diagrams into different formats such as PS, EPS,PDF, GIF, PNG, JPEG, etc., which may eventually be imported into a word processing document or web page. The tool should also allow the definition of preferred resolution and size of the graphic that is being produced. 12. Scripting. The power user may create scripts that can directly access the object model within the modelling tool for the purpose of creating other artifacts. The modelling tool should expose interfaces to the object model internal to itself that provides access to the components of the object model under development. However, the scripting language itself must be object-oriented (e.g., Java, Python). 13. Robustness. The UML tool must be with rock-solid reliability to prevent users from losing potentially hours of productivity when the tool crashes in the middle of a design session.

3

14. Platform. Selection of the platform on which to run the tool is very important. The tool must be able to run on cross-platforms. However the cross-platform tool need to be supported on commodity platforms such as Linux in order to achieve large scale adoption by programmers. 15. New Releases. The modelling tool must continue to be actively improved through either bug fixes, performance improvements or addition of new features. That is the tool must be evolving and not static. Most of the current UML tools can satisfy most of the above criteria though not fully. Many (e.g., Rational Rose) have been found wanting in the area of exporting diagrams into different formats for word processing documentation. System boundary descriptions is yet another area where Rational Rose and other tools seem to be lacking. The following is a brief account of a cross section of current UML tools:

3

RATIONAL ROSE TOOL

Rational Rose is a visual modelling tool that is part of Rational Software’s comprehensive and fully integrated e-development solution. Rational Rose product family is designed to provide the software developer with a complete set of visual modelling tools for development of robust, efficient solutions to real business needs in the client/server distributed entreprise, and real-time systems environments. Rational Rose products standard is to make modelling accessible to non-programmer wanting to model business processes as well as programmers modelling applications logic. Rational rose tool provides the capabilities to: • Identify and design business objects and then maps them to software components. • Partition services across a three-tiered service model. • Design how components will be distributed across a network. • Generate Visual Basic code frameworks directly from a model. • Use reverse engineering to create models from existing components and applications. • Use round-trip engineering facilities to keep designs synchronised with a code. Rational Rose extends Visual modeller for dynamic behaviours such as business requirements analysis, business scenario analysis with sequence and collaboration diagrams, state modelling, addition code generation capabilities for DDL (Descriptions Definition Language) and IDL (Interactive Data Language) along with the inclusion of a scripting language to provide access to the Rose domain. 4

3.1

Rational Rose shortcomings

Despite the fact that Rational Rose is widely accepted as the leading UML tool, it lacks very important aspects as explained below: 1. No system boundary for Use Cases. Use cases do capture system requirements. Hence it is very important that the system’s boundary must be defined. A system boundary is the boundary between the system being modelled and the outside world. One system may in turn be made up of several subsystems which interact with each other. Each subsystem may be independently developed in which case the subsystems are better off arranged in layered architecture. Rational Rose does not provide this facility. 2. No animation or simulation for new users and experienced users alike. A good UML tool should always provide animation for new and experienced users alike as reference points. Currently, rational Rose assumes that the user knows what to do with the diagrams or code generation. The simulation must be part of the tool and not a separate package. 3. Code generation not automatic. Rational Rose does not generate code as one draws class diagrams. The developer has to select the class for which to generate the code. It would be quite helpful if Rational Rose generated the code in all the most used languages such as Java, C++, etc., and only allowed the developer to choose which language code to view. 4. No consistency checks done. Rational Rose does not check on the consistency of classes and relationships(e.g., Associations, generalization, aggregations, compositions, e.t.c.). A good UML tool should always check for consistency and report the findings accordingly to enable the developer to make the necessary corrections. 5. Not flexible. Rational Rose is not able to import clip art into its diagrams. The tool is not capable of saving the diagrams in ps (encapsulated Postscript) or pdf (Portable document format) formats or other formats like JPEG, GIF, standard image in which case diagrams drawn using Rational Rose become very difficult to incorporate them into documents of such format. Rational Rose can export diagrams to other formats but the exported file or diagrams become inaccessible thereafter. 6. Not support formal descriptions. Rational Rose is based on UML semantics and constructs. However, the UML semantics are not formal in which case many diagrams are difficult to interpret. In other words, Rational Rose does not support formal description of constructs like associations, compositions and aggregations

5

and classes, generalisation and many more. This in turn means that the constructs or models cannot be verified.

4

Visual UML.

Visual UML is a Visual Object Modeller Inc. modelling product [40]. It is a highly UML-compliant object-modelling tool that provides a complete and comprehensive support for all ten of the diagram types defined in the OMG 1.3 UML specifications namely Class, Object, Package, Use Case, Collaboration, Component, Deployment, Activity, State and sequence diagrams [40]. The following are some of the prominent features of Visual UML tool. 1. The User Interface. Visual UML features a consistent, modern, intuitive user interface, with a multiple document interface (MDI), allowing several charts of the same or different types to be loaded at once. 2. Linking of Models. Visual UML supports linking of model or diagram objects to multiple other diagrams and movement between them. It also supports linking of model or diagram objects to multiple external files such as documents and URLs. 3. XML support. Visual UML supports XML interface (export, import and merge) with DTP. Visual UML supports exporting of diagrams to several popular graphics formats including Windows Metafiles (EMF and WMF), JPEG, BMP, TIFF, PCX, GIF, HTML and the windows clipboard. Moreover, Visual UML supports exporting models and diagram objects description and use case detailed definition reports to HTML, XML, RTF and PDF. Finally, Visual UML supports Visual Basic environment and Java environments as basic environments.

4.1

Visual UML short comings

Like Rational Rose, Visual UML does not support formal descriptions of the UML semantics and constructs and thus models cannot be verified and the actual meaning cannot be realised.

5

Poseidon for UML

Poseidon for UML is the Basic edition of Gentleware’s tool suite. It contains and supports all UML diagrams and implemented diagram elements. Its code generation mechanism is based on a template technology which defines the syntax of the outcome. Poseidon is entirely written in Java and is therefore platform

6

independent [5]. Poseidon for UML comes in two types, namely the community edition and the Standard edition, although the differences are not very significant.

5.1

Advanced Features of Poseidon for UML

1. Constraint with Object Constraint Language (OCL). UML is basically a graphical language suitable for expressing high-level abstractions for architectures, workflows, processes and many more but falls short of expressing very detailed and fine-grained issues like algorithms,equations or constraints. To compensate for this UML comes with a supplementary textual language to express constraints. This language is known as Object Constraint Language (OCL). Since OCL is noted as text, it is simple to support but difficult to tell whether the syntax and semantics are used correctly. Poseidon has a constraints panel on the details pane which holds an OCL editor that comes with its own assistance mode. Poseidon then provides extensive help for constraints using OCL. 2. Critics. This is a cognitive support acting like a built in auditor provided by Poseidon. When activated in the ”critics” menu, the ”critics” are constantly analysing and critiquing the design which can be viewed from any one of the three priority folders shown in the bottom left corner of the working area. 3. Generating Code. Poseidon for UML provides a very powerful and flexible code generation framework, based on a template mechanism. It is currently used to generate Java code, but is also understood to be flexible enough to generate any kind of programming language or even languages such as HTML or XML. This code generation is based on the class model. Generating code from state diagrams is also available as a plug in for the standard Edition of Poseidon for UML. 4. Reverse-Engineering Code. If a source code written in Java programs without errors, Poseidon for UML can analyse the code and auto-generate a model and a set of class diagrams for it. 5. Round-Trip Engineering. This is a very important feature which is still under development in Poseidon. When completed, this facility will enable Poseidon to both forward and reverse engineer source code. 6. Searching for Model Elements. Poseidon offers a powerful search tool that is not just based on text but on model information. The search tool is invoked by pressing the F3 key

7

and then entering the model element name required and specifying the type to search.

6

XUML - Executable UML

XUML is a UML tool which supports MDA (Model Driven Architecture). MDA provides an open, vendor-independent approach to challenge of interoperability, building upon and leveraging the value of OMG’s established modelling standards [?]. It is a new way of writing specifications and developing applications based on platform independent model (PIM). A complete MDA specification consists of a definitive platform independent base UML Model, plus one or more platform-specific (PSM) and interface definition sets each describing how the base model is implemented on a different middleware platform. The UML is an industry standard language with underlying semantics for expressing object models. The UML was conceived as a language that could be used to cover many development paradigms [?]: • Synchronous and asynchronous behaviour. • State dependent and stateless behaviour • Mealy state machines and Moore state machines. • Flat state models and hierarchical state charts • Abstract analysis modelling and code specific design modelling.

6.1

The Key features of XUML

XUML has three main components as specified below: 1. iUML modeller This provides facilities to support • the creation and manipulation of executable object models using xUML formalism • the creation and management of textual requirements including the ability to categorise the requirements, create inter-requirement relationships and attach requirements to model elements • use case analysis including the ability to define use cases and specify their courses using both textual pseudo-code and sequence diagrams. • the specification of system builds from sets of versions of platform independent xUML models. • the ability to capture models describing system design policies and, using the optional iCCG product, use these models to create a code generator that can be used to generate target code from xUML models according to the design policies.

8

2. iUML Generator provides the ability to: • generate 100percent of the code required to execute a model in the iUML Simulator component • using an optional target generation capability, generate 100percent of the code required to produce production code for a target system • integrate generated code with third party tools and/or legacy software, even in simulation mode 3. iUML Simulator provides the ability to: • execute, test and debug the executable object models created using iUML modeller • run special purpose simulation code for the purpose of testing • execute the tests while integrating with third party or legacy software • run automatic regression tests xUML provides support (through iUML) for • Projects and Domains • Domain charts (UML Package Diagrams) • The Static Model which include the following: – Class Diagrams – Classes, attributes, Datatypes – Associations and Generalizations – Textual Descriptions – Optional declaration of object identity and constraints through referential attributes – Ability to define instance data sets • The Dynamic Model – State Models (UML state charts and state tables) – Operations – Class Collaboration Diagrams – Sequence Diagrams with pseudo-code commentary – Interface classes with formal contract definitions • Actions – Defined with the Action Specification Language • Bridges(PIM to PIM Mappings) 9

– Support for formal bridge contracts – Mappings specified using ASL • Model tagging with user defined tag schemas • Full Multi-user working including: – Shared access to xUML models – access to diagrams – Long term multi-user transactions – Ownership and access control. – Partitioning into sub-domain Packages with support for multi-site working. • Integration with iUML Generator and iUML simulator. – Ability to define initialisation actions for simulation runs – Ability to define special purpose external actions for simulation runs – Invocation of simulation process • Requirements Management – Textual requirements capture and refinement – Requirement Traceability – API for integration with third party tools. • Configuration management – Built-in versioning of projects, Domains, and sub-Domain Packages – Off-line utilities for integration with third party tools. • Document production: – Built-in and configurable report production – HTML, Postscript, Groff, Plain text and Framemaker formarts. – Diagrams generated in Postscript, PNG or Windows meta-file formats. • Capture of arbitrary Additional information – Textual and graphical annotations on any diagram – Textual, graphical or tabular annotation documents – Capture and management of supplementary code blocks for insertion into code generation process.

10

7

Related Work

In this research work, a perfect UML tool is one which in addition to all the above criteria, it fully supports the following criteria: 1. Animation. It is quite helpful and productive for the UML tool to provide animated demonstration for the new user as well as experienced user. This is because instruction manuals have always been found to be boring and taking longer time for the user to learn. Animated tutorial is found to motivate the user to carry on the tasks until the end with a better understanding. 2. An Integrated Editor. The modelling tool must be able to integrate text editors which will be used to display the source code for the corresponding UML diagrams or semantic descriptions. The tool should allow changes to the name of signature of a method directly in the code and have the changes immediately reflected in the model. 3. Auto-generation of interaction and state diagrams. The Modelling tool should facilitate the creation of a trace file during the execution of an existing program in order to capture the interaction between objects as they are passing messages between each other. After the trace file is created, the modelling tool is then used to analyse the trace in order to find the patterns of object interactions. The tool should be able to generate either a sequence or collaboration diagram based on actual recorded object interactions. 4. Metrics. The modelling tool should allow access to the metrics for a model. The metrics include the number of super-classes in a class hierarchy, the number of methods per class, the number of attributes per class, the number of methods overriden, the number of lines of code for each method, percentage of public, private and protected methods, the degree of coupling per class and the number of methods commented etc. The metrics are very important for immediate feedback on the viability of a particular model. 5. Management Tools. The modelling tool must be capable of exporting modelling information into a tool that will allow to track the progress of both the design and implementation of a project. 6. Use of XMI. XMI is an interchange format which has the potential to allow seamless sharing of models between tools. Hence the UML tool should be conversant with XMI. 7. The use of Formal Methods. Formal methods came about for two reasons namely:

11

• The interpretation of natural languages. By developing notations that have precise, unambiguous meanings that are not open to multiple interpretations, there is reduction in the freedom of interpretation which reduces the chance of misunderstandings arising and introduction of errors. • Manipulation of specifications. Natural language is large and complex and cannot easily be manipulated. This an attempt at creating systems capable of analysing and manipulating natural language in a meaningful way. Formal methods are very important for our understand and manipulation. In this case, the tool must support one or two formal specification language.

8

Conclusion

The most obvious way of describing requirements is to use natural language because it is easily readable and widely understood. However, natural language descriptions tend to be verbose and can suffer from a variety of problems as described below [1]: 1. Ambiguity Ambiguity in natural language means that many words and sentences are context-sensitive where understanding and interpretation are inferred from the general surrounding text, often intuitively. 2. Completeness and vagueness. Natural language allows us to leave details unspecified and incomplete. 3. Contradiction. A set of requirements may contain statements at odd with each other and the contradictions may spread throughout the requirements so it will not be self-evident that they exist. The semantics and constructs of UML are almost all described using normal English which a natural language. For understanding and using UML effectively, its semantics and constructs must be formalised and a suitable tool supporting formal methods is necessary. This research work is involved in creating such a suitable tool to run on a cross-platfoms.

References [1] a. Harry. Formal Methods VDM and Z, chapter 1, pages 1–7. John Wiley, 1996. [2] J. Abrial, M. Lee, and D. Neilson. The B-Method. In VDM 91: Formal Software Development Methods, 4th International Symposium on VDM, LNCS, pages 398–405, Berlin, Germany, October 1991. Springer-Verlag.

12

[3] D. Andrews and D. Ince. Practical Formal Methods with VDM. McGrawHill, 1991. [4] S. Bennett, J. Skelton, and K. Lunn. Schaums’ outlines UML, chapter 4, pages 47–77. McGraw-Hill, 2001. [5] S. Bennett, J. Skelton, and K. Lunn. Schaum’s outlines UML, chapter 2, pages 6–23. McGraw-Hill, 2001. [6] C. Bock and J. Odell. A foundation for composition. Journal of ObjectOriented Programming, 7(6):36–44, 1994. [7] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modelling Language User Guide. Addison-Wesley, 1999. [8] R. Bourdeau and B. Cheng. A formal semantics for object model diagrams. IEEE Transactions on Software Engineering, 7(21):799–821, October 1995. [9] R. Breu, U. Hinkel, C. Hofmann, C. Klein, B. Paech, B. Rumpe, and V. Thurner. Towards a Formalization of the Unified Modelling Language. In ECOOP’97 Proceedings, volume 1241 of LNCS, pages 344–366, Germany, 1999. Springer-Verlag. [10] M. Broy, C. Facchi, R. Grosu, B. Hubmann, and D. Nazareth. The Requirement and Design Specification Language Spectrum. Technical Report TUM-I9312, Technical University of Munich, Germany, 1993. [11] J. M. Bruel and R. France. Transforming UML models to formal specifications. In Proc. International Conference on the Unified Modelling Language: Beyond the notations, LNCS 1618. Springer-Verlag, 1998. [12] J. M. Bruel, R. France, B. Chintapally, and G. Raghavan. A tool for rigorous analysis of object models. In TOOLS’96: Tools on Object-Oriented Language Systems. Prentice Hall, 1996. [13] Objects by Design. Choosing UML modelling tools. URL: http: //www .objectsbydesign.com/tools/umltoolsb yCompany.html /, 2002. [14] M. Calder and C. Shankland. A symbolic semantics and bisimulation for full LOTOS. In FORTE 2001, 21st International Conference on Formal Techniques for networked and distributed system, pages 184–200, Korea, 2001. Kluwer Academic Publishers. [15] W. Chan, R. Anderson, P. Beame, S. Burns, F. Modugno, D. Nothin, and J. Reese. Model checking large software specifications. IEEE Transaction on Software Engineering, 24(7):498–520, 1998. [16] T. Clark and A. Evans. Foundations of the Unified Modelling Language. In 2nd BCS-FACS Northern Formal Methods Workshop. Springer-Verlag, 1999. 13

[17] D. Coleman, P. Arnold, S. Bodof, and C. Dollin. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994. [18] S. Cook. The UML family: Profiles, prefaces and packages. In UML 2000 Unified Modelling Language, LNCS 1939, pages 255–264. Springer-Verlag, 2000. [19] S. Cook and J. Daniels. Designing object systems. In Second European Conference on Object-Oriented Programming, Germany, 1998. Technical University of Munich. [20] D. Craigen, I. Meisels, and M. Saaltink. Analysing Z specifications with Z/EVES. In M. G. Hinchey and J. P. Bowen, editors, Industrial-Strenght Formal Methods in Practice, FACIT, pages 255–283. Springer-Verlag, 1995. [21] M. d’Inverno and M. Priestly. Structuring specification in Z to build a unifying framework for hypertext systems. In J. P. Bowen and M. G. Hinchey, editors, ZUM’95: The Z Formal Specification Notation, LNCS, pages 47–62, Ireland, September 1995. Springer-Verlag. [22] J. Dong and R. Duke. The geometry of object containment. Object-Oriented Systems, 2(1):41–63, 1995. [23] R. Duke, P. King, G. Rose, and G. Smith. The Object-Z Specification Language. In Technology of Object-Oriented Languages and Systems: TOOLS 5. Prentice Hall, 1991. [24] R. Duke and G. Rose. Formal Object-Oriented Specification using Object-Z. Macmillan Press, 2000. [25] R. Duke, G. Rose, and G. Smith. Object-Z: A specification language advocated for description of standards. Computer Standards and Interfaces, 17(94-45):511–533, 1995. [26] A. Evans. Reasoning with UML class diagrams. URL:http://www.cs.york.ac.uk/puml/publications.html, November 2000. [27] A. Evans, R. France, K. Lano, and B. Rumpe. Developing the UML as a formal modelling notation. In H. Kilov, B. Rumpe, and I. Simmonds, editors, OOPSLA’97 Workshop on Object-Oriented Behavioural Semantics, TUM-19737, pages 297–307, Germany, 1997. Technical University of Munich. [28] A. Evans, R. France, K. Lano, and B. Rumpe. The UML as a Formal Modelling Language. URL: http://www.cs.york.ac.uk/puml/publications.html, 2000. [29] A. Evans and S. Kent. Core Meta-Modelling Semantics of UML: The pUML Approach. In Proceedings of UML 1999, LNCS 1723, pages 140–155. Springer-Verlag, October 1999. 14

[30] A. Evans, K. Lano, R. France, and B. Rumpe. Meta-modelling Semantics. URL: http://www.cs.york.ac.uk/puml/publications.html, 1999. [31] A. Evans, K. Lano, R. France, and B. Rumpe. Meta-modelling semantics of UML. URL: http://www.cs.york.ac.uk/puml/publications.html, November 2000. A technical overview of the OO modelling notations such as UML. [32] R. France and J. M. Bruel. The role of integrated specification techniques. In Proceeding of the Workshop on Real-time Systems Education. IEEE Computer Society Press, 1996. [33] R. France, J. M. Bruel, and M. Larrondo-Petrie. An integrated objectoriented and formal modelling environment. Journal of Object-Oriented Programming JOOP, 10(7):25–34, 1997. [34] R. France, A. Evans, and K. Lano. The UML as a formal modelling notation. In OOPSLA’97 Workshop on Object-Oriented Behavioural Semantics, pages 75–81, Germany, 1997. Technical University of Munich. [35] R. France, K. Lano, and B. Rumpe. The UML as a formal modelling notation. In OOPSLA’97 Workshop on Object-Oriented Behavioural Semantics, pages 75–81. Technical University of Munich, 1997. [36] S. Goldsack and K. Lano. Specifying discrete event systems in VDM++. In International Workshop on Analysis and Design of event-driven Operations in Process System, London, 1995. [37] Object Management Group. OMG unified modelling language specification. URL: http://www.omg.org/, 1999. [38] Object Management Group. OMG unified modelling language specification, version 1.3r2, 1999. [39] J. Hall. Using Z as a specification calculus for object-oriented systems. In Formal methods in Software Development. Springer-Verlag, 1990. [40] Visual Object Modeler Inc. UML tools by company. URL: http: //www .objectsbydesign.com/tools/umltoolsb yCompany.html /, 2002. [41] D. Jackson. Alloy Constraint Analyser for UML. Technical report, MIT Laboratory for Computer Science, USA, 2000. [42] X. Jia. ZTC : A Type Checker for Z Notation, User’s Guide. USA, August 1998. [43] S. Kim and D. Carrington. A formal mapping between UML models and Object-Z specifications. Technical Report 00-03, The University of Queensland, Australia, 2000.

15

[44] G. Kwon. Rewrite rules and operational semantics for model checking UML Statechart. In UML 2000 – The Unified Modelling Language, LNCS 1939, pages 528–540. Springer-Verlag, 2000. [45] K. Lano. Z++, an object-oriented version to Z. In Z User Workshop, Oxford 1990, Workshops in Computing, pages 151–172. Springer-Verlag, 1991. [46] K. Lano and J. Bicarregui. Formalising the UML in structured temporal theories. In Second ECOOP Workshop on Precise Behavioural Semantics, pages 105–121, Germany, 1998. Technical University of Munich. [47] D. Latella, I. Majzik, and M. Massink. Automatic verification of a behavioural subset of UML statechart diagrams. Technical Report 27439, CNUCE, Consiglio Nazionale delle Ricerche, Italy, 2000. [48] Xiaoshan Li, Zhiming Liu, and He Jifeng. Formal and use-case driven requirement analysis in UML. Technical Report 230, UNU/IIST, United Nations University, Macau, 2001. [49] D. Lightfoot. Formal Specification using Z. Palgrave, 2nd edition, 2001. [50] J. Lilius and I. Paltor. The Semantics of UML State Machines. Technical Report 273, Turku Centre for Computer Science, Finland, 1999. [51] N. Nissanke. Formal Specification Techniques and Applications. SpringerVerlag, 1999. [52] OMG. OMG Unified Modelling Language Specification. Object Management Group URL:http: //www.omg.org/technology/uml/, 2000. [53] The Common Framework Initiative Task Group on Language Design. Formal Methods ’99 CASL The Common Algebraic Specification Language. Springer-Verlag, 1999. [54] P. Padawitz. Swinging UML how to make class diagrams and state machines amenable. In UML 2000: The Unified Modelling Language, LNCS 1939, pages 162–177. Springer-Verlag, 2000. [55] T. Quatrani and G. Booch. Visual Modelling with Rational Rose 2000 and UML, pages 44–56. Addison-Wesley, 2000. [56] G. Reggio, M. Cerioli, and E. Astesiano. Towards a rigorous semantics of UML supporting its multiview approach. In H. Hussmann, editor, 2nd AMAST Workshop Algebraic Methods in Language Processing (AMILP 200), pages 171–186, Holland, 2000. Springer-Verlag. [57] R. Rodrigues. Formalising UML activity diagrams using finite state processes. In UML 2000 Workshop. University of Canterbury, Kent, 2000.

16

[58] J. Rumbaugh, M. Blaha, W. Premerlani, and W. Lorensen. Object-Oriented Modelling and Design. Prentice Hall, 1991. [59] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modelling Language Reference Manual. Addison-Wesley, 1999. [60] B. Rumpe. A note on semantics (with emphasis on UML). In Second European Conference on Object-Oriented Programming on Semantics, TUMI9813, Germany, 1998. Technical University of Munich. [61] J. Schmuller. Understanding the Foundations of the UML. Sams publishing, 1999. [62] L. Semmens, R. France, and T. Docker. Integrated structured analysis and formal specification techniques. The Computer Journal, 35(6):21–24, 1992. [63] G. Smith. The Object-Z specification language. Kluwer Academic Publisher, 2000. [64] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science, 2nd edition, 1992. [65] P. Stevens and R. Pooley. Using UML, chapter 5, pages 56–73. AddisonWesley, 2000. [66] K. Turner. LOTOS. URL: http://www.cs.stir.ac.uk/well/intro.html, 1998. [67] M. Vaziri and D. Jackson. Some shortcomings of OCL, the Object Constraint Language of UML. Technical report, MIT Laboratory for Computer Science, USA, 1999. [68] Y. Zhang, V. Raghavan, and J. Deogun. An object-oriented modelling of the history of optimal retrievals. In Annual ACM Conference on Retrieval and Development in Information Retrieval, pages 241–250, New York, 1991. ACM Press.

17