|
Tigris.org
Open Source Software Engineering Tools
|
|
|
 A tutorial and reference descriptionCopyright © 2004, 2005, 2006, 2007, 2008 Michiel van der Wulp Copyright © 2003 Linus Tolke Copyright © 2001, 2002 Jeremy Bennett Copyright © 2001 Kunle Odutola Copyright © 2000 Philippe Vanpeperstraete Copyright © 2000 Alejandro Ramirez Copyright © 2000 Andreas Rueckert This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later. A copy of this license is included in the section Open Publication License. The latest version is presently available at http://www.opencontent.org/openpub/. Abstract This version of the manual is intended to describe the version DISCONTINUED-0.26 of ArgoUML. Table of Contents
Software design is a cognitively challenging task. Designers must manually enter designs, but the primary difficulty is decision-making rather than data-entry. If designers improved their decision-making capabilities, it would result in better designs. Current CASE tools provide automation and graphical user interfaces that reduce the manual work of entering a design and transforming a design into code. They aid designers in decision-making mainly by providing visualization of design diagrams and simple syntactic checks. Also many CASE tools provide substantial benefits in the area of version control and concurrent design mechanisms. One area of design support that has been not been well supported is analysis of design decisions. Current CASE tools are usable in that they provide a GUI that allows designers to access all the features provided by the tool. And they support the design process in that they allow the designer to enter diagrams in the style of popular design methodologies. But they typically do not provide process support to guide the designer through the design task. Instead, designers typically start with a blank page and must remember to cover every aspect of the design. ArgoUML is a domain-oriented design environment that provides cognitive support of object-oriented design. ArgoUML provides some of the same automation features of a commercial CASE tool, but it focuses on features that support the cognitive needs of designers. These cognitive needs are described by three cognitive theories:
ArgoUML is based directly on the UML 1.4 specification. The core model repository is an implementation of the Java Metadata Interface (JMI) which directly supports MOF and uses the machine readable version of the UML 1.4 specification provided by the OMG. Furthermore, it is our goal to provide comprehensive support for OCL (the Object Constraint Language) and XMI (the XML Model Interchange format). ArgoUML was originally developed by a small group of people as a research project. ArgoUML has many features that make it special, but it does not implement all the features that commercial CASE tools provide. The current version (DISCONTINUED-0.26) of ArgoUML implements all the diagram types of the UML 1.4 standard (versions of ArgoUML prior to 0.20 implemented the UML 1.3 standard). It is written in Java and runs on every computer which provides a Java platform version 5 or newer. It uses the open file formats XMI (XML Metadata Interchange format) (for model information) and PGML (Precision Graphics Markup Language) (for graph information) for storage. When ArgoUML implements UML 2.0, PGML will be replaced by the UML Diagram Interchange specification. This manual is the cumulative work of several people and has been evolving over several years. Connected to the release 0.10 of ArgoUML, Jeremy Bennett, wrote a lot of the new material that was added to the earlier versions by Alejandro Ramirez, Philippe Vanpeperstraete and Andreas Rueckert. He also added things from some of the other documents namely the developers cookbook by Markus Klink and Linus Tolke, the Quick Guide by Kunle Odutola, and the FAQ by Dennis Daniels. Connected to the release 0.14 changes were made by Linus Tolke, and by Michiel van der Wulp. These changes were mostly to adopt the manual to the new functions and appearance of ArgoUML version 0.14, and introduction of the index. The users and developers that have contributed by providing valuable input, such as review comments or observations while reading and using this manual are too many to name. ArgoUML is available for free and can be used in commercial settings. For terms of use, see the license agreement presented when you download ArgoUML. We are providing the source code for ArgoUML for you to review, customize to your needs, and improve. Over time, we hope that ArgoUML will evolve into a powerful and useful tool for everyone to use. This User Manual is aimed at the working designer, who wishes to make use of ArgoUML. The manual is presently written assuming familiarity with UML, but eventually it will support those new to UML. The manual is written in DocBook/XML and available as both HTML and PDF. The ArgoUML project welcomes those who want to get more involved. Look at the project website to find out more. Tell us what you think about this User Manual! Your comments will help us improve things. See Section 1.3.3, “User Feedback” . Over the past decade, Object Oriented Analysis and Design (OOA&D) has become the dominant software development paradigm. With it has come a major shift in the thought processes of all involved in the software development life cycle. Programming language support for objects began with Simula 67, but it was the emergence in the 1980's of hybrid languages, such as C++, Ada and Object Pascal that allowed OOA&D to take off. These languages provided support for both OO and procedural programming. Object Oriented programming became mainstream. An OO system is designed and implemented as a simulation of the real world using software artifacts. This premise is as powerful as it is simple. By using an OO approach to design a system can be designed and tested (or more correctly simulated) without having to actually build the system first. It is the development during the 1990's of tools to support Object Oriented analysis and design that moved this approach into the mainstream. When coupled with the ability to design systems at a very high level, a tool based OOA&D approach has enabled the implementation of more complex systems than previously possible. The final driver that has propelled OOA&D has been its suitability for modeling graphical user interfaces. The popularity of object based and object oriented graphical languages such as Visual Basic and Java reflect the effectiveness of this approach. During the 1980's a number of OOA&D process methodologies and notations were developed by different research teams. It became clear there were many common themes and, during the 1990's, a unified approach for OOA&D notation was developed under the auspices of the Object Management Group. This standard became known as the Unified Modeling Language (UML), and is now the standard language for communicating OO concepts. ArgoUML was conceived as a tool and environment for use in the analysis and design of object-oriented software systems. In this sense it is similar to many of the commercial CASE tools that are sold as tools for modeling software systems. ArgoUML has a number of very important distinctions from many of these tools.
UML is the most prevalent OO modeling language and Java is one of the most productive OO development platforms. Jason Robbins and the rest of his research team at the University of California, Irvine leveraged these benefits in creating ArgoUML. The result is a solid development tool and environment for OO systems design. Further, it provides a test bed for the evolution of object oriented CASE tools development and research. A first release of ArgoUML was available in 1998 and more than 100,000 downloads by mid-2001 show the impact that this project has made, being popular in educational and commercial fields. Jason Elliot Robbins founded the Argo Project and provided early project leadership. While Jason remains active in the project, he has handed off project leadership. The project continues to move forward strongly. There are more than 300 members on the developer mailing list (see http://argouml.tigris.org/servlets/ProjectMailingListList), with a couple of dozen of those forming the core development group. The developer mailing list is the place where all the discussion on the latest tasks takes place, and developers discuss the directions the project should take. Although controversial at times, these discussions are always kept nice and friendly (no flame-wars and such), so newbies should not hesitate and participate in them. You'll always get a warm welcome there. If you want to learn how the project is run and how to contribute to it, go the the ArgoUML Web Site Developer Zone and read through the documentation there. The Developers' Cookbook was written specifically for this purpose. Besides the developer mailing list, there's also a mailing for users (see The ArgoUML Mailing List List ), where we can discuss problems from a user perspective. Developers also read this list, so highly qualified help will generally be provided. Before posting to this list, you should take a look at the user FAQ maintained by Ewan R. Grantham. More information on ArgoUML and other UML related topics is also available on the ArgoUML website, maintained by Linus Tolke. The current release of this document is aimed at experienced users of UML in OOA&D (perhaps with other tools) who wish to transfer to ArgoUML. Future releases will support designers who know OOA&D, and wish to adopt UML notation within their development process. A long term goal is to support i) those who are learning design and wish to start with an OOA&D process that uses UML notation, and ii) people interested in modularized code design with a GUI. The intention is that this document will provide a comprehensive guide, enabling designers to use ArgoUML to its full extent. It is in two parts.
Version 0.22 of the document achieved the second of these. In this guide there are some things you will not find, because they are covered elsewhere.
These are covered in the Developers Cookbook, the FAQ, and the Quick Guide. Chapter 2, Introduction (being written) provides an overview of UML based OOA&D, including a guide to getting ArgoUML up and running. Chapter 4, Requirements Capture through Chapter 7, Code Generation, Reverse Engineering, and Round Trip Engineering then step through each part of the design process from initial requirements capture through to final project build and deployment. As each UML concept is encountered, its use is explained. Its use within ArgoUML is then described. Finally a case study is used to give examples of the concepts in use. Chapter 8, Introduction is an overview of the user interface and provides a summary of the support for the various UML diagram types in ArgoUML. Chapter 10, The Menu bar and Chapter 11, The Explorer describe the menu bar, and each of the sub-windows of the user interface, known as Panes. Chapter 15, The Critics gives details of all the cognitive critics within the system. Eventually ArgoUML will link directly to this manual when giving advice on critics. Chapter 16, Top Level Model Element Reference is an overview of the model elements (i.e. the UML entities that can be placed on diagrams) within ArgoUML. The following chapters ( Chapter 17, Use Case Diagram Model Element Reference through Chapter 24, Built In DataTypes, Classes, Interfaces and Stereotypes) describe, the model elements that can be created through each ArgoUML diagram, and their properties, as well as some standard model elements provided with the system. A complete Glossary is provided. Appendix A, Supplementary Material for the Case Study provides material to supplement the case study used throughout the document. Appendix B, UML resources and Appendix C, UML Conforming CASE Tools identify background information on UML and UML CASE tools. Appendix D, The C++ Module explains the use of the C++ module. Appendix F, Open Publication License is a copy of the GNU Free Documentation License. Please tell us what you think about this User Manual. Your comments will help us make improvements. Email your thoughts to the ArgoUML Users Mailing List. In case you would like to add to the missing chapters you should contact the ArgoUML Developer Mailing List to check whether anyone else is working on this part. You can subscribe to either of the mailing lists via the ArgoUML web site. This release of the manual assumes the reader is very familiar with UML already. This is reflected in the sparseness of the description of UML concepts in the tutorial. The case study is described, but not yet fully realized throughout the tutorial. This will be achieved in future releases of the manual. This tutorial will be taking you through a tour of the use of ArgoUML to model a system. First you will become familiar with the feel of the product and then we will go through an analysis and development process for a test case. Not every nook and cranny of the product will be demonstrated. That degree of detail is given in the reference materials to be found in subsequent parts of this document. The state of the model at the end of key sections will be available in .zargo files. These are available so that you can play with various aspects not specifically covered in this tutorial and then restore yourself back to the proper state of the model in your work area. These .zargo files will be identified at the end of the sections whose work they represent. An ATM (automated teller machine) project has been chosen as a case study to demonstrate the various aspects of modeling that ArgoUML offers. In subsequent sections we are going to develop the ATM example into a complete description in UML. The tutorial, however, will only walk you through part of it. At this point you should create a directory to contain your project. Name the directory anything you feel is consistent with the rest of your file system. You should name the contents and any subdirectories as directed for reasons that will become apparent. The case study will be an ATM system. Your company is FlyByNight Industries. You are going to play two roles. That of the Project Manager and that of the Designer Analyst. We are not going to build a physical ATM, of course. The product that we will build as a case study will be an ATM simulator to be used for testing the design of a physical ATM. How your company arranges its work into projects is usually determined as much by politics as anything else and is, therefore, out of the scope of this document. We will go into how you structure the project itself once one has been defined. In this chapter, we look at how UML as a notation is used within OOA&D. Object orientation as a concept has been around since the 1960's, and as a design concept since 1972. However it was in the 1980's that it started to develop as a credible alternative to a functional approach in analysis and design. We can identify a number of drivers.
A number of researchers proposed OOA&D processes, and with them notations. Those that achieved some success include Coad-Yourdon, Booch, Rumbaugh OMT, OOSE/Jacobson, Shlaer-Mellor, ROOM (for real-time design) and the hybrid Jackson Structured Development. During the early 1990's it became clear that these approaches had many good ideas, often very similar. A major stumbling block was the diversity of notation, meaning engineers tended to be familiar with one OOA&D methodology, rather than the approach in general. UML was conceived as a common notation, that would be in the interests of all involved. The original standard was driven by Rational Software ( www.rational.com, in which three of the key researchers in the field (Booch, Jacobson and Rumbaugh were involved). They produced documents describing UML v0.9 and v0.91 during 1996. The effort was taken industry wide through the Object Management Group (OMG), already well known for the CORBA standard. A first proposal, 1.0 was published in early 1997, with an improved version 1.1 approved that autumn. ArgoUML is based on UML v1.4, which was adopted by OMG in September 2001. The current official version, supported by ArgoUML, is UML v1.4.2 dated July 2004, adopted as ISO/IEC 19501. The latest UML version is UML v2.1.2, from November 2007. It is important to understand that UML is a notation for OOA&D. It does not prescribe any particular process. Whatever process is adopted, it must take the system being constructed through a number of phases.
In this section we look at the two main types of process in use for software engineering. There are others, but they are less widely used. In recent years there has also been a move to reduce the effort required in developing software. This has led to the development of a number of lightweight variants of processes (often known as agile computing or extreme programming) that are suited to small teams of engineers. In this process, each stage of the process—requirements, analysis, design and build (code and test) is completed before the next one starts. This is illustrated in Figure 3.1, “The Waterfall Process”. This is a very satisfactory process where requirements are well designed and not expected to change, for example automating a well proven manual system. The weaknesses of this approach show with less well defined problems. Invariably some of the uncertainties in the requirements will not be clarified until well into the analysis and design, or even code phases, requiring backtracking to redo work. The worst aspect of this, is that working code does not become available until near the end of the project, and very often it is only at this stage that problems with the original requirements (for example with the user interface) become apparent. This is exacerbated, by each successive stage requiring more effort, than the previous, so that the costs of late problem discovery are hugely expensive. This is illustrated by the pyramid in Figure 3.2, “Effort Involved in the Steps of the Waterfall Process”. The waterfall process is still probably the dominant design process. However because of its limitations it is increasingly replaced by iterative processes, particularly for projects where the requirements are not well defined. In recent years a new approach has been used, which aims to get at least part of the code up and running as quickly as possible, to bring discovery of problems forward in the development cycle. These processes use a series of “mini-waterfalls”, defining a few requirements (the most important) first, taking them through analysis, design and build to get an early version of the product, with limited functionality, related to the most important requirements. Feedback from this can then be used to refine the requirements, spot problems etc before more work is done. The process is then repeated for further requirements to construct a product with a step up in functionality. Again further feedback can be applied to the requirements. The process is repeated, until eventually all requirements have been implemented and the product is complete. It is this iteration that gives these processes their name. Figure 3.3, “Effort Involved in the Steps of an Iterative Process” shows how this process compares to the pyramid structure of the Waterfall Process. The growth in popularity of iterative processes is closely tied to the growth of OOA&D. It is the clean encapsulation of objects that allows a part of a system to be built with stubs for the remaining code clearly defined. Perhaps the best known Iterative Process is the Rational Unified Process (RUP) from Rational Software ( www.rational.com). This process recognizes that our pyramid view of even slices of the waterfall is not realistic. In practice the early iterations tend to be heavy on the requirements end of things (you need to define a reasonable amount even to get started), while the later iterations have more of their effort in the design and build areas. RUP recognizes that iterations can be grouped into a number of phases according to their stage in the overall project. Each phase may have one or more iterations.
We shall use an iterative process in this manual, that is loosely based on the RUP. A good rule of thumb is that an iteration should take between six and ten weeks for typical commercial projects. Any longer and you have probably bitten off too many requirements to do in one go. You also lose focus on getting the next working iteration completed. Any shorter and you probably haven't got enough requirements to make a significant advance. In this case the additional overhead associated with an interation will become a problem. The total number of iterations depends on the size of project. Take the estimated time (working out/guessing that is a whole subject on its own), and divide it into 8 week chunks. Experience seems to suggest that the iterations will divide in the ratio of around 1:2:3:3 into RUP style inception, elaboration, construction and deployment phases. A project that has great vagueness in its specification (some advanced research projects for example) will tend to be heavier on the early phases. When building a product to contract for a customer the end point is well defined. However when developing a new product for the market place, a strategy that can be used is to decide the product launch date, and hence the end date for completion of engineering (some time before). The time is then divided into iterations, and as much of the product as can be built in that time developed. The iterative process is very effective where time to market is more important than the exact functionality. Very few software systems are conceived as monolithic artifacts. They are broken down into subsystems, modules etc. Software processes are the same, with early parts of the process defining a top level structure, and the process reapplying to parts of the structure in turn to define ever greater details. For example the initial design of a telephone system might identify objects to i) handle the phone lines, ii) process the calls, iii) manage the system and iv) bill the customer. The software process can then be reapplied to each of these four components to identify their design. OOA&D with its clean boundaries to objects, naturally supports this approach. Such OOA&D with recursive development is sometimes abbreviated as OOA&D/RD. Recursive development can be applied equally well to waterfall or iterative processes. It is not an alternative to them. For the purpose of this tutorial we will use a stripped down iterative process with recursive development, loosely akin to RUP. The case study will take us through the first iteration, although at the end of the tutorial section of the manual we will look at how the project will develop to completion. Within that first iteration, we will tackle each of the requirements capture, analysis, design and build activities in turn. Not all parts of the process are based on UML or ArgoUML. We will look at what other material is needed outside. Within this process we will have an opportunity to see the various UML diagrams in use. The full range of UML diagrams and how they are supported is described in the reference manual (see Section 16.8, “Diagram” ). Our requirements capture will use the UML concept of Use Cases. Starting with a Vision Document we will see how Use Cases can be developed to describe all aspects of the system's behavior in the problem domain. During the analysis stage, we will introduce the UML concept of classes to allow us to build a top level view of the objects that will make up the solution—sometimes known as a concept diagram. We will introduce the UML sequence diagram and statechart diagram to capture requirements for the overall behavior of the system. Finally we will take the Use Cases from the requirements capture stage, and recast them in the language of the solution domain. This will illustrate the UML ideas of stereotyping and realization. We use the UML package diagram to organize the components of the project. We then revisit the class diagram, sequence diagram and statechart diagram, to show how they can be used recursively to design the complete solution. During this part of the process, we need to develop our system architecture, to define how all the components will fit together and operate. Although not strictly part of our process, we'll look at how the UML collaboration diagram can be used as an alternative to, or to complement the sequence diagram. Similarly we will look at the UML activity diagram as an alternative or complement to the statechart diagram. Finally we shall use the UML deployment diagram to specify how the system will actually be realized. In the introduction, we listed the four key things that make ArgoUML different: i) it makes use of ideas from cognitive psychology, ii) it is based on open standards; iii) it is 100% pure Java; and iv) it is an open source project. ArgoUML is particularly inspired by three theories within cognitive psychology: i) reflection-in-action, ii) opportunistic design iii) and comprehension and problem solving.
ArgoUML implements these theories using a number of techniques.
UML is itself an open standard. ArgoUML throughout has tried to use open standards for all its interfaces. The key advantage of adherence to open standards is that it permits easy inter-working between applications, and the ability to move from one application to another as necessary. XML Metadata Interchange (XMI) is the standard for saving the meta-data that make up a particular UML model. In principle this will allow you to take the model you have created in ArgoUML and import it into another tool. This clearly has advantages in allowing UML to meet its goal of being a standard for communication between designers. The reality is not quite this good. Prior to UML 2.0 the XMI file includes no information about the graphical representation of the models, so diagram layout is lost. ArgoUML gets round this by saving graphical information separate from the model (see Section 3.4.3.1, “Loading and Saving”).
Object Constraint Language (OCL) is a declarative language for describing rules that apply to UML models. It was developed at IBM and is now part of the UML standard. Initially OCL was only a formal specification language extension to UML. OCL may now be used with any Meta-Object Facility (MOF) compliant metamodel, including UML. The Object Constraint Language is a precise text language that provides constraint and object query expressions on any MOF model or metamodel that cannot otherwise be expressed by diagrammatic notation. Java was conceived as an interpreted language. It doesn't have a compiler to produce code for any particular target machine. It compiles code for its own target, the Java Virtual Machine (JVM). Writing an interpreter for a JVM is much easier than writing a compiler, and such machines are now incorporated into almost every Web Browser. As a result most machines can run Java, with no further work. (In case you wonder why all languages aren't like this, it is because interpreted languages tend to be slower than compiled languages. However with the high performance of modern PCs, the trade-off for portability is worthwhile for many applications. Furthermore modern multi-level caches can mean that interpreted languages, which produce denser code, may actually not be that much slower anyway.) By choosing to write ArgoUML in pure Java, it is immediately made available to the maximum number of users with the minimum amount of effort. ArgoUML is an open source project. That means anyone can have a free copy of the source code, change it, use it for new purposes and so on. The only (major) obligation is that you pass your code on in the same way to others. The precise nature of what you can and can't do varies from project to project, but the principle is the same. The advantage is that a small project like ArgoUML suddenly is open to a lot of additional help from those who can chip in their ideas for how the program might be improved. At any one time there may be 10, 15, 20 or more people making significant contributions to ArgoUML. To do that commercially would cost $1m+ per year. Its not just a spirit of pure altruism. Contributing is a way of learning “hands-on” about leading edge software. Its a way of getting a lot of visibility (over 1,125,000 people had downloaded ArgoUML by the end of 2005). That's a lot of good experience on a résumé and a lot of potential employers seeing you! And its great for the ego! Open Source doesn't preclude making money. Gentleware www.gentleware.com sell a commercial version of ArgoUML, Poseidon. Their value proposition is not a piece of private code. Its the commercial polish and support that take risk out of using ArgoUML in a commercial development, allowing customers to take advantage of ArgoUML's leading edge technology. The aim of this section is to get you started with ArgoUML. It takes you through obtaining the code and getting it running. Since ArgoUML is written in 100% pure Java, it should run on any machine with Java installed. Java version 5 or later is needed. You may have this in place, but if not the latest version can be downloaded free from www.java.com. Note that you only need the Java Runtime Environment (JRE), there is no need to download the whole Java Development Kit (JDK). ArgoUML needs a reasonable amount of computing resource. Any PC which is able to run an operating system with a graphical user interface will suffice. Download the code from Download section of the project website argouml.tigris.org. Choose the version that suits your needs as described in the section below. You have three options for obtaining ArgoUML.
All four options are freely available through the project web site, argouml.tigris.org. There are two steps to this.
Java Web Start will download ArgoUML, cache it and start it the first time, then on subsequent starts, check if ArgoUML is updated and only download any updated parts and then start it. The ArgoUML home page also provides details on starting ArgoUML from the Java Web Start console. If you choose to download and install using the Windows installer, you will have a choice of downloading the latest stable version of the code (which will be more reliable, but not have all the latest features), or the current version (which will be less reliable, but have more features). Choose according to your own situation. The install wizard gives you the opportunity to install the latest "JRE" (Java Runtime Environment). There is no need to select this if you already have a Sun Java installed, version 5 or better. If you choose to download the binary executable, you will have a choice of downloading the latest stable version of the code (which will be more reliable, but not have all the latest features), or the current version (which will be less reliable, but have more features). Choose according to your own situation. ArgoUML comes in
You should have a directory containing
a number of If you get completely stuck and you have no local assistance, try the web site, particularly the FAQ. If this still doesn't solve the problem, try the ArgoUML users' mailing list. You can subscribe through the mailing lists section
of the project web site
argouml.tigris.org, or send an empty message to
users@argouml.org with the subject line You can then send your problem to users@argouml.org and see how other users are able to help. The users' mailing list is an excellent introduction to the live activity of the project. If you want to get further involved there are additional mailing lists that cover the development of the product and issues in the current and future releases. To run ArgoUML depends on whether you use Microsoft Windows or some flavor of Unix.
It's unusual to encounter problems if you have made a successful download. If you can't solve the problem. Try the users' mailing list (see Section 3.4.1.6, “Problems Downloading and Installing”).
Before beginning the Case Study, you need to become familiar with the user interface. Start by reading the introduction to the User Interface Reference. See Chapter 8, Introduction. You should also read the Section 8.2, “General Mouse Behavior in ArgoUML” As you go through this tutorial you will be told what to do, and when to do it but how to do it will often be left to the User Interface Reference. It is not necessary at this point to read all of the Reference, but you should leaf through enough of it to become familiar with how to find things in it. Every attempt will be made to direct you to the appropriate part of the Reference at those points in the tutorial where they apply. Figure 3.6, “Initial ArgoUML window”, shows the main ArgoUML window as it appears when ArgoUML is first entered. Grab the vertical divider bars and move them back and forth. Grab the horizontal divider bar and move it up and down. Play around a little with the little arrows at the left or top of the divider bars. See Section 8.3, “General Information About Panes”. The menu bar and toolbars give access to all the main features of ArgoUML. As is conventional, menu options and toolbar options that are not available (disabled) are grayed out and menu items that invoke a dialog box are followed by an ellipsis (...). At this time you should read Chapter 9, The Toolbar and Chapter 10, The Menu bar. File menu. The standard file menu entries present no surprises and we will just use them when needed without first showing how they work. A number of other actions are available that are peculiar to ArgoUML and we will go over them here.
Edit menu. The edit menu does not look like what you are used to in other products. There are no "Cut", "Copy", or "Paste" actions. All of the choices are peculiar to ArgoUML so we are going to cover all of them in detail.
View menu. This allows you to switch between diagrams, find model elements in the model, zoom in a diagram, adjust the grid, toggle page break display, and show an XML representation of the project. Do a File=>New to get back to a known point. Create an example of each diagram type not already in the Explorer Pane. Click on the (+) sign widgets in the Explorer Pane to expand the tree nodes. Select the class diagram and give it a name.
Create Diagram menu. This allows you to create any one of the seven UML diagram types (class, use case, state, activity, collaboration, deployment and sequence) supported by ArgoUML. State and activity diagrams can only be created when a class or actor is selected, even though the relevant menu entries are not grayed out if this has not been done (nothing will happen under this circumstance). Arrange menu. This allows you to align, distribute and reorder model elements on a diagram and set the layout strategy for the diagram. Generation menu. This allows you to generate Java code for selected classes or all classes. Critique menu. This allows you to toggle the auto-critique on and off, set the level of importance of design issues and design goals and browse the critics available. Tools menu. This menu is permanently grayed out unless there is some tool available in your version of ArgoUML. Help menu. This menu gives access to details of those who authored the system, and where additional help may be found. File Toolbar. This toolbar contains some of the tools from the File menu. Edit Toolbar. This toolbar contains some of the tools from the Edit menu. View Toolbar. This toolbar contains some of the tools from the View menu. Create Diagram Toolbar. This toolbar contains some of the tools from the Create Diagram menu. At this time you should take the time to read Chapter 11, The Explorer. The Explorer Pane is fundamental to almost everything that you do and we will be coming back to it again and again in what follows. In fact you will recall we have had to use it already. There is an expand or contract control in front of the package symbol for “untitledModel” in the Explorer Pane and the package symbol for “Medium” in the To-Do Pane. Click on these controls and observe that these panes are tree widgets that behave pretty much as you would expect them to. The expand or contract control is either plus (+)/minus (-) sign or knob with a right or bottom pointer depending upon the look and feel that you have chosen for an appearance. Select alternately Class Diagram 1 and Use Case Diagram 1 observing that the detail pane changes to track to the selected item in the Explorer. The detail pane is described in Chapter 12. It is not necessary to read Chapter 12 at this point, but it couldn't hurt. At this point take some time to read Chapter 12, The Editing Pane. As we go through the Editing pane changes will sometimes occur in the Details and the To-Do panes. Pay no attention to them for now. We will attend to them when we cover those panes. Select "Class Diagram 1" in the Explorers Pane. The name is unimportant, if you have changed it, just select the new name. If you have deleted it, first perform a Create=>New Class Diagram action. Click on the "New Package" button in the Edit Pane tool bar. Click somewhere in the edit pane. In the Explorer notice that a package appears named (unnamed Package). Double click on the "New Class" button in Edit Pane the tool bar. Click first within the package and once outside of it. Notice that within the Explorer, two classes appear in the tree both named (unnamed Class) one of them attached to the model node and the other attached to the (unnamed Package) node. Click the Select button in the Edit Pane tool bar so you can do things in the Edit Pane without adding new Classes. In the Explorer select the class that is not subordinate to the package. This selects the corresponding class in the diagram. Grab this class and move it into the package. Notice that in the Explorer this class is now also subordinate to the package node. In the diagram select the other class. Notice that in the Explorer, the selected node changes correspondingly. Grab this class and move it outside of the package and watch what happens in the Explorer. At this point take some time to read Chapter 13, The Details Pane.
At this point take some time to read Chapter 14, The To-Do Pane.
In general diagrams are drawn by using the edit pane toolbar to select the model element desired and clicking in the diagram at the position required. Model elements that are already in the model, but not on a
diagram, may be added to a diagram by selecting the
model element in the explorer, using As well as UML model elements, the Edit pane toolbar provides for general drawing objects (rectangles, circles, lines, polygons, curves, text) to provide supplementary information on diagrams. There are several ways to move diagram elements. Select the elements you want to move. By holding down the Ctrl key while selecting you can select several elements to move at the same time. Now hit your arrow keys. Your elements move a little with every key stroke. If you also hold down the Shift key, they move a bit faster. Figure 3.6, “Initial ArgoUML window” shows the ArgoUML main window as it appears as right after start-up The main window's client area, below the menu and toolbar, is subdivided into four panes. Starting at the leftmost top pane, and working around the clock, you can see the Explorer, showing a tree view of your UML model, the Editing Pane with its toolbar, two scroll bars and gray drawing area, the Details Pane with the ToDoItem tab selected, and the To-Do Pane with a tree view of the to do items, ranked in various ways selected via the drop down list at the top of the pane. Each time ArgoUML is started up without a project
file as an argument, a new blank project is created. This
project contains a model called The model and both empty diagrams can be seen in the explorer, which is the main tool for you to navigate through your model. Let's assume for a moment that this is the
point where you want to start modeling a new purchasing
system. You want to give the name
“purchasingmodel” to your model, and you
want to store it in a file called For now ArgoUML; saves diagrams using an earlier proposed standard, Precision Graphics Markup Language (PGML). However it has the option to export graphical data as SVG for those who can make use of it. When ArgoUML; supports UML 2.0, it will store diagrams using the UML 2.0 Diagram Interchange format. First, let's save the model in it's
current (empty and unnamed) state. On the menu bar, click
on Please notice that the File menu contains the usual options for creating a new project, for opening an existing project, for saving a project under a new name, for printing the currently displayed diagram, for saving the currently displayed diagram as a file, and for program Exit. Some of these menu commands can be invoked by pressing key combinations, as indicated on the drop-down menu. For instance, holding down the “Ctrl” key, and pressing “N”, will create a new project. In the current version, ArgoUML can only contain one active project at a time. In addition, a project can only contain one UML model. Since an UML model can contain an unlimited number of elements and diagrams, this should not present any serious limitations, even for modeling quite large and complex systems. But let's go back to saving our project. After
clicking on the This is a standard Java FileChooser. Let's go over it in some detail. The main, outstanding feature, is the scrollable folders list in the center of the dialog. By using the scroll bar on the right, you can move up and down in the list of folders contained inside the currently selected folder. If it is scrollable or not depends on the amount of files and folders shown and also how they are shown. If everything fits the window is not scrollable as seen in the picture. Double-clicking on one of the displayed folders navigates you into that folder, allowing you to quickly navigate down into the folders hierarchy on your hard disk. Notice that only folder names, and no file names
are displayed in the scrollable area. Indeed, the dialog
is currently set up in order to show only ArgoUML project
files with an extension of Also notice that the currently selected
folder's name is displayed in the upper drop-down
control labeled At the top of the dialog, above the scrollable folder chooser area, there are a few more folder navigation tools.
OK, now we navigate to the directory where we want
to save our ArgoUML project, fill in the You have now an active project called ArgoUML saves the diagram information in a PGML
file (with extension All of these are then zipped to a file with
extension
GEF is the software package that is the foundation of the diagrams that appear in the Editing Pane. GEF was an integral part of ArgoUML but has been separated. Like ArgoUML it is an open source project available via Tigris. PGML is the current storage format for diagram information used in ArgoUML. In the future, PGML will be replaced by the UML 2.0 Diagram Interchange format. PGML is a predecessor of SVG (see Section 3.4.3.2.5, “Scalable Vector Graphics (SVG)”. It was dropped by the W3C Consortium. Currently there are no other tools that we know of working on PGML. Select a diagram, then go to
A World Wide Web Consortium (W3C) standard vector graphics format ( http://www.w3.org/TR/SVG/). Support is built in to modern browsers, but you can also get a plugin for older browsers from adobe.com.
Et viola! SVG! Give it a try and zoom around a little... They are not pretty though, so if you know anything about rendering beautiful SVG let us know. Most modern browsers support SVG. If yours doesn't try Firefox or get a plugin for your current browser from adobe.com
ArgoUML supports XMI 1.0, 1.1, and 1.2 files which contain UML 1.3 and UML 1.4 models. For best compatibility with ArgoUML, export your models using UML 1.4 and XMI 1.1 or 1.2. Be sure to turn off any proprietary extensions (such as Poseidon's diagram data). With UML versions earlier than UML 2.0, it isn't possible to save diagram information, so no diagrams will be transferred. There is also a tool that converts XMI to HTML. For more information, see http://www.objectsbydesign.com/projects/xmi_to_html_2.html. In the Versions of ArgoUML prior to 0.19.7 supported UML 1.3/XMI 1.0. After this time, the save format is UML 1.4/XMI 1.2 which is not backward compatible. Newer versions of ArgoUML will read projects written by older versions, but not vice versa. If you might need to return to an older version of ArgoUML you should be careful to save a backup of your old projects. Additionally, if you write XMI files which need to be read by other tools, you should take into account the different versions. Most modern UML modelling tools should read UML 1.4, but you may have in-house code generators or other tools which are tied to UML 1.3. XMI compatibility between UML modeling tools has improved over the years, but you may still occasionally run into problems. ArgoUML will not read XMI files which contain UML 1.5 or UML 2.0 models, but it should be able to open most UML 1.4 and UML 1.3 files. If you find one that it can't open, please file a bug report so that a developer can investigate. It is possible to compile your generated code with ArgoUML, you still need to implement method bodies, though, to get usable results. At the moment you cannot write code for methods (operations) within ArgoUML. The source pane is editable, but the changes are ignored. ArgoUML is a pure design tool for now, no IDE functionality but the desire is there. You might consider using Forte and ArgoUML together—it's a good work around! You can help us out there if you'd like! Design critics are part of the practical application of the theories of Cognitive Psychology that are implemented in ArgoUML. See Section 3.3.1, “Cognitive Psychology” Where do we stand now? A new project has been
created, and is stored in the file The project contains a top-level package, called
If we look carefully at the screen, we can see that
the "Medium" folder in the To-Do Pane (the lower
left pane) must contain some items, since its activation
icon
Clicking on this icon will open the
"Medium" folder. An open folder is indicated by
the
But what is this “To-Do” Pane anyway. You haven't recorded anything yet that has to be done, so where do these to do items originate. The answer is simple, and is at the same time one of the strong points of ArgoUML. While you are working on your UML model, your work is monitored continuously and invisibly by a piece of code called a design critic. This is like a personal mentor that watches over your shoulder and notifies you each time he sees something questionable in your design. Critics are quite unobtrusive. They give you a
friendly warning, but they do not force you into design
principles that you don't want or like to follow. Let
us take a look at what the critics are telling us. Click on
the
Figure 3.11, “ArgoUML Window Showing the Critic Item Notice that your selection is highlighted in red in the To-Do Pane, and that a full explanation appears now in the Details Pane (the lower right pane). You may have to re-size your Details Pane or to scroll down in order to see the full message as displayed in our example. What ArgoUML is trying to tell you is that usually,
package names are written in lower cases. The default top
level package created by ArgoUML is called At this point, you can choose to change the package name manually or to impose silence on the design critic for some time or permanently We will do nothing of this (we'll come back to it when we talk about the design critics in more detail) but we'll use another handy feature of ArgoUML—an auto-correct feature. In order to do that, just click on the Replace the name Watch now how the design critic note in the To Do
panel disappears, leaving only the If this doesn't happen at once, wait for a few seconds. ArgoUML makes heavy use of several threads of execution that execute in parallel. This can cause delays of a few seconds before the information gets updated on the screen. The package name change should also be reflected in the explorer, in the top left corner of your ArgoUML window. We are now ready to create our first UML diagram, a Use Case diagram, but first let's save what we've done so far. Click on the Here is where we are going to start the Case Study. It is at this point that you define your project; not your product, but your project. It can be argued that modeling concepts should apply here as well but this has not been well established. If you can take the time to look into the ArgoUML project, you will find that there are a large number of "lines of code" and lines of documentation that are part of the project, but not part of the product. For example, this document is part of the product while the Cookbook and the build.xml files are part of the project only. At a minimum the file structure of the project could be shown in a package diagram. ... Requirements capture is the process of identifying what the “customer” wants from the proposed system. The key at this stage is that we are in the problem domain. At this stage we must describe everything from the “customer” perspective and in the language of the “customer”. The biggest risk we have in requirements capture is to start thinking in terms of possible solutions. That must wait until the Analysis Phase (see Chapter 5, Analysis). One of the steps of the Analysis Phase will be to take the output of the Requirements Phase and recast it in the language of a deemed solution. Remember we are using both a incremental, and an iterative process. We may well come back to the requirements process again as we break down the problem into smaller chunks, each of which must have its requirements captured. We will certainly come back through the requirements phase on each iteration as we seek to define the requirements of more and more of the system
We start with a top-level view of the problem we are solving and the key areas of functionality that we must address in any solution. This is our vision document, and should be just a few pages long. For example the top-level view of an automated teller machine (ATM) might be that it should support the following.
From this top-level view we can extract the principal activities of the system, and the external agents (people, equipment) that are involved in those activities. These activities are known as use cases and the external agents are known as actors. Actors may be people or machines. From a practical standpoint it is worth knowing the stakeholder behind any machine, since only they will be able to engage with the requirements capture process. Use cases should be significant activities for the system. For example customer use of the ATM machine is a use case. Entering a PIN number is not. There is a gray area between these two extremes. As we shall see it is often useful to break very large use cases into smaller sub-use cases. For example we may have sub-use cases covering cash deposit, cash withdrawal and account inquiry. There is no hard and fast rule. Some architects will prefer a small number of relatively large use cases, others will prefer a larger number of smaller use cases. A useful rule of thumb is that any practical project ought to require no more than about 30 use cases (if it needs more, it should be broken into separate projects). We then show the relationship between use cases and actors on one or more use case diagrams. For a large project more than one diagram will be needed. Usually groups of related use cases are shown on one diagram. We must then give a more detailed specification of each use case. This covers its normal behavior, alternative behaviors and any pre- and post-conditions. This is captured in a document variously known as a use case specification or use case scenario. Finally, since use cases are functional in nature, we need a document to capture the non-functional requirements (capacity, performance, environmental needs etc). These requirements are captured in a document known as a supplementary requirements specification. The steps in the requirements capture process can be summarized as follows.
In any iterative development process, we will prioritize, and early iterations will focus on capturing the key behavior of the most important use cases. Most modern requirements capture processes agree that it is essential that the authoritative representative of the customer is fully involved throughout the process. Almost all the output of the requirements capture process is documentary. The only diagram is the use case diagram, showing the relationships between use cases and actors. Typical sections of this document would be as follows.
The vision document has identified the use cases and actors. The use case diagram captures how they interact. In our ATM example we have identified “customer uses machine”, “maintain machine” and “audit” as the three main use cases. We have identified “customer”, maintenance engineer“,”“local branch official” and “central computer” as the actors. Figure 4.1, “Basic use case diagram for an ATM system” shows how this could be displayed on a use case diagram. The use cases are shown as ovals, the actors as stick people (even where they are machines), with lines (known as associations connecting use cases to the actors who are involved with them. A box around the use cases emphasizes the boundary between the system (defined by the use cases) and the actors who are external.
The following sections show how the basic use case diagram can be extended to show additional information about the system being designed. Active actors initiate interaction with the system. This can be shown by placing an arrow on the association from the actor pointing toward the use case. In the ATM example, the customer is an active actor. Interaction with passive actors is initiated by the system. This can be shown by placing an arrow on the association from the use case pointing toward the actor. In the ATM example, the central computer is a passive actor. This is a good example where the arrow helps, since it allows us to distinguish an event driven system (the ATM initiates interaction with the central computer) from a polling system (the central computer interrogates the ATM from time to time). Where an actor may be either active or passive, depending on circumstances, the arrow may be omitted. In the ATM example the bank engineer fits into this category. Normally he is active, turning up on a regular cycle to service the machine. However if the ATM detects a fault, it may summon the engineer to fix it. The use of arrows on associations is referred to as the navigation of the association. We shall see this used elsewhere in UML later on. The choice, by the OMG, of zero vice two arrowheads to show a bidirectional association is unfortunate. Under this convention you cannot distinguish between an association whose navigation has yet to be determined and one that is bidirectional. Figure 4.2, “Use case diagram for an ATM system showing navigation.” shows the ATM use case diagram with navigation displayed. It can be useful to show the multiplicity of associations between actors and use cases. By this we mean how many instances of an actor interact with how many instances of the use case. By default we assume one instance of an actor
interacts with one instance of a use case. In other cases
we can label the multiplicity of one end of the
association, either with a number to indicate how many
instances are involved, or with a range separated by two
periods ( In the ATM example, there is only one central
computer, but it may be auditing any number of ATM uses. So
we place the label A local bank will have up to three officials
authorized to unload and load ATM machines. So at the actor
end of the relationship with the use case There may be any number of customers and there may be
any number of ATM systems they could use. So at each end of
the association we place the label Figure 4.3, “Use case diagram for an ATM system showing multiplicity.” shows the ATM use case diagram with multiplicity displayed. Multiplicity can clutter a diagram, and is often not
shown, except where it is critical to understanding. In the
ATM example we would only choose to show In our ATM example so far we have just three use cases to describe all the behavior of the system. While use cases should always describe a significant chunk of system behavior, if they are too general they can be difficult to describe. We could for example define the behavior of the use case “Use ATM” in terms of the behavior of three simpler use cases, “Deposit Cash”, “Withdraw Cash” and “Query Account”. The main use case could be specified by including the behavior of the subsidiary use cases where needed. Similarly the “Maintain ATM” use case could be defined in terms of two use cases “Maintain Equipment” and “Reload ATM”. In this case the two actors involved in the main use case are really only involved in one or other of the two subsidiary use cases and this can be shown on the diagram. The decomposition of a use case into simpler sub-use cases is shown in UML by using an include relationship, a dotted arrow from the main use case to the subsidiary, with the label «include». Include relationships are fine for breaking down the use case behaviors in to hierarchies. However we may also want to show a use case that is an extension to an existing use case to cater for a particular circumstance. In the ATM example we have a use case covering routine maintenance of the ATM, “Maintain Equipment”. We also want to cover the special case of an unscheduled repair caused by the ATM detecting an internal fault. This is shown in UML by the extend relationship. In the main use case, we specify a name for a location in the description, where an extension to the behavior could be attached. The name and location are shown in a separate compartment within the use case oval. The representation extend relationship is the same as the include relationship, but with the label «extend». Alongside the extend relationship, we specify the condition under which that behavior will be attached. Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.” shows the ATM use case diagram with an extend relationship to a use case for unscheduled repairs. The diagram is now getting rather complex, and so we have split it into two, one for the maintenance side of things, the other for customer usage and audit. The “Maintain Equipment” use case defines a name “Unsched”, at the start of its description. The extending use case “Unscheduled Repair” is attached there when the ATM detects an internal error. Use cases may be linked together in one other way. One use case may be a generalization of a subsidiary use case (or alternatively the subsidiary is a specialization of the main use case). This is very like the extends relationship, but without the constraint of specific extension points at which the main use case may be extended, and with no condition on when the subsidiary use case may be used. Generalization is shown on a use case diagram by an arrow with solid line and solid white head from the subsidiary to the main use case. This may be useful when a subsidiary use case specializes the behavior of the main use case at a large number of positions and under a wide range of circumstances. However the lack of any restriction makes generalization very hard to specify precisely. In general use an extend relationship instead. Each use case must be documented to explain in detail the behavior it is specifying. ArgoUML assists in this area through the generation of graphic files for inclusion in this documentation. This document is known by different names in different processes: use case specification, use case scenario or even (confusingly) just use case. A typical use case specification will include the following sections.
The final size of the use case specification will depend on the complexity of the use case. As a rule of thumb, most use cases take around 10-15 pages to specify, the bulk of which is alternate flows. If you are much larger than this, consider breaking the use case down. If you are much smaller consider whether the use case is addressing too small a chunk of behavior. All flows in a use case specification are linear—that is there is no conditional branching. Any choices in flows are handled by specifying another alternate flow that takes over at the choice point. It is important to remember we are specifying behavior here, not programming it. A flow is specified as a series of numbered steps. Each step must involve some interaction with an actor, or at least generate a change that is observable externally by an actor. Requirements capture should not be specifying hidden internal behavior of a system. For example we might give the following sequence of steps for the basic flow of the use case "Withdraw Cash" in our ATM example.
Remember this is a sub-use case included in the main “Use ATM” use case, which will presumably handle checking of cards and PINs before invoking this included use case.
This captures the alternative scenarios, as linear flows, by reference to the basic flow. Initially we just build a list of the alternate flows.
Subsequently we flesh out each alternate flow, by reference to the basic flow. For example the first alternate flow might look like.
The convention is to number the various alternate flows as A.1, A.2, A.3, etc. The steps within an alternate flow are then numbered from this. So the steps of the first alternate flow would be A.1.1, A.1.2, A.1.3, etc. Iterative development will prioritize the use cases, and the first iterations will address the most important. Early iterations will capture the basic flows of the most important use cases with only essential detail and list the headings of the main alternate flows. Later iterations will address the remaining use cases, flesh out the steps on individual alternate flows and possibly provide more detail on individual steps. This captures the non-functional requirements or constraints placed on the system. Since use cases are inherently functional in nature, they cannot capture this sort of information.
There should be a section for each of the main areas of non-functional requirements. The checklist provided by Ian Sommerville in his book Software Engineering (Third Edn, Addison-Wesley, 1989) is a useful guide.
To this we should add sections on environment (temperature, humidity, lightening protection status) and standards compliance. ArgoUML allows you to draw use case diagrams. When you
create a new project it has a use case diagram created by
default, named New use case diagrams can be created as needed through
To add an actor to the diagram use button 1 click on
the actor icon on the editing pane toolbar (
Multiple actors can be added in one go, by using
button 1 double click on the actor icon. Each subsequent
button 1 click will drop an actor on the diagram. A button 1
click on the select icon (
The actors name is set in its property panel. First
select the actor (if not already selected) on the editing
pane using button 1 click. Then click on the As a shortcut, double button 1 click on the name of the actor in the editing pane (or just typing on the keyboard when an actor is selected) will allow the name to be edited directly. This is a convenient way to enter a name for a new actor. Having created the actor, you will see it appear in the
explorer (the upper left quadrant of the user screen). This
shows all the model elements created within the UML design. A drop
down at the top of the explorer controls the ordering of
model elements in the explorer. The most useful are the The procedure for adding use cases is the same as that
for adding actors, but using the use case icon on the editing
pane toolbar ( By default use cases in ArgoUML do not display their extension points (for use in extend relationships). You can show the extension point compartment in one of two ways.
The same approaches can be used to hide the extension point compartment. There are two ways to add an extension point to a use case.
Whichever method is used, the new extension point is selected, and its property tab can be displayed in the details pane. The name and location of the extension point are free text, set in the corresponding fields of the property tab. An existing extension point can be edited from its property tab. The property tab can be reached in two ways.
The name and location fields of the extension point may then be edited. As a shortcut, where the extension point compartment is displayed, double click on the extension point allows text to be typed in directly. This is parsed to set name and location for the extension point. Extension points may be deleted, or their ordering
changed by using the button 2 pop-up menu over the Having created an extension point, it will appear in the explorer (upper left quadrant of the user screen). Extension points are always shown in a sub-tree beneath their owning use case. To join a use case to an actor on the diagram use
button 1 click on the association icon on the editing pane
toolbar ( This will create a straight line between actor and use case. You can segment the line by holding down button 1 down on the line and moving before releasing. A vertex will be added to the line, which you can move by button 1 motion. A vertex can be removed by picking it up and sliding to one end of the line. Multiple associations can be added in one go, by using
button 1 double click on the association icon. Each
subsequent button 1 down/motion/release sequence will join an
actor to a use case. Use button 1 on the select icon (
It is also possible to add associations using small “handles” that appear to the left and right of a use case or actor when it is selected and the mouse is over it. Dragging the handle from a use case to an actor will create an association to that actor (and similarly by dragging a handle from an actor to a use case). Dragging a handle from a use case into empty space will create a new actor to go on the other end. Similarly dragging a handle from an actor into empty space will create a new use case. It is possible to give an association a name, describing the relationship of the actor to the use case, although this is not usually necessary. This is done through the property tab of the association. Such a name appears alongside the association near its center. There are two ways of setting the navigation of an association.
You will see it is possible to give an association end a name in its property tab. This name will appear at that end of the association, and can be used to indicate the role being played by an actor or use case in an association. For example a time management system for a business may have use cases for completing time sheets and for signing off time sheets. An employee actor may be involved in both, one as an employee, but the other in a role as manager. There are two ways of setting multiplicity at the end of an association.
The second of these two approaches has a wider range of options, although ArgoUML does not currently allow the user to set an arbitrary multiplicity. UML as originally designed allowed use cases to be organized by grouping them in packages as well as by specifying relations among them. In ArgoUML only the relations mechanism is supported. All Three of the relations that apply to use cases are supported. These are include, extend and generalization. The procedure for adding an include relationship is
the same as that for adding an association, but using the
include icon from the editing pane toolbar (
Since include relationships are directional the order in which the two ends are selected is important. The including (main) use case should be selected first (button 1 down) and the included (subsidiary) use case second (button 1 release). It is possible to name include relationships using the property tab, but this is rarely done, and will not be displayed on the use case diagram. The procedure for adding an extend relationship is
the same as that for adding an include relationship, but
using the extend icon from the editing pane toolbar (
As with include relationships, the order of selection matters. In this case, the extending (subsidiary) use case should be selected first (button 1 down) and the extending (main) use case second (button 1 release).
To set a condition for the extend relationship,
select the extend relationship in the editing pane
(button 1 click) and then bring up its property tab in the
details pane ((button 1 click on the tab). The text of the
condition may be typed in the It is possible to name extend relationships using the property tab, but this is rarely done, and will not be displayed on the use case diagram. The procedure for adding generalizations, is the same
as for adding extend relationships, but using the
generalization icon from the editing pane toolbar (
Since generalization is a directed relationship, the order of selection matters. The specialized use case should be selected first (button 1 down) and the generalized second (button 1 release). It is also possible to add generalizations using small “handles” that appear to the top and bottom of a use case when it is selected. Dragging the handle at the top to another use case will create a generalization. The original use case is the specializing end, and the use case to which the handle was dragged will be the generalizing end. Dragging into empty space will create a new use case to be the generalizing end. Similarly dragging on the bottom handle will create a generalization in which the original use case is the generalizing end. Generalization is also permitted between actors, although its use is beyond the scope of this tutorial. Unlike use cases there are no generalization handles on actors, so generalizations must be created using the toolbar icon. It is possible to name generalization relationships using the property tab, but this is rarely done. If a name is provided, it will be displayed on the use case diagram. UML has the concept of stereotyping as a way of extending the basic notation. It may prove useful for example to model a problem at both the business level and the engineering level. It is for this reason that the OMG distinguishes between a PIM and a PSM. For both of these we will need use cases, but the use cases at the business level hold a different sort of information to those at the engineering level. Very likely they use different language and notation in their underlying use case specifications. Stereotypes are used to label UML
model elements such as use cases, to indicate that they belong to
a certain category. Such labels are shown in guillemots (
You will see that ArgoUML has a drop down selector,
The details of stereotyping are beyond the scope of this tutorial. The reference manual (see Section 16.6, “Stereotype”) documents the support provided in ArgoUML.
ArgoUML has some simple documentation facilities associated with model elements on a diagram. In general these should be used only to record the location of material in documents that can be handled by a mainstream editor or word processor, not the actual documentation itself. Documentation for a particular model element is recorded through the documentation tab in the details pane (the quadrant of the user screen at the bottom right). In addition annotation may be added to diagrams using
the text icon on the editing pane toolbar (
The recommendation is that a use case diagram should use the documentation tab of actors to record information about the actor, or if the actor is complex to refer to a separate document that holds information about the actor. The documentation tab of use cases should record the location of the use case specification. The information in a use case specification (for all but the simplest use cases) is too complex to be placed directly in the tab. The project should also have a separate vision document and supplementary requirements specification. A text annotation on diagrams may be used to refer to these if the user finds this helpful.
ArgoUML provides a series of tools to provide arbitrary graphical annotation on diagrams (we have already mentioned the text tool). These are found at the right hand end of the editing pane toolbar and are fully documented in the reference manual (see Chapter 12, The Editing Pane ). The rectangle tool can be used to draw the boundary
box. Use the button 2 context-sensitive
A vision document contains more than those things needed for the modeling effort. It also contains financial and scheduling pertinent information. The following sections are those parts of the Vision Document spelled out in Section 4.3.1, “Vision Document” above. In practice this format need not be followed religiously, but is used here for consistency. The company wishes to produce and market a line of ATM devices. The purpose of this project is to produce the hardware and the software to drive it that are both maintainable and robust. To produce better designed products based on newer technology. Follow the MDA philosophy of the OMG by producing first a Platform Independent Model (PIM). As current modeling technology does not admit of maintaining the integrity of the connection between the PIM and Platform Specific Models (PSMs), the PIM will become comparatively stable before the first iteration of the PSM is produced. The software platform will be Java technology. The system will use a simple userid (from ATM card) and password (or PIN) mechanism. Equipment currently on the market is based on older technology for both hardware and software. This technology has not reached the end of its useful life, making it unlikely that the vendors of that gear are going to update it in the near future. On the other hand newer technology is available that would put us at a competitive advantage if implemented now. Among the stakeholders for this system are the Engineering Department, the Maintenance Department, and the Central Computer Facility. The full list of these stakeholders and the specific individuals representing them are.
Cash deposit, cash withdrawal, and account inquiries by customers. Customers include people who have accounts at the owning bank as well as people who wish to make withdrawals from accounts in other banks or from credit card accounts. Maintenance of the equipment by the bank's engineers. This action may be initiated by the engineer on a routine basis. It may also be initiated by the equipment that can call the engineer when it detects an internal fault. Unloading of deposits and loading of cash by officials of the local bank branch. These actions occur either on a scheduled basis or when the central computer determines that the cash supply is low or the deposit receptacle is liable to be getting full. An audit trail for all activities will be maintained and sent periodically to the bank's central computer. It will be possible for the maintenance engineer to save a copy of the audit trail to a diskette for transporting to the central computer. Both dialup and leased line support will be provided. The ATM will continue to provide services to customers when communication with the central computer is not available. The project must be completed within nine months. It must cost no more than 1,750,000 USD excluding production costs. Components may be contracted out, but the basic architecture as well as the infrastructure will be designed in house. Close liaison must be maintained between the software development and the design, development and production of the hardware. Neither the hardware nor the software shall be considered the independent variable, but rather they shall be considered equal. The following are the actors that directly support this vision. Additional actors may be identified later that are needed to support this or that technology. They should not be added to this list unless they are deemed to directly support the vision as described in this document.
The following are the use cases that directly support this vision. Additional use cases may be identified later that are needed to support this or that technology or to support the use cases listed here. They should not be added to this list unless they are deemed to directly support the vision as described in this document.
For the ATM case study, we will elaborate on the examples in Section 4.3, “Output of the Requirements Capture Process”, Figure 4.4, “Use case diagram for an ATM system showing include relationships.” and Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.”, and progress to identify additional actors and use cases that comprise our model of the ATM system. Figure 4.4, “Use case diagram for an ATM system showing include relationships.” and Figure 4.5, “Use case diagram for an ATM system showing an extend relationship.” exemplified the essential concepts and components of a use case diagram such as, use cases, actors, multiplicity, and include / extend relationships. They showed the relationships between the actors and use cases, and demonstrated how these actors and use cases interact. In Figure 4.4, “Use case diagram for an ATM system showing include relationships.” we see a use case diagram for an ATM system consisting of «include» relationships for the use cases, Maintain ATM and Use ATM. Maintain ATM was further defined by two use cases, "Maintain Equipment" and "Reload ATM". Use ATM was further defined in terms of the behavior of three simpler use cases: "Deposit Cash", "Withdraw Cash" and "Query Account". More to be written... Analysis is the process of taking the “customer” requirements and re-casting them in the language of, and from the perspective of, a putative solution. We are not actually trying the flesh out the detailed solution at this stage. That occurs in the Design Phase (see Chapter 6, Design). Unlike the boundary between Requirements and Analysis Phases, the boundary between Analysis and Design Phases is inherently blurred. The key is that analysis should define the solution no further than is necessary to specify the requirements in the language of the solution. The model elements in Analysis generally represent a high level of abstraction. Once again the recursive, and iterative nature of our process means we will come back to the Analysis phase many times in the future. There are three schools of thought on how Analysis should be approached. The ontologist defines the data (actually the metadata) first and worries about processes later. The true ontologist would prefer not to have to think about processes at all. The phenomenonologist reverses this and favors process over data. The panparadigmist considers both process and data to be equally important and addresses both from the start. When it comes to being a purist the ontologist has the upper hand. It is possible to define and build a database into which data can be entered and retrieved without concern for what happens to it or is done with it. On the other hand implementing a process without having any data structures for it to operate on is not very meaningful. The CRC methodology favors the phenomenonologists preference for analysis. It is the equivalent of starting with the use cases, the process aspects (operations) of the class diagrams, and scenarios from which sequence diagrams can be initiated. CRC cards and the associated methodology are described in detail in Appendix G, The CRC Card Methodology. They are used again in the design phase and are further discussed in Chapter 6, Design. The strength of CRC cards during analysis.
In this phase the group should consist of two or three domain experts, one object-oriented technology facilitator, and the rest of the group made up of people who are responsible for delivering the system. The first time that the Analysis phase occurs a special case of the CRC session happens as there are no classes or scenarios to choose from to define a CRC session. At this point a special type of session known as brainstorming is held. During this session you identify the initial set of classes in the problem domain by using the problem statement or requirements document or whatever you know about the desired result for a starting point. The nouns that are found in whatever you are starting from are a good key to an initial set of classes in the system. In a brainstorming session there should be little or no discussion of the ideas. Record them and filter the results after the brainstorming. At this stage the distinction between class and object is blurred. Once a reasonable set of classes has been defined by the group, responsibilities can be added. Add responsibilities that are obvious from the requirements or the name of the class. You don't need to find them all (or any for that matter). The scenarios will make them more obvious. The advantage of finding some in the beginning is that it helps provide a starting place. Select the initial scenarios from the requirements document by examining it's verbs in much the same way that we scanned its nouns earlier. Then as many walk through sessions as necessary to complete the analysis phase are performed. When is enough of the analysis complete that design can begin? When all the different responsibilities are in place and the system has become stable. After all the normal behavior has been covered, exceptional behavior needs to be simulated. When you notice that the responsibilities are all in place to support the new scenarios, and there is little change to the cards, this is a sign the you are ready to start design. To be written... Identifying class diagrams from existing materials (Vision, Use Cases etc). To be written... Click on your target class. Then click on the note icon. ArgoUML will generate the link automatically. You can also right click to add a note as well! Be aware that you can add an undefined number of notes to any one class!
To be written... To be written... Click directly in the class model element and start typing. Do not use the properties window dialog fields—they are not fully functional and liable to cause you a little frustration. In fact, it would be interesting to see if you can type stereotypes right into the class attribute box for generating XML diagrams. To be written... To be written... Types of statechart diagram (Moore, Mealy); Hierarchical diagrams. To be written... To be written... To be written... Regardless of which methodology you use, at this time you are undoubtedly going to take the problem statement from Section 4.5, “Case Study” and extract the nouns from it. This list should be compacted to contain only those nouns that are expected to result in a class. This effort results in the following.
The project manager convenes a CRC session at which the initial set of classes are to be defined. The facilitator reminds the participants that we are in the analysis phase and are only interested in what needs to be done (at the business level) and are to leave out anything that smacks of how to do it. As a general rule of thumb this means a subset of the nouns from the problem statement (see above). The group starts with a complete list of all of the nouns in the statement, examines each one, and decides which are inappropriate crossing them off the list. Each class is then assigned to one of the participants. to be continued... To be written... To be written... We now have the problem we are trying to solve specified in the language of a putative solution. In the Design Phase, we construct all the details of that solution. The blurred boundary between Analysis and Design is reflected in their use of many of the same UML tools. In this chapter we will mostly be reusing UML technology we have already met once. The big step is casting everything into concrete terms. We move from the abstract concepts of analysis to their concrete realization. Once again the recursive, and iterative nature of our process means we will come back to the Design phase many times in the future. The design process extends the modeling effort beyond the business concerns and into the solutions space. It is during this effort that you decide whether you are going to use Java, C++, J2EE, CORBA, SOAP, Dial up line, internet connection dedicated line, XML, etc. Many of these decisions will impact directly the PSM model, others may only be reflected in the documents produced. ... Strength of CRC cards during Design
In this phase developers replace some of the domain experts in the group, but there should always be at least one domain expert in the group. The focus of the group moves from what is to be done to how to do it. The classes from the solution domain are added to those defined in the analysis phase. Think about what classes are needed to make the system work. Do you need a List class to hold objects? Do you need classes to handle exceptions? Do you need wrapper classes for other subsystems? New classes that are looked for in this part, are classes that support the implementation of the system. During the design phase the distinction between class and object becomes important. Think about the objects in your scenarios. Who creates the objects? What happens when it is created and destroyed? What is the lifetime of the object vs. the lifetime of the information held be the object? Now is the time to look at what information the objects hold compared to what is requested from other classes or computed on the fly. Use the back of the card to record the attributes found for the classes. Break you responsibilities into subresponsibilities and list the subresponsibilities indented under the main responsibilities. Move the collaborators next to the subresponsibilities that use them. After the Collaborator class on your card list the responsibility of the used class that is used in the collaboration. After the collaborating responsibilities on your cards, list the data passed back by the collaborating object in parenthesis. Redo the scenarios you did in the analysis phase, but know take into consideration all of the design heuristics discussed. Make up your own scenarios and try them. To be written... How to work out what goes in packages. To be written... To be written... To be written... To be written... More on identifying classes from existing materials and use of stereotypes. To be written... To be written... Add a unnamed interface to the current classdiagram by single-clicking on the interface icon in the tool bar and then clicking at the diagram pane (see Figure 6.1, “Selecting the Interface tool”). Then double click on the interfaces name field to change it's name as shown in Figure 6.2, “Interface model element on the Class Diagram” and type a name for it (like Add another interface with a different name by repeating the last 2 steps. Then single-click on the Generalization icon in the tool bar as shown in Figure 6.3, “Generalization on the Class Diagram tool bar”. Move the mouse pointer to the subinterface, press the left mouse button and drag the generalization to the superinterface, where you release the mouse button. The screenshot of Figure 6.4, “Generalization between two Interfaces.” shows how your diagram should look now. By clicking on the subinterface and the source tab properties pane, and then selecting Java Notation for the source tab, you can see that the interface actually extends it's superinterface.
To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... To be written... We now have our design fully specified. With the right simulator we could actually execute the design and see if it works. (ArgoUML does not provide such functionality, but this functionality has been provided in alternative tools.) ArgoUML does allow you to generate code from the design in several different programming languages. We, most likely, already in the design had a programming language in mind because some of the design considerations are to care for a specific language. The output of this process is the set of files that constitute the program that solves the problem. Once again the recursive, and iterative nature of our process means we will come back to the Build phase many times in the future. There is also another side to this and that is the reverse engineering side. If we happen to have an old program that we would like to examine then we could take the files and reverse engineer them to create a design. This can be used when trying to understand some not so well documented program or as a quick start for the design work. The process of going back and forth between doing changes in the design followed by a code generation and then doing changes in the code followed by a reverse engineering using for every change, the best possible perspective, is called Round-trip Engineering. The output of the Code Generation is the completed program. Depending on the contents of the design, we could also generate Unit test cases. To do the work we need the design model, containing both static and dynamic descriptions of the program. It is rather straightforward to do this generation, at least as long as we do it for an object-oriented language. This is some of the basic rules:
This conversion is not as straight-forward as the conversion of the static structure. It is much more depending on the target language and target platform. In general it is only possible to say the following for interactions:
The following describes one possible way to generate state machines:
Most of the generation can be done automatically by the provided language modules. Files are generated in a directory hierarchy that need to be filled in by the actual code. Reverse Engineering is used for two main purposes:
Essentially this does the opposite of Code Generation. Round-Trip Engineering makes it possible to switch perspective while doing the design. Create some classes in a class diagram. Write some code for some of the operations or functions using your favorite editor. Move the operations from one class to another in the class diagram... ArgoUML currently does not support this for any language. This chapter describes the overall behavior of the user interface. Description of the various component parts—the menu bar, panes and various diagrams— is in separate chapters. Figure 8.1, “Overview of the ArgoUML window” shows the main ArgoUML window. The titlebar of the window shows the following 4 parts of information, separated from each other by a dash.
At the top of screen is a menu bar, which is described in Chapter 10, The Menu bar. Below that is the toolbar, as described in Chapter 9, The Toolbar. The bulk of the window comprises four sub-windows or panes. Clockwise from top left these are the explorer (see Chapter 11, The Explorer), editing pane (see Chapter 12, The Editing Pane), details pane (see Chapter 13, The Details Pane) and to-do pane (see Chapter 14, The To-Do Pane). All 4 panes have a tool bar at the top (in the details pane it is located under the properties tab). An overview of the panes is given in Section 8.3, “General Information About Panes”. Finally at the bottom of the window is a status bar described in Section 8.4, “The status bar”. Mouse behavior that is specific to the various panes of ArgoUML (see Section 8.3, “General Information About Panes”) or the menu bar, is discussed in the chapters covering those panes and the menu bar. In this section we cover behavior that is general across all of ArgoUML. In a number of places in ArgoUML text may be directly edited (for example the constraint editor—see Section 13.7.1, “The Constraint Editor”). The behavior of the mouse when handling text is discussed in the sections that follow. ArgoUML assumes a two button mouse. We will refer to the buttons as “button 1” and “button 2”. Button 1 is the leftmost button on a right-handed mouse, and sometimes referred to as the select button. Button 2 is the rightmost button on a right-handed mouse, and is sometimes referred to as the adjust button. A single depress and release of a mouse button with the mouse is referred to as a click. Two clicks in quick succession is referred to as a double click. Moving the mouse while holding a button down is referred to as button motion with the starting point being at button down and the end point at button up. Clicking on an user-interface object or on a diagram model element may establish many different things. Most of the behaviour is experienced quite intuitive by the user, mainly because the high degree of standardisation, even spanning different computer platforms (Macintosh, PC, UNIX,...). ArgoUML follows the Java Look and Feel Design Guidelines by Sun. See http://java.sun.com/products/jlf/. Hence, behaviour of common user-interface components is generally not discussed in this document. On the other hand, mouse actions in a diagram may not seem so intuitive to the user, since it is specific for ArgoUML. Hence they are explained here. In short, clicking selects or activates the object beneath the mouse-pointer, and moves the focus (i.e. navigation). More in detail, the button 1 click may cause the following result: Here button 1 is used to choose (select) a model element (in a list or tree or on a diagram) on which subsequent operations will take place. Multiple model elements may be selected by using Shift and/or Ctrl in combination with button 1, see Section 8.2.5, “Shift and Ctrl modifiers with Button 1”. Selection is always clearly indicated by a colored background. On a diagram, the selected model element is indicated with colored "blocks" at the corners/ends of the object. Model elements can be selected or deselected in different ways:
Here button 1 is used to activate the user interface component, e.g. a button. The object is usually highlighted when the mouse button is pressed and then activated when the mouse button is released. Activating an user-interface object means that its function is executed. Here button 1 is used to move the focus from one user interface component or diagram model element to another. It is better known under the term keyboard focus. This because keyboard commands usually work on the model element that has the focus. The focus is indicated by a (hardly visible) box around the model element, or for a text entry box, by a flashing cursor. The behavior of button 1 double click varies betweens panes and is discussed in their chapters. This behavior applies where there is a list of things that may be selected. This includes various dialog boxes, and the to-do pane, where there is a list of to-do items to be selected. Where selections are to be made, the SHIFT key is used to with button 1 to extend from the original button 1 selection to the current position. Similarly the CTRL key with button 1 is used to add individual items to the current selection. Where Ctrl-button 1 is used on an item already selected, that item is removed from the selection.
In a number of places in ArgoUML text may be directly edited (for example when naming a model—element in the properties pane, or when typing a UML note / comment). Here SHIFT button 1 is used to select a range of text from the previously selected point. Subsequent operations (text entry and deletion) will replace the selected text. When holding down the Alt key during button 1 down on a diagram, movement of the mouse pans the drawing area. The function is indicated by the mousepointer which turns into a crosshair with arrows. When holding down the Ctrl key while dragging with mouse button 1 down on a diagram, the movement of the dragged element element will be constrained to one of eight cardinal directions : North, South, East, West, NE, SE, SW, NW. Button 2 actions are all dependent on the pane or menu bar, and discussed in their various chapters. Button 2 actions are all dependent on the pane or menu bar, and discussed in their various chapters. The four sub-windows of the main ArgoUML window are called panes. Clockwise from top left these are the explorer (see Chapter 11, The Explorer), editing pane (see Chapter 12, The Editing Pane), details pane (see Chapter 13, The Details Pane) and to-do pane (see Chapter 14, The To-Do Pane). At the top the editing pane is a tool bar. You can re-size panes by dragging on the divider bars between them. To indicate this possibility, the mouse cursor changes shape when hovering over the divider bars. In addition you will see there are two small left pointing arrows within the vertical divider bars, one at the top of the vertical divider bar between explorer and editing pane and one at the top of the vertical divider bar between to-do pane and details pane. Button 1 click on the first of these will expand the editing pane to the full width of the window, button 1 click on the second will expand the details pane to the full width of the window. There is also a small downward pointing arrow within the horizontal divider bar at its leftmost end. Clicking on this will expand the explorer and editing panes to the full depth of the window. By using both the top arrow on the vertical divider and the arrow on the horizontal divider, it is possible to expand the editing pane to use the entire window. The original configuration can be restored by clicking again on these arrows, which are now located at the edge of the window. These buttons have identical functions as their
counterparts in the
These buttons have identical functions as their
counterparts in the
The
These buttons have identical functions as their
counterparts in the
An important principle behind ArgoUML is that actions should be able to be invoked in whatever way the user finds convenient. As a result many (but not all) actions that can be carried out on the menu can be carried out in other ways as well under ArgoUML. A number of the common menu entries are also available through keyboard shortcuts. It is also be possible to navigate the menu from the keyboard. Each level of each menu is identified by a letter (shown underlined in the menu or entry name from the moment the ALT key is pressed). This sequence of letters while holding down the ALT key selects the entry. The following is an explanation of why the menuitems are grouped as they are.
Behavior of the mouse in general, and the naming of the buttons is covered in the chapter on the overall user interface (see Section 8.2, “General Mouse Behavior in ArgoUML”). There is no ArgoUML specific behaviour for the menu. These are actions concerned with input and output and the overall management of projects and the ArgoUML system. Shortcut Ctrl-N. This initializes a new project within ArgoUML. The
project is created without a the name. It contains a
(top-level)
If the model has been altered (as indicated by the "*" in the titlebar of ArgoUML's window), then activating the "New" function is potentionally not the user's intention, since it will erase the changes. Hence a confirmation dialog appears to allow the user to save his work first, or cancel the operation completely. Shortcut Ctrl-O. This opens an existing project from a file. Selecting
this menu option will open a file selection dialog (see
Figure 10.2, “The file selection dialog for The main body of the dialog is a text area with a listing of all directories and files in the currently selected directory which match the current filter (see below). Navigating in the directory tree is possible by selecting a directory in the drop down selector at the top of this dialog. Navigating deeper in the tree may be done by double clicking button 1 on the directory shown in the main text area. In the lower portion of the dialog is a text box
labeled Beneath this is a drop down selector labeled
Shortcut Ctrl-S. This saves the project using its current file name. Use
This opens a dialog allowing you to save the project under a different file name (or to specify a file name for the first time if the project is a new project). The dialog box is almost identical to that for This menu-item allows you to throw away all your recent
changes, and reload the last saved version of the current
project. It works a bit like an This menu-item is downlighted unless the currentproject has been saved or loaded before (i.e. it has a name), and it has been altered. When this menu-item is activated, a small confirmation
dialog box opens, as shown in the figure below. This warning
that all recent changes will be discarded, is needed because
the action can not be undone. Selecting This menu-item allows to load an
UML 1.3 or 1.4 model which was exported by e.g. another tool,
as a XMI file, according the XMI V1.0, V1.1 or V1.2 standard.
The extension of such file should be If the model has been altered (as indicated by the "*" in the titlebar of ArgoUML's window), then activating the "Import XMI..." function is potentionally not the user's intention, since it will erase the changes. Hence a confirmation dialog appears to allow the user to save his work first, or cancel the operation completely. When the menu is activated, the standard filechooser
appears, see Figure 10.5, “The dialog for This menu-item allows to save the complete structure of
the UML 1.4 model as a XMI file, according the XMI V1.2 standard.
Beware the fact that this file will only contain the model,
not any diagram layout. Hence, if the XMI file is reloaded
with the When the menu is activated, the standard filechooser
appears, see Figure 10.6, “The dialog for A very powerful feature of ArgoUML is that it can “Reverse Engineer” Java code to yield a class diagram. This sub-menu entry specifies Java code to be imported for reverse engineering. The dialog box is similar to that for Those fields that are the same as Next to the "All Files" file filter, there is the default filter "Java Source File (*.java)". The first of the two tabs is labeled
The second of the two tabs is labeled
This brings up the standard dialog box provided by the operating system to adjust printer paper size, orientation, and other options. Shortcut Ctrl-P. This brings up the standard dialog box provided by the operating system allowing the current diagram to be printed out. In some cases, when the printing is started, the dialog box of Figure 10.8, “The diagram exceeds page size dialog.” appears. Selecting the "Fit to page" button does print the whole diagram fitted on one page by scaling it down. Which might cause all text to be too small to read in case of big diagrams, but it is a quick and easy way to get an usable printout. Selecting the "Multiple pages" option does print unscaled, by dividing the diagram in pieces, on as many pages as needed. Pressing the close button of the dialog does the former option.
This menu entry brings up a dialog box allowing the currently selected diagram (in the editing pane) to be saved in one of a number of graphic formats. The dialog box is identical to that for The available graphics types are:
The graphics format that is selected by default is set in the dialog under the menu entry Edit - Settings... This menu entry brings up a dialog box to select a directory. In this directory, for all diagrams in the current project, a graphics file is generated. The names of the files are deducted from the diagram names.
The graphics format that is produced
is set in the dialog under the Edit menu
(see Section 10.4.5, “ This sub-menu presents a radio button selection for notation, i.e. the language in which all textual adornments are shown on the diagrams. This feature defines the project's notation language. There are 2 ways to set the notation language:
The following 2 notations are build in ArgoUML:
The following choices are only available if the corresponding plugin languages are installed.
Besides UML, only Java is partly implemented in V0.22 of ArgoUML. This menu entry brings up a dialog box, which allows the user to set various options of the currently loaded project. All settings in this dialog are stored in the project-file together with the model. In the User tab, you are able to set the following fields:
In the Profiles tab, you are able change the following settings:
In the Notations tab, you are able to set the following fields:
In the Diagram Appearance tab, you are able change the diagrams font. ArgoUML remembers a few of the most recently saved files, and lists them here, to enable loading then in the most simple way. The maximum number of files that is listed here, can be
adjusted in the Shortcut Alt-F4. This closes down ArgoUML. A warning message will pop-up if you have a project open with unsaved changes asking if you wish to save it. See Figure 10.13, “The save changes dialog.”. The options are:
This menu provides support for selecting model elements on the editing pane; removal of model elements from diagrams and the model; and control of user settings. This sub-menu provides for selection of items on the editing menu. It has the following entries.
Shortcut Delete. This removes the currently selected item(s) from the diagram, but not from the model. The modelelement can be re-added to the diagram by button 2 click on the modelelement in the explorer, or by dragging it onto the diagram. Shortcut Ctrl-Delete. This function deletes the selected item(s) from the model completely. If the item to be deleted is also present on another diagram than the current one, the dialog box from figure x appears. This menu-item invokes the same dialog as the button at the top of the explorer. See Section 11.5, “Configuring Perspectives”. for a complete description. This menu entry brings up a dialog box, which allows
the user to set various options that control the behavior of
ArgoUML (see Figure 10.15, “The dialog for These settings are saved persistently for use by subsequent ArgoUML sessions. ArgoUML has various user specific configurations that can
be set in this dialog box,
or directly on the various panes. Also the main window
size and location is such a setting. Activating this menu
entry causes the information to be saved in the file
The options that can be set up on the various tabs are described in the following sections. For each tab there are three buttons at the bottom of the dialog box.
Closing the dialog (with the close button in the top
corner in the border of the window) causes the same effect as
Selecting the
Selecting the
This tab allows the user to record additional information of use to the system. There are two text boxes provided.
This information is used when requesting to-do help by Email. This tab allows the user to specify the LAF (Look And Feel) and theme, i.e. what the complete ArgoUML UI looks like. It comprises the following settings.
In this tab the user may configure the ArgoUML application settings related to the profiles.
(To Be Written) This tab allows the user to specify certain notation settings, i.e. how things are shown on diagrams. It comprises the following check boxes. All settings here, only define the defaults used for new projects. If you want to change the way the diagrams in your current project look, then see the File - Properties menu.
(To Be Written) This tab shows a list of modules that are installed, which may be enabled or disabled. Since this is a new concept for ArgoUML, it currently contains a list of modules that can not be removed, and a button to test the concept. Pressing this button adds a useless menu-item on the Tools menu, nothing else. Notice also that this is a "new" modules concept so the old Pluggable modules do not work this way, and are not listed. This menu is used for actions that affect how the various panes are viewed. This menu entry brings up a dialog box, describing all the diagrams in the current project under ArgoUML. The dialog box contains a table with three columns and one row for each diagram in the current project. A scroll bar gives access if the table is too long for the box. Double button 1 click on any row will select that diagram in the editing pane. The three columns are as follows.
This dialog box is not modal, which allows it to remain open while editing the model for easy navigation.
This menu entry brings up a non-modal dialog box for the ArgoUML search engine. The
The lower two thirds of the dialog comprises an initial
tab (labeled Button 1 double clicking on these tabs removes the tab, and spawns a new window that contains the tab contents, i.e. the search results. This window can be moved and sized at will. This does not work for the help tab. The top half is labeled
Button 1 click on any row will give more information on that model element by showing related model elements in the bottom half (see below). Double click on any row describing a model element on a diagram and that item and diagram will be selected. The bottom half of the tab is a table labeled
This entry brings up a sub-entry, which allows scaling the view of all diagrams to a factor of its normal size. This setting is not saved persistently. The sub-menu items that can be selected are:
This allows selection of the grid representation on the screen between the following:
This allows selection of the spacing of grid snapping between the following:
This toggles whether page breaks are shown on the diagram (as white dotted lines).
This menu allows the user to hide or show any of the bars at will. By default, all of them are shown. This menu provides for creating the various types of UML diagrams supported by ArgoUML. This menu entry creates a blank use case diagram, and selects that diagram in the editing pane. If a package is currently selected, then the use case diagram will be created within that package. This means that it will be shown within the package on the explorer hierarchy (under Package-centric view) and model elements created on the diagram will be created within the namespace of the package. This does not only apply to a package, but also to a class, interface, use case, etc.
This menu entry creates a blank class diagram, and selects that diagram in the editing pane. If a package is currently selected, the class diagram will be created within that package. This means that it will be shown within the package on the explorer hierarchy (under Package-centric view) and model elements created on the diagram will be created within the namespace of the package. This does not only apply to a package, but also to a class, interface, use case, etc.
This menu entry creates a blank sequence diagram, and
selects that diagram in the editing pane.
It also creates a This menu entry creates a blank collaboration diagram,
and selects that diagram.
It also creates a | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Note]](images/note.png)
![[Warning]](images/warning.png)
![[Caution]](images/caution.png)
![[Tip]](images/tip.png)
