Drawing Diagrams in ArgoUML - Practices

The ArgoUML interface should be familiar to anyone who has used a drawing tool or another UML CASE tool. Diagrams are drawn using the tools available on the Editing pane toolbar, by selecting an artifact and clicking the diagram to place it at the desired position. Most model artifacts are meant to be associated with other artifacts in a diagram. In ArgoUML you have access to the most used association for a given element right from the element itself. By selecting a model artifact or hovering with the mouse over an already selected model artifact, you’ll see squares appear on the artifact’s periphery that hint at the possible associations available. To use them, simply click and hold the desired association hint (square) and drag it to another artifact in the diagram. Figure 2-3 shows the association hints for a class artifact.

Figure 2-3. Association hints

Besides UML artifacts, the toolbar also provides general drawing tools to create rectangles, circles, lines, polygons, curves, and free-flowing text. These can be used to complement and supplement the expressiveness of a given diagram.

One of the features unique to ArgoUML is the Broom Alignment tool, which supplements the usual array of positioning- and alignment-related commands. This tool enables you to sweep several diagram elements horizontally or vertically, thereby aligning them. The Broom tool is the rotated T-shaped button (second from the left on the toolbar). The Broom’s orientation is determined by the initial mouse gesture. After you select the direction, you can move the mouse and sweep elements against the edge of the broom. Moving the mouse perpendicularly in the direction of the broom increases the size of the broom’s edge, thereby allowing you to cover a larger area with possibly more elements.

Case Study: Modeling the TCMS with ArgoUML

The next step is to create an analysis object model, also known as a domain model, based on the design roadmap. The choice of whether to model structure or behavior first is a hotly debated topic in object-oriented circles. In cases where the domain is well understood it’s beneficial to start by consolidating the domain knowledge into a domain model. Well-chosen abstractions that are a true reflection of the business domain will naturally fall into the right roles when modeling behavior.

In ArgoUML, select File -> New Project (or press Ctrl-N). A new project will be created with a root element model that contains two children nodes, a class diagram, and a use case diagram, as shown in Figure 2-4.

Figure 2-4. New project

Next you can rename the model root element by selecting it on the Navigator pane and then selecting the Properties tab in the Details pane. Alternatively, you can right-click the Navigator node and select Properties. In the Name field on the Properties tab, enter Tcms. Notice that the To-Do pane (lower left-hand corner) has changed to the By Goal view for critiques or to-do items, and Unspecified is the root node of the tree view. Expanding the Unspecified node will reveal the following two subitems:

• Revise Package Name Tcms

   

• Add Elements to Package Name Tcms

   

Select the Revise critique and the text will appear on the To-Do tab of the Details pane, explaining the critique, as shown in Figure 2-5.

Figure 2-5. Critique details

The design critic tells you that it’s a good practice for package names to be written in lowercase. To automatically fix the package name, select the Next button, which will show the suggested new package name as “tcms”. You can now select the Finish button and the change will be automatically applied. Remember that the critiques are suggestions, which you can choose to ignore. Also you can choose to manually rename the model as stated in the critique explanation.

Under the tcms package you’ll want to create two packages. One package will contain all diagrams for the domain analysis and the other will keep all the solution-space design diagrams. To create a package, right-click the tcms package and select Add package. A new package will appear with the name “(anon Package)”. Select the new package on the tree view and, using the Properties tab, change the name to “domain”. Repeat this operation and create another package under the tcms named “solution”. You’ll also want to remove the current default diagrams and create new diagrams under the newly created packages. To remove a diagram you can right-click it and select Delete from Model. Notice that you can only delete one of the diagrams. For a model to be valid, ArgoUML requires at least one diagram to be present. Before you remove the remaining diagram in the model, you need to create a diagram under the domain package.

To add a class diagram select the domain package on the Explorer and from the menu select Create Diagram -> Class Diagram. Rename the new class diagram “Class Diagram”. Now you can proceed to remove the remaining diagram at the root of the project. The resulting project should look like the one depicted on Figure 2-6.

Figure 2-6. TCMS ArgoUML project

Finding and Refining Candidate Domain Model Elements

Based on the TCMS vision documents and high-level architectural blueprints introduced earlier, you can compile a list of candidate domain models. For this one you could use Class-Responsibility-Collaboration (CRC) cards or simply (as performed here) create a list of nouns and verbs by manually scanning the source documents. This process isn’t merely a manual process, because it entails analyzing the understanding of the system and eliminating and discovering new candidate

classes and new operations that weren’t present in the source documents. This newly discovered domain knowledge can then be added to the source documents to ensure that it isn’t lost.

The resulting filtered list of nouns is obtained by collapsing synonyms and eliminating nonentities (candidates that might be properties or modifiers, or may represent a state of an object). After analysis the resulting list shrinks in size. Now, the structural relationships between the candidate objects can be modeled. This process will further refine the candidate objects and will resolve many ambiguities about the understanding of the problem domain that you haven’t previously encountered. The list of Nouns representing candidate entities is show in Table 2-3.

Table 2-3. TCMS Candidate Entities (Nouns)

Noun	Description
Sponsor	A sponsor is an individual or company that is
	“sponsoring” a conference.
Conference administrator	An administrator is an individual that has privileged
	access to conference-related functions.
Presenter	A presenter is an individual that presents one or more
	sessions.
Attendee	An attendee is a registered user who is attending a
	conference.
Organization	A nonindividual legal entity.
Conference	An event that consists of one or more sessions.
Conference Track	A high-level classification of the topics covered in
	a conference.
Presentation	A collection of materials and information to be conveyed
	to an audience in a predetermined amount of time.
Session	An event that embodies the act of “presenting” a
	presentation.
Schedule	A list of events that an attendee or a presenter will
	attend during a conference.

Venue A physical location where a conference takes place.

Table 2-3. TCMS Candidate Entities (Nouns) (Continued)

Noun Description

Booth A temporary structure where sponsors can showcase their products during a conference.

Room A room that is part of a venue.

Abstract A document that explains the intent of a given presentation in compressed form.

---

 

Following Peter Coad’s domain neutral component, you start the modeling of the actions embodied in the verbs (action phrases) gathered as objects in your domain model. Based on research into parallel object-oriented programming languages conducted at Stanford University¹⁴ it was concluded that real-time tasks such as making a reservation or purchasing an airplane ticket should be modeled as objects that encapsulate (facade) the complexity of the task and simplify the associations between participating objects.

The question of whether to model the structure or behavior first is one that many beginning and intermediate modelers deal with during every new project. We recommend doing both simultaneously because modeling behavior validates the structural integrity of the model, and well-defined entities that reflect a domain naturally fall into place when modeling behavior.

---

TIP

Don’t overanalyze with the noun and verb exploration. Concentrate on finding the principal candidates; others will emerge as you refine the analysis and design.

---

With this preliminary list of nouns you’ll begin to construct a static model and the behavioral part of the domain model will begin to emerge. We emphasize that this is an iterative process and that the models produced will evolve as the system is constructed. In addition, certain assumptions made are validated while others are refuted. Remember, the analysis of the system helps you gain a deeper understanding of it, but doesn’t prevent you from deducing knowledge that might be erroneous and based on naive, preconceived notions.

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus