Design with ArgoUML - Design Roadmap (Page 4 of 11 )
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:
- Creation of an analysis object model (domain model): An understanding of the domain is documented in the form of a static model (class model) that will serve as guidance during the requirements analysis and creation of the design models. This step gives a high-level foundation from which it’s easier to see subsystems of related objects and components emerge. A domain model also serves as a way to validate any assumptions or preconceived notions about the domain and solidifies and centralizes the knowledge about the problem domain.
- Requirement analysis: Actors are defined from the analysis and architectural documents. User use cases (a use case that fulfills a specific feature) are created for high-level interactions of the primary actors with the system. User use cases are then decomposed into system-level use cases if necessary. System-level use cases depict actions taken by specific components in the system to accomplish a task needed for the fulfillment of a user use case. Quick assessment of the reuse of system-level use cases is performed. High- priority use cases are written in detail to curtail major risks (detail doesn’t mean implementation-specific details). Analysis of requirements continues iteratively for as long as the project or product is alive.
- Iteration planning: Iterations are planned based on a group of use cases. Integration planning is performed to determine points of integration and modifications, or enhancements to the overall automation of the integration process are made. In this book each chapter is set as an iteration that sets out to fulfill a certain number of use cases.
- Iteration execution: Detail is added to use cases, both user and system use cases. Tests are written for each feature, and integration code or scripts are created or enhanced. Detailed dynamic models are created (detailed enough to be implemented and detailed enough to utilize any forward-engineering features of the CASE tools available to the maximum). Class diagrams for any subsystems created are defined and the overall model diagram is updated to reflect the results of the iteration. Whenever necessary, component diagrams and subsystem diagrams are created, thereby displaying the component interfaces and their relationships to the object models.
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.
Figure 2-1. TCMS system-design roadmap
ArgoUML
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.
NOTE
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.
TIP
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.
NOTE
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.
Figure 2-2. The ArgoUML UI
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.
Table 2-2. ArgoUML Navigator Pane Model Views
| Navigator View | Description |
| Package-centric | The default view, it provides a hierarchical view of all |
| | packages, diagrams, and contained modeling elements. |
| Class-centric | Shows classes in their package hierarchy as well as |
| | datatypes and use case diagram elements. Similar to the |
| | Package-centric view but it doesn’t show connecting or |
| | associating elements. |
| Diagram-centric | A rootless view showing only diagrams as top-level |
| | elements. |
| Inheritance-centric | Shows a hierarchy of modeling elements based on |
| | inheritance. This view is relevant mostly when dealing |
| | with a hierarchy of class elements. |
| Class Associations | Shows a hierarchy of classes and their associations |
| | (circular associations will be expanded ad infinitum!). |
| | It also shows all diagrams at the top level. |
| Navigable Associations | Supposed to show associations among classes (not |
| | working as of version vPRE-0.14.a1). |
| State-centric | This view shows relationships between elements of a |
| | state diagram. |
| Transitions-centric | Shows all transitions between elements of a state |
| | diagram at the top level with their elements connected |
| | by the transition as children. It also shows the state |
| | diagrams in the model at the top level. |
| Transitions paths | This view shows all transition paths between elements of |
| | a state diagram in a tree hierarchy. Circular paths can |
| | also be expanded ad infinitum. |
| Collaboration-centric | A rootless tree showing all collaboration diagrams in the |
| | model and their elements. |
| Dependency-centric | This view shows a hierarchy of dependencies between |
| | diagram elements (currently not working). |
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.
Next: The Editing Pane >>
More Practices Articles
More By Apress Publishing
|
 This article is taken from chapter two of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259). Check it out at your favorite bookstore today. Buy this book now.
|
|
