MyEclipse exits without permission

Integration of design patterns in ArgoUML

Transcript

1 thesis Integration of Design Patterns in ArgoUML, presented by René Lindhorst. Ing.Peter Forbrig Institute for Computer Science Chair of Software Technology University of Rostock Rostock, December 19, 2006

2

3 Contents 1 Introduction Unified Modeling Language Design Pattern Singleton Facade Observer ArgoUML Development Special Features Use Documentation ArgoUML Expand Module Subsystem Model Subsystem Internationalization Build Process Special Features and Guidelines ArgoUML Pattern Wizard Implementation Preparations Generating the Ant configuration file Implementation of the main class of the module Structure of the user interface

4 ii CONTENTS Conception of the data model Possibilities of the pattern wizard Example scenario Final remarks Extension possibilities Design by Contract Pattern cardinality Integration of the design pattern library Conclusion A Appendix 39 A.1 Apache Ant configuration file (build.xml) A.2 Class diagram of the data model Bibliography 47

5 List of figures 1.1 Structure of the singleton design pattern Structure of the facade design pattern Structure of the observer design pattern User interface of ArgoUML Important components of the module subsystem Example for factories and helpers Dependencies of the Ant Targets Main class for activating the Pattern Wizard GUI classes of the Pattern Wizard User interface of the Pattern Wizard Combination of capsule and command objects Component tab of the Pattern Wizard Relationship tab of the Pattern Wizard Important classes of the clock example Clock example in combination with observer design pattern

6

7 Chapter 1 Introduction The use of Unified Modeling Language (UML) and Computer Aided Software Engineering (CASE) tools in software development simplifies the analysis and design of object-oriented applications. In addition, the use of design patterns enables successful designs to be reused and improves the flexibility of the design. However, the use of design patterns is not supported by all CASE tools. The aim of this thesis is the development of a pattern wizard for the open source program ArgoUML. The wizard is integrated into ArgoUML as an extension, a so-called module, and is intended to facilitate the integration of design patterns into existing software systems and to simplify the design of new applications using design patterns. The work is based on the pattern extension for Rational Rose developed in [Man00] and revised in [Sch02]. The wizard developed represents a porting and further development of this extension, with particular emphasis on object-oriented programming and easier usability by the user. The following two subsections provide a brief introduction to the Unified Modeling Language and design patterns. In the next chapter ArgoUML is explained in detail and in chapter 3 the most important internal components of ArgoUML for the development of the pattern wizard are examined more closely. Chapter 4 finally describes the development of the pattern wizard and its possibilities. The chapter ends with a short example scenario, which is intended to clarify the functionality of the wizard once again. In the concluding remarks, options for expanding the pattern wizard are discussed.

8 2 1.1 Unified Modeling Language 1.1 Unified Modeling Language UML is an internationally recognized graphic notation for creating object-oriented models for the analysis and design of object-oriented software. As described in [Bal05], it was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobson and published in 1996 as version 0.91. At the end of 1997, the further developed version 1.1 was adopted as the standard by the Object Management Group (OMG). Other versions followed with some improvements. For example, in May 2002 UML 1.4. However, the notation was not significantly changed and expanded until UML 2.0 was published in 2005. The UML is very popular for a number of reasons. On the one hand, the various elements of a software system can be visually described with a uniform and understandable notation. On the other hand, it forms a simple basis for communication between developers. In the UML there are a large number of diagrams for the most diverse areas of application. In this work, however, only the class diagrams are required. They are used to represent classes, with their attributes and methods, and the relationships (associations, aggregations, compositions, etc.) between them. For further information about UML, the available diagrams and notation elements, I would like to refer to [ZGK04] and [Bal05]. 1.2 Design pattern With a certain level of abstraction, a design pattern describes a structure for solving a general object-oriented design problem, when it can be used and the consequences of its use. In addition to a class structure, the internal structure of the classes and the interfaces are also described. Furthermore, the functionality of the design pattern is illustrated with the help of code fragments. The advantage of design patterns is inter alia. in the reuse of successfully implemented designs and a resulting improvement in the quality of design decisions. The standard work on design patterns is [GHJV04] by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides and the first edition was published at the end of 1994. At that time, the idea of ​​design patterns was no longer new, but it contained the first extensive pattern catalog and thus played a major role in the widespread use of design patterns in software engineering. In this book the Gang of Four (GoF), as the four authors are also called, are the

9 1 Introduction 3 Design patterns divided into three categories. A distinction is made between generating, structure-oriented and behavior-oriented patterns. Generation patterns deal with the creation of objects, structural patterns with the composition of classes and objects, and behavior patterns with the cooperation and distribution of responsibilities between different classes and objects. These three categories are divided into class-based and object-based patterns with regard to their area of ​​validity, depending on whether a pattern mainly relates to classes or objects. It should be mentioned that there are a large number of other collections of patterns in books such as [BMR + 98] or on websites such as [Hil], where the patterns are also classified differently. The design patterns that are mentioned in the course of this study project should then be briefly described. Since these are all design patterns from the GoF, the information accordingly comes from [GHJV04] Singleton The singleton is an object-based generation pattern that ensures that a class has a maximum of one copy. This pattern also provides a global access point to this instance. The singleton class itself is responsible for the administration of its single instance and can thus respond to commands to create new objects with its instance. Figure 1.1: Structure of the singleton design pattern Facade The facade is an object-based structure pattern and is used to provide a uniform interface to the functionality of a subsystem. This is particularly useful with a complex subsystem to make it easier to use. The facade contains information about which subsystem class is responsible for which requests and delegates these accordingly to the responsible ones

10 4 1.2 Design pattern Figure 1.2: Structure of the facade design pattern subsystem objects. The subsystem classes contain the actual functionality and process the requests assigned to them. Observer The object-based behavior pattern Observer is also referred to as observer in German and is used to define a 1-to-n dependency between objects. It has the effect that as soon as the status of an object changes, all objects dependent on it are notified and automatically update themselves. With the observer pattern it is thus possible to ensure the consistency between interacting classes without interlocking them too closely with one another. When the ConcreteSubject changes status, it notifies its observers, whereupon the individual ConcreteObserver objects inform the subject after its status change.

11 1 Introduction 5 questions. The ConcreteObserver then uses this data to adapt its own state to that of the ConcreteSubject.

12

13 Chapter 2 ArgoUML ArgoUML is a tool that supports software developers in the analysis and design of object-oriented applications. It differs in some areas from other commercial CASE tools like Together or Rose. ArgoUML is open source and is based on many open standards. Furthermore, it is a pure Java application and implements ideas from cognitive psychology. These peculiarities will be discussed in more detail in the following sections, but first we will take a look at the history of the project. 2.1 Development ArgoUML was developed by a small group of people led by Ph.D. Jason Elliot Robbins as a research project at the University of California at Irvine. It was one of Robin's main goals, as he said in an email to the developer: [...] to help promote good software engineering practices broadly throughout the industry, and to provide a basis on which more OOAD [Object Oriented Analysis and Design] tools could be built 1. A first version appeared in 1998 and in February 1999 ArgoUML was published as an open source project. At that time it was still called Argo / UML and was only renamed to ArgoUML in November 2001. Since January 2000 the ArgoUML project has been administered via Tigris.org. This is a medium-sized hosting platform, comparable to SourceForge.net or BerliOS, which specializes in open source development tools. It provides the necessary infrastructure such as bug trackers,

14 8 2.2 Special features - lists, version management, web space etc. are available. Until mid-2001 ArgoUML had been downloaded more than once from the project homepage and meanwhile there are an average of 2 downloads per month. Jason E. Robbins gave up the management of the project several years ago. After Toby Baier was briefly responsible, Linus Tolke has been the project manager since June 2002. The core development team of ArgoUML consists of 32 people who are authorized to make changes to the source code. A large number of other developers forward their modifications or extensions to the core development team. There are no exact figures as to how many there are, but the more than 300 subscribers to the developer list can serve as a guide. 2.2 Special features ArgoUML is under the BSD license and is therefore subject to almost no restrictions on the terms of use. The program is available to everyone free of charge and the source code is freely accessible in order to check it, adapt it to one's own needs and distribute it. There are also various UML tools based on ArgoUML, such as MyEclipse and Sygel. Posseidon for UML is such a tool and has been sold commercially as a closed source by the German company Gentleware since June 2001. They offer different versions of the tool with different functionality. Including a community edition for free use. Gentleware also offers commercial support for its products, which is very important for many users. Jason E. Robbins commented on the use of the ArgoUML source code as a basis for other CASE tools in a list sent to the developer as follows: I am happy to see vendors create and sell their own unique value-add [ed tools] and be rewarded for it. Encouraging more small tool vendors is great for the industry in the long run. 3 Another special feature are the open standards. The developers of ArgoUML have tried to use as many as possible for the program and its interfaces. The main advantage of using open standards is interoperability. ArgoUML conforms to the UML 1.4 standard of the Object Management Group (OMG) and uses their XML Metadata Interchange 4 (XMI) format spec catalog.htm

15 2 ArgoUML 9 for storing the model information. XMI also serves as an exchange format between different CASE tools. Thus it is theoretically possible to import the model created in ArgoUML into another tool. However, the XMI file does not contain any information about the graphic representation of the model (this was only added in the UML 2.0 specification), so that the layout information is lost. ArgoUML currently saves this information for each created diagram in a separate file and uses the Precision Graphics Markup Language (PGML) for this. It is planned to replace the PGML with the UML Diagram Interchange Specification as soon as ArgoUML implements the UML 2.0 specification. It is also possible to import the model from another CASE tool into ArgoUML. For this, the model must be available in the XMI format of version 1.0, 1.1 or 1.2, but the graphic representation would also be lost in this case. Programs like Meta Integration Model Bridge 5 specialize in converting models between different tools. So it is z. For example, it is possible to convert models from Rational Rose, which does not support XMI export, into an XMI format that can be read by ArgoUML. ArgoUML packs the XMI file together with the PGML files, a file (* .argo) that contains the information about the project and another file (* .todo) that contains the test criteria created by the user in a so-called compressed ArgoUML project file with the file extension zargo. This is a normal zip archive, which you can unpack again with common packing programs after renaming the extension. The UML diagrams generated in ArgoUML can also be exported as graphics. For this purpose, the formats Encapsulated PostScript (EPS), Graphic Interchange Format (GIF), Portable Network Graphics (PNG), PostScript (PS) and Scalable Vector Graphics (SVG) are supported. Another special feature of ArgoUML is that it also supports the Object Constraint Language (OCL). The Dresden OCL Toolkit 6 developed at the Technical University of Dresden is used for this purpose. The decision to develop ArgoUML in Java has a speed disadvantage compared to compiled programs due to the interpretation of the Java bytecode. However, the performance of modern computers makes this difference smaller and smaller. The use of Java also has a great advantage. The program is available to all common platforms and thus to all potential users without adjustments. It is also possible for anyone interested to try out the program as Java Web Start (JWS) on the project homepage. Thus ArgoUML can be tested without running the program on the

16 Use your own computer to install. Another special feature of ArgoUML is that it is available in 10 different languages, including: is available in English as well as in German, Russian and Chinese. The standard language of the program and also of the community is US English. If you start ArgoUML for the first time and this is not done via the command line with the parameter -local (see Command Line Options in the Quickguide), it starts with the default locale of the computer. If the language is not available, the standard language is used instead. The menu Edit Settings Appearance takes you to a selection box through which you can specify the language that ArgoUML should use from the next start. A main focus of ArgoUML lies in the implementation of the ideas of cognitive psychology in order to support the developer in the conception of object-oriented systems. The theory is in the Ph.D. Dissertation by Jason E. Robbins [Rob99] described in more detail. The so-called design critics run as asynchronous processes, parallel to ArgoUML in the background, to monitor the UML draft and to offer the user a large number of useful suggestions and tips. So the user is z. B. Attention is drawn to the fact that, contrary to convention, he has written class names in lower case or that no constructor has yet been defined. A detailed list and description of the checked criteria can be found in the user manual. ArgoUML goes one step further to optimally support the user. In addition to information about identified weaknesses or errors, the program also offers a wizard to eliminate them. It is of course also possible to deactivate individual or all criteria or to set your own priorities for them. 2.3 Use In order to be able to use ArgoUML, only a few system requirements have to be met. An operating system that supports Java is required and a Java Runtime Environment (JRE) or a Java Development Kit (JDK) version 1.4 or higher must be installed. The program itself takes up about 10 MB of storage space on the hard drive after it has been downloaded as a ZIP archive from the project homepage and unzipped. Figure 2.1 shows the ArgoUML program window in which an empty project with a class diagram and a use case diagram is open. Such an ArgoUML project contains exactly one model with the associated diagram information and several model elements that form the UML description of the system to be modeled. The model elements can be in one or more

17 2 ArgoUML 11 several diagrams.However, ArgoUML can only have one project open for editing at a time. Figure 2.1: ArgoUML user interface The ArgoUML user interface has a menu at the top, as is usual with programs for Windows and Linux, and a toolbar below. The version that has been adapted for Mac OS X and packaged in a.app package shows the menu in the menu bar at the top of the screen, as is usual under OS X. The area below the toolbar is divided into four sections and takes up most of the program window. At the top left is the explorer, which shows a tree structure of the generated UML model with all diagrams and model elements and thus plays a central role in all actions. The elements of the tree can be grouped and sorted according to various criteria in order to adapt the view to your own needs. To the right of this is the editing area in which the classes and their relationships are modeled. Model elements can be added to the diagram by the Explorer or the objects in a diagram can be rearranged using drag & drop. The editing area has its own toolbar that adapts to the type of diagram to be edited. By selecting the corresponding button in the toolbar, new model elements can be created in the diagram. A very simple way of creating new elements that are linked to already existing elements is via the so-called quick links. These appear as soon as you move the mouse over a selected element. The details area is located directly below the editing area. A number of tabs can be used in it, among other things. edited the properties of the currently selected model element, adjusted the representation of the element and defined OCL criteria

18 Documentation. There you can also see the generated source code for a currently selected class. Source code generation for Java, PHP, C ++ and C # is currently supported. However, further languages ​​can be added as the source code generation is a modular framework. Unfortunately, the changes you make in the source code are not saved. Round-trip engineering is currently not possible for any of the supported languages. But at least reverse engineering for Java source code and JAR archives is supported via File Import ... The import for C ++ code is also in progress. However, it is currently still in the early stages with some restrictions. To the left of the detail area is the ToDo area. It shows the problems found by the design critics and the entries added by the developer in a tree structure. These entries can be sorted according to criteria such as priorities, problems or goals. Below these four areas, the status bar forms the end of the program window. It is used to provide the user with brief information. So you are informed there about the successful saving of the project or the export of diagrams. 2.4 Documentation The ArgoUML project offers various English-language documents for users and developers to support them in their work. In addition to an ArgoUML Quick Guide [WTOO06], there is also an ArgoUML User Manual [WTB + 06] and a list of Frequently Asked Questions for ArgoUML [Mor]. The Cookbook for Developers of ArgoUML [TK06] is, as the name suggests, aimed at developers. The ArgoUML Quick Guide is intended to give the user a rough overview of ArgoUML. It explains the installation of the program and introduces the available command line parameters. It also explains what you have to set under Windows so that when you double-click on a .zargo file, it opens with ArgoUML. In addition, the structure and functionality of the program are briefly explained. For further information, the user is referred to the user manual. This is an independent part of the ArgoUML project. The goals of this sub-project are on the one hand to provide instructions for the use of ArgoUML in object-oriented analysis (OOA) and in object-oriented design (OOD), and on the other hand

19 2 ArgoUML 13 to provide a representation of all components of ArgoUML. The user manual (ArgoUML User Manual) currently has a volume of almost 400 pages, whereby only the structure has been defined for the chapters on analysis and design and they are only gradually filled with content. In the FAQ, the user will find answers to a large number of questions. For example, it explains how to create diagrams and print them out later. However, Java Web Start, XMI and operating system-specific questions are also dealt with. The FAQ is regularly expanded to include problems or important information that is discussed in the user list. The developer cookbook (Cookbook for Developers of ArgoUML) is intended for developers, as it describes the internal functionality of ArgoUML. Much of the information in the next chapter comes from it. With its almost 150 pages, however, it only offers a very rough overview in many places, so that a look at Javadoc 7 or an examination of the source code is essential. However, the developer cookbook is regularly revised and expanded and therefore contains more and more important information, especially for new developers. It is also advisable to subscribe to the developer list and to follow the developers' discussions or to participate in them yourself in order to better understand the design decisions. 7th

20

21 Chapter 3 ArgoUML Extending ArgoUML can be extended by so-called modules with new functions without having to make changes to ArgoUML itself. In other tools, such modules are also called add-ins or plug-ins, such as Gentlewares Poseidon. The following sections explain how the module architecture of ArgoUML works and how other components of ArgoUML that are important for pattern expansion are structured and how they can be used. 3.1 Module subsystem The ArgoUML program code is divided into subsystems, each of which is responsible for certain tasks in order to simplify development. The module system is such a subsystem and it is responsible for the integration of extensions. There are currently two different mechanisms for loading modules. An old module loader and a new one that simplifies the writing of modules and should be used for all new modules. When reading the developer's cookbook ([TK06]), you have to be careful which of the two is explained so that you don't mistakenly use the old one for your expansion. However, the original Module Loader has been marked as obsolete since version. For this reason, the situation will be simplified again in the near future, since according to the programming standards described in [TK06] such classes can be removed after a stable version. When ArgoUML is started, the modules are loaded by the ModuleLoader2, the name of the new Module Loader, which is located under org.argouml.moduleloader. It is also planned that the modules will be integrated from ArgoUML,

22 model subsystem or can be deactivated again. In order for the ModulerLoader2 to recognize a module, a class of the module must implement the ModuleInterface. It contains methods for activating, deactivating and identifying the module. The manifest file, which is located in the module jar archive together with all classes and the required resources, refers to this class. A distinction is made between external and internal modules with regard to whether the module is an independent jar archive or part of the argouml.jar. The external modules must be located in a sub-folder with the name ext in the program folder so that they can be found by the Module Loader. Once a module is activated, it can no longer be distinguished from the rest of ArgoUML. It can therefore access all programming interfaces (APIs) of the subsystems and other modules. Figure 3.1: Important components of the module subsystem 3.2 Model subsystem The model subsystem was created in order to provide all other components of ArgoUML with consistent interfaces with which manipulations of the model repository are possible. So it is of no interest for the components whether NetBeans Model Data Repository (MDR), Novosoft UML Library (NSUML) or a

23 3 Extending ArgoUML 17 ne other implementation is used. The NSUML library was used for the UML 1.3 metamodel and an implementation that uses NetBeans MDR is now used for the 1.4 metamodel. The manipulations on the model are carried out using so-called factory and helper classes. The factories are generally used to create new model elements, and the helpers offer the possibility to change the model elements. These classes are accessed using static methods of the org.argouml.model.model class. It is also she who decides which of the above mentioned implementations is used. This is possible because every implementation offers the same factory and helper classes and their methods are specified by interfaces. The most important of these classes are CoreHelper and CoreFactory. So you can z. E.g. change the name of a model element with Model.getCoreHelper (). SetName (handle, name) or create a new attribute with Model.getCoreFactory (). BuildAttribute (model, type). Other important classes are the ModelManagementHelper and ModelManagementFactory shown in Figure 3.2. With them you can z. B. determine all model elements of a certain type or create a new UML package. Another important class of the model subsystem is the facade. As the name already suggests in Figure 3.2: Example for factories and helpers, it is an implementation of the facade design pattern. It is accessed via Model.getFacade () and it only allows read access to the model. 3.3 Internationalization Internationalization, also called i18n, is an infrastructure subsystem of ArgoUML and other subsystems are available to translate character strings. All character strings that appear in the GUI are stored in property files under an identifier and these files are

24 build process starts loaded into the PropertyResourceBundles. The syntax of the IDs is word1.word2.word3, where word1 is the first part of the name of the file in which the ID is located. There are files for labels, menus, tabs etc. and all have the ending properties. Files that belong to a different localization than the standard language US English are given a name affix to identify the corresponding language. The German localization files get z. B. de appended. Listing 3.1 shows an example of part of such a file. tab. appearance = Appearance tab. checklist = Checklist tab. checklist. warning = Warning! What items you check is not saved tab. checklist. description = Description tab. constraints = Constraints tab. documentation = Documentation Listing 3.1: Extract from tab.properties The identifiers are used in the GUI as parameters for the localize method (see Listing 3.2), which finds and outputs the appropriate character strings in the selected language while the program is running. The localization method is provided by the class org.argouml.i18n.translator as a static method. import org. argouml. i18n. Translator; ... String localized = Translator. localize ("tab. appearance") ... Listing 3.2: Use of the internationalization subsystem The files for the standard language US English are located in ArgoUML under org.argouml.i18n. All other languages ​​are designed as independent projects that are integrated as modules in ArgoUML. So it is possible without major problems to add new languages ​​to ArgoUML. 3.4 Build process ArgoUML uses Apache Ant for the build process, among other things. to compile the individual components of ArgoUML and to create various Jar archives from the class files. Ant is a build tool written in Java by the Jakarta Project 1, part of the Apache Software Foundation, and is licensed under Apache 1

25 3 Extending ArgoUML 19 Software License. It is very popular in the Java environment and in publications such as [Edl02] it is also referred to as the successor to make in this area. One reason for this is not only the flexibility of Ant, but certainly also the good integration into development environments (Integrated Development Environment) such as Eclipse and NetBeans. Ant reads the rules about which commands should be used on what from an XML file (build.xml). These commands, which are named in Ant Tasks, include: calling various Java compilers, accessing version management, copying commands and creating various archives. Tasks are grouped in instruction blocks, so-called targets, and form individual work steps that can also depend on other work steps. In addition to the main build file with a large number of targets, ArgoUML also has two smaller ones for the model subsystem and the MDR implementation of the model subsystem, which are used by the main file. Each module also has its own build.xml file. Further information about Ant can be found in the official documentation 2 or in books such as [Mat05] or [Edl02], which also served as the basis for my explanations and work with Ant. 3.5 Special features and guidelines When programming on ArgoUML or a module for ArgoUML, there are some special features and guidelines that a developer should observe. Some of the most important are briefly discussed below. The version number of ArgoUML is composed according to the following scheme: major version number, minor version number, revision number. The main version number is still a 0, which does not indicate that the development is not very far advanced, but rather that even after almost eight years of development, the set goals have not yet been achieved. A stable version that can be used by everyone always has an even minor version number, such as B If errors occur in such a version that urgently need to be eliminated, the improved version is appended with a corresponding revision number, e.g. B Developer versions always have an odd minor version number. In the 0.23. * Versions, improvements and extensions are being worked on, which will ultimately lead to the release of the next stable version 0.24. The programming style in ArgoUML is based on the Code Conventions for the Java 2

26 Special features and guidelines Programming Language 3 from Sun Microsystems with some extensions. According to this, all classes, methods and variables must be provided with Javadoc comments and no comments should be written within methods. If something more complex happens in a method that requires an explanation, this part should, if possible, be outsourced to a separate method and this should receive a corresponding comment. Another important extension of the code conventions is the handling of obsolete public or protected classes, methods and attributes. Before you can delete them, they have to be marked as deprecated for a stable version. This is the only way that module developers can make their adjustments during the developer versions of ArgoUML and that updated modules can appear together with a new stable version of ArgoUML. Furthermore, it is also important for the development of ArgoUML itself to have enough time for appropriate adjustments and tests on dependent program parts. For additional rules on the programming style, on handling the Subversion Repository and on the provisions on the use of external libraries, reference should be made at this point to the Standards for coding chapter in [TK06]. The logging subsystem of ArgoUML can be used to output messages for searching for errors or other information about the program flow on the command line. This system uses log4j 4 for its task. Since according to [TK06] you should not use System.out.println in the ArgoUML source code, it is important to know how you can use the logging system in your own classes. The following source code is intended to demonstrate this briefly: // Import the class definition of the logger import org. Apache. log4j. Logger; public class your class {// create the logger private static final logger LOG = logger. getlogger (yourclass. class); } public void a method () {// print a debug message LOG. debug ("Debug test!"); } Listing 3.3: Using the logging subsystem

27 3 Extending ArgoUML 21 An overview of the different levels of the log entries as well as an explanation of how to activate the different logging options can be found in [TK06]. A very easy way to activate the logging is via one of the prefabricated targets of the build.xml file from ArgoUML. So starts./build debug ArgoUML from the compiled sources and activates the debug level logging, whereupon all debug messages are output in the console.

28

29 Chapter 4 ArgoUML Pattern Wizard After ArgoUML and its internal structure have been explained in the previous chapters, the pattern wizard that has been developed will now be discussed in more detail. The most important development steps are explained and the options of the wizard are described in detail. 4.1 Implementation Preparations Before the actual development of the module can begin, a few preparations are necessary. First you need the source code of ArgoUML. You could use the source code that is available for download for each version. However, it is better to check out the latest code from the Subversion repository.Since Eclipse was used for the development, the Team Project Set files provided by the ArgoUML project could be used. About 30MB of source code and libraries are downloaded and divided into different Eclipse projects. The necessary settings for Eclipse are also made. A detailed description can be found in the chapter Developer Cookbook. Setting up Eclipse 3 of generating the Ant configuration file After the source code has been downloaded and ArgoUML can be compiled and started from Eclipse, a new Java-

30 implementation project. The first thing you need in this project is a configuration file for Ant. The build.xml created for the pattern wizard can be found in Appendix A.1. The build file begins with a mandatory, XML-typical instruction that defines the Ant version and the encoding used. The project is then defined in line 17 with the name argouml-pattern-wizard and usage is defined as the standard target if Ant is called without explicitly specifying a target. The individual tasks that Ant is supposed to perform are divided into separate targets, each of which calls its corresponding predecessor with the help of the depends attribute. This creates a linear linking of the individual targets. The project contains ten targets and imports another one from another build file. This import takes place in line 23 with the import task. The division of the build file is based on the structure required for all subprojects in the Developing in a subproject section of the developer cookbook and expands this with a few additional targets. The most important target for development is debug in line 166. Its task is to start ArgoUML in debug mode in order to test the functionality of the module. To start ArgoUML without logging, use the run target in line 156. Before one of the two targets can execute ArgoUML, the ext directory for extensions in the ArgoUML folder must be created in line 144 in the install target. The jar archive of the pattern wizard previously created in the jar target (line 120) is then copied there. When creating the jar archive, the required manifest.mf file is also created. The most important entries are the class path and the name of the class that implements the ModuleInterface. The class files that are required in the jar target to create the jar archive are created in the compile target (line 104) when the source code is compiled by the javac task. But before the Java compiler can do its job, the prepare-target is executed in line 76. Its task is to create a bin folder in the build folder in which the class files can be stored. Furthermore, the source code of the module is also copied into the build folder (line 81) and the tokens in the source code are replaced by the corresponding character strings. This ensures that the version information displayed later in the pattern wizard is also correct. As you can see in line 76, the prepare target depends on three more. On the one hand, from the init target (line 28), which defines various so-called properties or includes them from property files. Properties are comparable to constants. They serve as placeholders for a value and once they are set, they can no longer be changed. The second target that prepare depends on is clean (line 180). He is responsible for deleting the results of a previous run. The third dependency is on the imported generate-buildnumber-target, the

31 4 ArgoUML Pattern Wizard 25 is defined in the buildnumber.xml file. As the name suggests, its job is to generate the build number. It consists of four digits, whereby the first represents the number of years the module has already existed and the last three stand for the number of the day on which the module was compiled. Build number 1242 stands for day 242 of the first year in which the module is available and number 242 stands for August 30th. Since Ant does not offer any tasks for control structures, but these are necessary to calculate the number of the day, Ant-Contrib 1 is used for this. This is a collection of additional tasks that can be used after they have been integrated via taskdef-task. In addition to the targets already presented, there is also a javadoc target (line 192) for creating documentation and the standard target usage (line 54) already mentioned, which outputs information about available targets. Both require some properties and therefore also depend on the init target. Figure 4.1: Dependencies of the Ant Targets implementation of the main class of the module The next step is to write a class that implements the ModuleInterface. The ActionOpenPatternWizard class takes on this task and thus represents the main class that ArgoUMLs ModuleLoader2 recognizes and integrates as a module during the program start or after activation. To do this, it has to implement four methods (see Figure 4.2). On the one hand the method enable () to be able to activate the module, and on the other hand disable () to enable it 1

32 implementation can also be deactivated again. The other two methods are used to learn more about the module. Getname () returns the name of the module and getinfo () gives you, depending on the parameter, the author, a short description or the version of the module. Figure 4.2: Main class for activating the pattern wizard When activating the module, the ArgoUML menu should be extended by an entry for the pattern wizard in the tools menu. To do this, as in Listing 4.1, it is necessary to determine the GenericArgoMenuBar in the enable () method. It defines ArgoUML's menu bar. The gettools () method gives you the JMenu object of the tool menu, to which you can attach the JMenuItem of the pattern wizard. public boolean enable () {GenericArgoMenuBar menubar = (GenericArgoMenuBar) ProjectBrowser. getinstance (). getjmenubar (); menubar. gettools () .add (patternextmenuitem); } Listing 4.1: Adding a menu entry Similarly, the menu entry must also be removed again if the module is deactivated. So that ActionOpenPatternWizard can react to the user's action, the class must also implement an ActionListener. This is the only way to react to the triggered ActionEvent by opening the Pattern Wizard. Structure of the user interface If the Pattern Wizard is activated via Tools Pattern Wizard ..., a non-modal dialog window opens. This dialog is generated by the PatternWizard class (see Figure 4.3). It is for interaction with the user

33 4 ArgoUML Pattern Wizard 27 and all changes made by it are passed on to the data model. The class extends ArgoDialog which is used in ArgoUML for dialogs with localized buttons. Figure 4.3: GUI classes of the pattern wizard As Figure 4.4 shows, the window of the pattern wizard is divided into three areas. At the very top is the transformation area, in which the classes can be manipulated via three tabs. A detailed description of the options in these tabs can be found in section 4.2. Below this area is the help area in which different numbers of tabs can be opened. One that is always available is the instructions tab, which explains how to use the wizard with step-by-step instructions. Further tabs can contain information about selected design patterns. you

34 implementations are opened via the button Show documentation below the list of available patterns. The information presented there comes from an overview of design pattern 2 from the software engineering chair at the University of Rostock and is stored in the documentation of the pattern packages. There are three buttons in the bottom area of ​​the Pattern Wizard. An Apply button to apply the manipulations made in ArgoUML, a Close button to temporarily close the dialog (whereby the changes made are not lost) and a Reset button to discard all changes made. Figure 4.4: User interface of the pattern wizard Conception of the data model All data that is displayed in the user interface originate from an object of the CombinePattern class. It saves all data of the model elements involved in the combination and all changes made to them by the user. Furthermore, the class contains the entire logic for manipulating and combining the design patterns and the associated interaction with ArgoUML. 2

35 4 ArgoUML Pattern Wizard 29 To give the user the opportunity to undo the changes he has made, the changes are not immediately implemented in ArgoUML, but are saved until the Apply button is pressed. For this purpose, as in [Sch02], capsule objects for classes, attributes, methods and relations of ArgoUML and command objects for the changes made by the user are used. Instances of the classes ... Wrappers form the capsule objects and each contain an unchanged ArgoUML model element. These capsule objects are preceded by command objects if the user makes modifications (... OperatorModify) or combinations (... OperatorMerge). The advantage of this approach is that manipulations by the user can be undone without any problems. To do this, the last command object is simply deleted. If there are no longer any command objects, the model element is in its original state. Figure 4.5: Combination of capsule and command objects With the help of the example in Figure 4.5, the use of the capsule and command objects is to be described in more detail. The starting point of this example are two classes (UMLClass) of an ArgoUML class diagram. These are each packed in a ClassWrapper to ensure uniform access to the properties of the model element. If the user combines these two classes, the two capsule objects are preceded by a ClassOperatorMerge. This command object ensures the combination of the properties of both predecessor objects. If the user then changes the name of the resulting class, for example, another command object, in this case a ClassOperatorModify, is placed in front of it. Requests to determine the name would then be answered by this object and all other requests would be forwarded to the ClassOperatorMerge object behind it.