To tackle the ongoing design process of the TCMS system, you should follow a simple design roadmap that will guide the reader through the creation of the models and the consequent production of the code that will materialize those models into a working software system. The roadmap consists of several steps or activities, many of which can be accomplished in parallel as follows:
The activities described provide a baseline for the development plan. As the system evolves, the choices of the models and diagrams created have a high impact on how a specific problem is solved. Experience is the best guide as to how to pick the number and types of diagrams needed. Again, always remember that the code is the final product and no amount of diagrams will make a customer happy. Figure 2-1 shows a diagram depicting the activities followed for the TCMS system.
The OMG, in its introduction to the UML, recommends that when getting started with OOAD and modeling you should first select a methodology or process and then select a modeling tool that properly supports the chosen methodology. The reality is that itís hard to judge what methodology will be a better fit for a certain project. Itís only after working with the same team on a similar system that you can say with confidence whether a methodology is a good fit or not. Consequently, choosing an OOAD, UML-compliant CASE tool is also no easy task and the high price tags associated with the leading CASE tools could make a bad decision in this area have a negative impact on the bottom line, especially for mid-sized and small businesses.
Although a set of models as depicted in this book might give you the impression that the design was done in a ďbig design up frontĒ (BDUP) fashion as Scott Ambler of agile modeling fame refers to it. 11 The reality is that the models depicted in this chapter are the result of an evolutionary process that took a nontrivial amount of time and involved throwing away many intermediate models. The result of this process is displayed in this chapter, and then we will concentrate on development-centric issues in the rest of the book.
Itís important to understand that many times a modeling tool just gets in the way of modeling. Many times a whiteboard, some markers, and a couple of Post-it notes are all you need to successfully model a system.
A common practice is to bring a digital camera and take snapshots of a model on a whiteboard as the modeling process progresses. CASE tools havenít yet matched the level of collaboration that sharing a marker with a colleague achieves.
To fill the void for a low-cost CASE tool, the Open Source community has ArgoUML. ArgoUML is a 100-percent Java, Open Source (under the Berkeley Software Design License, or BSD) UML-based CASE tool. Jason Robbins and David Redmiles (Robbinsís advisor) started the ArgoUML Open Source project as part of Robbins doctoral work on cognitive issues in software design at the University of California, Irvine in the late 1990s. ArgoUML is quickly evolving as the Open Source alternative in the CASE tool world and its rapid adoption has had a compounding effect on the quality of the tool.
ArgoUML, although feature-rich, still lacks some of the features of high-end commercial tools. The good news is that itís built on pluggable modules that allow it to grow in a controlled fashion. ArgoUML is part of the Tigris.org Open Source project, a mid-sized Open Source community focused on collaborative development tools (http://www.tigris.org). ArgoUML is the most prominent and active project on the Tigris.org site.
ArgoUML is a very active project and the tool is rapidly evolving. Bugs and instabilities are being fixed at a fairly fast pace. Itís built on a solid foundation that uses other high-profile and stable Open Source projects like Ant (Another Neat Tool) for building and ANTLER (ANother Tool for Language Recognition).
ArgoUML is currently compliant with version 1.3 of the UML standard. ArgoUML modular architecture employs a pluggable metamodel library that enables fast adoption of new versions of the UML standard. It also supports other standards like the XMI format (version 1.0) for the exchange of models with other tools (XMI is the standard mechanism used by ArgoUML to save models.) ArgoUML also has full support for OCL syntax and type checking as well as limited support for code generation via the ANTLR project.
Jason Robbins initially built ArgoUML as a test bed for ideas in cognitive psychology and their applications to software design. These features are unique to ArgoUML and include design critics, corrective automations, to-do lists, usage-based tool adaptation and design checklists among others. Several of these features help you keep the task of modeling focused on results rather than on the process that aligns well with the philosophy of XP. As Scott Ambler of agile modeling fame explains, a model is agile when itís sufficiently understandable, accurate, consistent, and detailed (the emphasis being in the word ďsufficientlyĒ).12 In XP terms a model should be as simple as possible but not simpler.Obtaining and Installing ArgoUML
Itís recommended that the Java Web Start (JWS) enabled version of ArgoUML is used given the simplicity and power that the JWS launching platform provides. With the JWS version of ArgoUML, installation and upgrades are automatic. To find out how to obtain and install the JWS-enabled version of ArgoUML or the stand-alone version, seehttp://argouml.tigris.org/servlets/ProjectDocumentList.
For more information on Java Web Start see http://java.sun.com/products/javawebstart/.
User Interface Overview
ArgoUML is a 100 percent swing-based Single Document Interface (SDI) application. The main application window consists primarily of four main panes, a menu bar, toolbar and status bar as shown in Figure 2-2.
Now would be a good time to launch ArgoUML and begin exploring the user interface. There are many panes and controls available, and youíll need to remember a few of them in order to effectively work in ArgoUML. ArgoUML comes packaged with an array of sample models for you to explore in the www/models directory, under the installation directory.
The Navigator Pane
The Navigator pane provides a tree-based view of the model elements that can be dynamically changed based on the desired view and working model of the designer. The Navigator pane is the main navigational mechanism. The tree view allows you to expand and collapse nodes, thereby revealing or hiding model elements as needed. It allows the tree view to be structured using several options. The Package-centric and Diagram-centric views will cover most of your needs. Table 2-2 shows the different model views available in the Navigator pane.
Package-centric is the default view, and it shows a hierarchy of objects for which the root is the model. Child nodes can include packages, diagrams, and any top-level but independent elements of any diagram (such as actors for a top-level use case diagram). The Diagram-centric view provides a rootless organization, which shows only diagrams at the top level and all other elements as children of the diagrams theyíre used in.
blog comments powered by Disqus