Design with ArgoUML

This article provides an overview of the practical application of object-oriented analysis and design (OOAD) design concepts and the Unified Modeling Language (UML). It 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)

“Luck is the residue of design.”

JAVA HAS FOUND a niche in the server side of contemporary distributed computing, in which the most prevalent service model is the browser-based application or web application. The rise of the Internet as a global network for business has given enterprise computing its greatest weapon and also its greatest challenge. More power and possibilities mean more challenges and complexity.

Software engineers have realized that without a solid architecture and some semblance of a process that emphasizes analysis and design, a project’s failure is all but imminent. Keeping with the demands of the evolving “connected” enterprise is no easy task; applications not only need to work well, but have to work well together. Interoperability, maintainability, scalability, and performance are now implied characteristics when one speaks about an enterprise system. When designs, in the form of models reflecting an architectural vision, are the driving force behind implementations, systems evolve in a controlled fashion. The opposite scenario, implementation-driven systems that grow in an organic fashion, are destined to head down a certain path of “architectural drift” in which an application moves further away from its intended goal of servicing the needs of stakeholders with each development iteration.

This chapter aims to be a brief overview of the practical application of object-oriented analysis and design (OOAD) concepts and the Unified Modeling Language (UML). OOAD techniques are used to provide a solution to the problems presented in the case study. You’ll tackle the initial design of the Technology Conference Management System (TCMS) system using ArgoUML, a freely available Open Source modeling tool. Object modeling tools have historically been fairly high priced. Open Source offerings such as ArgoUML diminish the high entry cost for adopting a modeling tool.

The initial analysis and design of the system is performed in this chapter by elaborating and expanding upon the knowledge gained about the TCMS case study system introduced in Chapter 1. In the interest of an iterative and incremental development process, subsequent chapters introduce, elaborate, or re-factor the design of a specific subsystem, feature, or component.

Object-Oriented Analysis and Design Overview

OOAD is a combination of problem solving mechanisms that facilitates the two following primordial tasks of software engineering:

  • Understanding and describing a particular problem and its domain
  • Formulating a conceptual solution to a problem


The results of OOAD are expressed in the language of objects. These results should be independent of the process or methodology used. Yet OOAD doesn’t work in a vacuum, for the principles and guidelines it promotes are meant to be used in the larger context of a software development process. Always keep in mind that the models produced by analysis and design are used both to understand the problems and to formulate a design that must eventually become code. The final product is in the trade code; without code there is no measurable level of completion. That said, it’s important to remember that technologies come and go and that many times the same problem gets solved over and over during the life of a company. Code isn’t the best artifact to carry knowledge and problem-solving lessons into the future—models are.

The case-study application introduced in this book is a tad more complex that the typical trade book example, yet it’s still simple enough to be understood in its entirety by one individual. This is far from the norm; rarely do you start with a manageable set of requirements, and only in rare cases is it possible for one individual to have a complete understanding of every detail of a system. You’ll use models for managing the complexity of systems, which further your understanding of the systems as artifacts of knowledge continuity.

Understanding the Problem with Object-Oriented Analysis

Object-oriented analysis (OOA) is concerned with developing requirements and specifications expressed in terms of objects that accurately represent a particular problem domain. OOA helps determine what is to be built rather than how to build it. Analysis aims at capturing the essence of a problem without introducing implementation-specific artifacts that can taint future design decisions. The process of analysis can be further qualified into requirements gathering and object analysis.

During the requirements-gathering phase you should be concerned with the discovery and understanding of the requirements. Use-case modeling is the primary technique used in this book to gather, evolve, and manage requirements. Although use-case modeling isn’t specifically an object-oriented activity, it has proven extremely beneficial when used in conjunction with OOAD techniques.

In the real world, requirements aren’t set in stone and the discovery of new requirements goes on for as long as or even longer than the lifetime of most software systems. Most methodologies have come to accept this fact and acknowledge changing requirements as a primary driving force in the software development life cycle. In iterative development an iteration involves the management of requirements. The number of requirements discovered and the changes to existing requirements are expected to diminish as the system evolves iteratively.

During object analysis, the focus shifts to the discovery of the domain entities at the conceptual level, with an “emphasis on defining software objects and how they collaborate to fulfill the requirements.”1 The products of this activity are conceptual object models that provide a visual organization of the concepts needed to create a coherent design.

Solving the Problem with Object-Oriented Design

Abstraction, encapsulation, information hiding, and generalization play a primary role in design. Software design hinges on the ability to disregard inessential details and focus on the essential. The goal of OOD is to arrive at a system as simple as possible that meets the stakeholders’ requirements while allowing a certain amount of flexibility. OOD entails the modeling of a system’s structure and behavior in terms of objects and interactions among objects. OOD tackles the development of object models that represent a solution to a problem in a specific problem domain. These object models represent a solution to a problem in the solution domain (technology-specific, less abstract, geared toward being implemented in code) while maintaining conceptual consistency with the problem domain.

OOD builds on the products developed during analysis by refining and mapping these into an object-oriented programming language (OOPL). Analysis, design, and coding are closer to each other in the world of objects than in other paradigms. For this reason, the notations used during analysis and the early stages of design are very similar. However, in OOD, technology-specific concepts that were nonexistent in analysis need to be specified, such as the datatypes of the attributes of a class, or the business logic in a class’s methods. Knowing when analysis ends and design begins is usually hard for those new to modeling. Some would argue that it’s more of an art than a science.



When in doubt about whether a piece of information belongs in the analysis or design model, ask yourself the following questions: If removed, will it diminish the understanding of the problem? Will it prevent a developer from correctly implementing a feature?


Models and Modeling

The main artifacts of OOAD models are visual representations of a system’s components and the interactions between those components. Edward Tufte, a pioneer in the field of information design tells you that “graphics reveal data.”2 This statement is particularly truthful when applied to software models. Models can reveal hidden characteristics of a system. They can help you see a system at different resolutions, and different angles. A model can focus on structure, behavior, or both. Simply speaking, a model is a visual abstraction for the purpose of understanding something before it is to be built.

The power of models lies both in their visual expressiveness and their ability to focus on a particular view or concern of a system at a time. Textual descriptions are great to enhance or clarify the description of an entity or process, but as with any representation based on natural language, ambiguities are easily introduced. Visual models reduce the ambiguity of textual descriptions by infusing objectivity through a constrained but extensible set of syntactical and semantical rules.

Models are vital tools in understanding and conveying problems and their solutions. They provide structure and a measurement of feasibility that isn’t easily captured in textual descriptions alone. A model can help pinpoint areas of risk in a soon-to-be-developed system and it can determine what components or subsystems might need to be prototyped in advance before making an implementation, technology, or vendor decision. Models encourage experimentation and enable the evaluation of different ways of solving a problem without incurring the expenses of building an actual system.

Models also help focus the level of concern and detail. They can give you the 50,000-foot view or a detailed view of a system, subsystem, component, or process. Used properly, a model is a formidable weapon in coping with the inherent complexity of software-intensive systems.

Software modeling refers to the practice of visually creating and documenting the results of the analysis and design processes using suitable object models.

Model-driven development has proven effective in reducing time-to-market, decreasing development costs, and managing the risk of software projects.


The goal of OOAD is to simplify the understanding of a problem and its solution. Overly complex models go against this very principle. Therefore, it’s important to keep your models as simple as possible. Whenever possible we try to follow George A. Miller’s heuristic for the human capacity to assimilate, retain, and process information.3 Models with around seven elements (give or take two) convey enough information without overwhelming your senses.
{mospagebreak title=The Unified Modeling Language}

The UML is a general-purpose visual modeling language used in the analysis, design, and maintenance of software-intensive systems. It’s a refinement of several modeling notations used by the most prevalent object methodologies. The core concepts are derived primarily from Grady Booch’s OOAD, James Rumbaugh’s object modeling technique (OMT), and Ivar Jacobson’s object-oriented software engineering (OOSE). In the late 1990s the Object Management Group (OMG) embraced and promoted the UML as a standard modeling language for object-oriented systems. The OMG is a nonprofit consortium of nearly 800 members that includes major industry players, developers, and users of object technologies worldwide.

The UML plays an extremely important role in OOAD; it standardizes the visual vocabulary of software architects, designers, and developers by providing software-modeling artifacts born out of best practices and notations that have successfully been used to model complex business problems throughout the years. The OMG defines the UML as follows: “[A] graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.”4

The UML represents the de facto standard and lingua franca for visually documenting the processes of OOAD in a methodology- and process-independent.

It’s relatively easy to learn, semantically rich, and it addresses several contemporary development issues such as scalability, distribution, and concurrency.

It also represents a natural evolution of the software-engineering industry toward standardization. If you make an analogy to the construction industry, it’s easy to see the benefit and need for the UML. In the construction industry, an architect designs a building. The result of the design process is a set of blueprints that the builders use to construct the building. Different blueprints are tailored to different tasks. For example, structure builders need to know about load-bearing walls, plumbers need to know about waterlines, and electricians are concerned with the electrical layouts. In construction, models specify the level of detail and areas of concern for specific construction tasks. The more complex the building, the more crucial it is for the information embodied in the blueprints to be easily understood by the builders.

The UML is the unifying force behind making blueprints in the software trade as commonplace as they are in the construction trade. The rewards of the UML are many, including standardization, globalization, and the emergence of a modeling-tool marketplace that has increased the acceptance of modeling as a standard practice of software engineering.

The semantics of the UML align well with the semantics of object-oriented languages; after all, it was the object-oriented paradigm that triggered the events that eventually led to the creation of the UML. The UML doesn’t present a very steep learning curve for Java developers accustomed to “thinking in objects.” For a comprehensive introduction to the UML in the context of a methodology (such as Unified Process), we recommend Craig Larman’s Applying UML and Patterns.5

As implementations rapidly develop in complexity, the design decisions and lessons learned are quickly lost in the noise of the construction details. The UML fosters an industrywide memory by providing a vehicle in which designs (both good and bad) in the form or patterns and antipatterns, can outlive implementations and provide value in the present as well as the future. The debates about notation don’t exist nowadays. Thanks to the wide adoption of the UML, the debate centers on methodologies and processes.

Java and the UML

The Java community has benefited enormously from the revolution in modeling that the UML has created. Among the many benefits that the UML has brought are the following:

  • Java’s open, accessible core enables developers to take advantage of the now extensive UML tool market support for reverse engineering as a technique for understanding the APIs.


  • In general terms, the UML has elevated the communication level between stakeholders, business analysts, architects, and developers.


  • Industrial-strength automation via source-code generation from predefined UML design templates is commonly achieved with many UML tools.


  • Templates for well-known design patterns are available along with facilities that turn generic models into J2EE components.


  • The lost art of documentation has been given a new breath of life; most tools support the creation of comprehensive documentation suites from models and source code. Most Java tools support the creation of JavaDoc documentation enhanced with UML.


UML Diagrams Used in This Book

In its current incarnation (version 2.0), the UML has a set of 13 diagrams that can be classified in three categories: behavior, interaction, and structure. The original 9 diagrams (pre-UML 2.0) are the class, component, deployment, object, package, sequence, state machine, and use case diagrams. The new additions to the specification include the communication, composite structure, interaction overview, and timing diagrams.

There are also three-model management diagrams tailored to the modeling of different aspects or views of a system at different levels of detail. Stand-alone UML diagrams in isolation lack cohesion without a higher level of organization. They become disconnected pieces of a puzzle. The UML model management constructs bring a set of diagrams together in a coherent way, thereby imparting a higher level of understanding by grouping and further classifying individual diagrams in a model. The model management elements include packages, model, and subsystems and will be used throughout this book when needed in conjunction with some of the core UML diagrams. Table 2-1 shows a list of the different diagrams used throughout the book for the design and development of the TCMS system and a short description of their intended usage.

Table 2-1. UML Diagrams Used in the Analysis and Design of the TCMS System

Diagram TypeUsed for Modeling
Use caseRequirements/Relationships of actors and use cases
 High-Level Behaviorwithin a system
ClassStatic StructureClass structure and relationships
  among classes
SequenceInteractionMessage exchanges (time perspective)
ComponentImplementationOrganization and dependencies of


These four diagrams provide a comprehensive coverage of a system’s structure and behavior from multiple perspectives. The core concepts of the UML enable these perspectives to be used together to build a self-consistent system. These diagrams represent the primary artifacts used in the analysis and design of the system. Knowing which diagrams to use and when to use them is one of lessons that you’ll eventually learn. The basic approach is to find a combination of diagrams that both reflect the static structure of the domain you’re trying to model as well as the interaction and behavior of the system entities. Throughout this chapter and the rest of the book you’ll learn the diagrams shown in Table 2-1 in greater detail in the context of the TCMS case study.


UML Stereotypes

An important quality of the UML is its extensibility, which gives the UML the ability to grow in a controlled fashion to meet future demands while remaining true to the object-oriented paradigm. At the core of the UML, you’ll find the meta-model that defines the basic abstractions from which all modeling elements are defined. The UML extensions exist to enable the enhancement of the UML expressiveness without affecting or changing its core, that is, the metamodel.

Of these extension mechanisms UML stereotypes are by far the most powerful and popular extension mechanism to date. They characterize UML components that are imparting specialized semantics. In other words, UML stereotypes are used to further qualify an element of a UML diagram. The simplest way to explain a stereotype is as a label or tag that can be attached to a model element in order to enhance its meaning in the context of a given diagram. Stereotypes can be used with most elements of an UML diagram, including classes, components, operations, and associations.

Many methodologies use stereotypes to add extra levels of expressiveness to UML diagrams. UML stereotypes allow the semantics of the UML to be extended in a way that models become more expressive. Stereotypes “brand” other model elements by imparting a set of values, constraints, and optionally, a different representation. Stereotypes have many possible representations, with the most commonly used being a string enclosed in guillemets (that is, << >>). You make extensive use of stereotypes when modeling components in the J2EE environment and in general by adopting Peter Coad’s modeling-in-color technique and the domain-neutral component (DNC), which are techniques used to produce better object models and enterprise components.



{mospagebreak title=Model-Driven Architecture and the UML}

Where is the UML headed? How will it affect enterprise Java development in the future? These are questions that many developers think about. Field experience tells you that the UML currently has an impact on the initial stages of analysis and design of a J2EE system, but its usage sharply dies off after this stage. The OMG is strongly promoting the concept of a Model-Driven Architecture (MDA) in which applications (with the help of the UML) are defined in a completely technology-independent fashion and are then realized in an given platform such as CORBA, .Net, or J2EE.

The MDA is the next step in the evolution of the software-engineering practice and places the model as the centerpiece of your trade. In essence the MDA concerns itself with specifying a system independently of a platform, specifying platforms, and then transforming a system’s specification into an implementation given a chosen platform. Its primary goals are portability, interoperability, and reusability.

Open Source MDA tools are beginning to emerge, such as AndroMDA, which generates Enterprise JavaBeans (EJB) components from a properly annotated (using stereotypes) component model file in eXtensible Metadata Interchange (XMI) format.


Future of the UML and Java

As with any committee-driven initiative, it’s expected that the OO languages that the UML is meant to support will evolve at a faster pace than the UML. Emerging component architectures like EJB and new service-oriented paradigms like web services are currently partially supported via some of the extension mechanisms previously mentioned in this chapter. Using a UML profile such as the one proposed by JSR 26 (UML/EJB Mapping Specification) will standardize the extensions used and enable tool interoperability.


JSR 26, the UML profile for EJB, defines extensions that will enable tool vendors to standardize on a set of UML extensions used to annotate models in a way that they can be used to generate EJB components. Also the extension will enable the reverse engineering of a system composed of EJBs into a UML model. The EJB-JAR format is targeted as a possible carrier for a “UML Descriptor for EJB,” which is an XML file that “identifies UML models stored in the same EJB-JAR and their relationship to EJBs in the EJB-JAR”.6 Enterprise tools could then use these store descriptors for automation and reflection.

But you could argue that if UML profiles proliferate at too high a rate, the UML will become a fragmented beast representative of the problems it was created to solve in the first place. A delicate balance must be achieved by the OMG between adding new concepts to the core of the UML and the liberal use of the extension mechanisms.

Like any general-purpose technology in the rapidly changing landscape of today’s technology, the UML is still a work in progress and it will probably remain that way for the foreseeable future.

Expect Java development to further benefit and extend from the new enhancements to the UML. Problems such as the impedance mismatch between objects and relational databases are being addressed at a conceptual level within the UML. Tool interoperability is slowly becoming a reality with XMI, which goes to show how XML is slowly finding a place within the UML. The ability of business rules to be expressed in the context of an object model is gaining ground with the usage of the Object Constraint Language (OCL).

The notion of executable UML models is rapidly gaining followers in the world of embedded and real-time systems. Executable UML models are an attempt to once again raise the level of abstraction at which humans deal with problems and their solutions. Several efforts are underway to make executable UML a reality, and it’s expected that yet another breed of tools will emerge and that the lessons learned will trickle down into the UML specifications. The OMG and their MDA envisions the complete specification of systems using models. These models are built on a Platform-Independent Model (PIM) that models a solution without any ties to a specific implementation technology. In the fall of 2001, the OMG extended the semantics of the UML with a very complete set of semantics for actions defined at a very high level of abstraction. UML models will rely on these actions to accurately translate models into executable systems. Executable UML is more that just mere forward engineering; it’s a move upwards to a higher level of abstraction that makes code a rarely seen low-level entity as obscure as CPU registers are to a Java developer.

Code Generation and Round-Trip Engineering

Many of the OOAD CASE tools available nowadays feature both code generation and forward and reverse (round-trip) engineering of models to code and vice versa. Knowing when to use those features is a judgment call that must be based mostly on the capabilities of a given tool.

In the Java world, round-trip engineering is gaining new ground as tool vendors experiment with the concepts of MDA, Metadata (see Java Metadata Interface (JMI) specification, JSR 40) and the previously mentioned UML profile for EJB. Tools like AndroMDA are paving the way for the creation of J2EE components from a UML model.

In iterative development, reverse engineering can help in the discovery of potential areas of code reuse, in the application of design patterns, and with possible structural problems such as high coupling and low cohesion. Possible encapsulation and the discovery of component interfaces are activities that can also benefit from a process of reverse engineering. Also, in the case for which there is an existing code base—which is a typical case in the industry because unfortunately most projects seem to go through more than one attempt—reverse engineering can help you determine what code can be reused and what needs to be thrown away. In the absence of documentation, some of the lessons learned in any previous attempts might be revealed for the benefit of the current effort.

In combination with forward engineering, CASE tools can help a system remain true to its architectural vision by providing near-instant feedback on the results of an iteration, and allowing for corrective and preventive measures to be taken.

That said, it’s important to point out that code generation and round-trip engineering are in their infancy and you must take care not to get caught in a cycle of manually correcting poor, skeletal code.

Methodologies, Processes, and the UML

Most modern methodologies have adopted the UML as the foundation for their notations. That said, it’s important to note that the UML doesn’t impose a specific methodology or process, yet it enables a model-driven, architecture-centric, iterative and incremental process especially suited to work with distributed, object-oriented, component-based systems. The UML is therefore an enabling force that encourages the application of methodologies in the form of processes.

There are a variety of methodologies and processes, and an equally large set of reasons why one might be a better fit for a particular development effort. Factors such as the personality makeup of a development team, the size and scope of a system, and the target architecture all weigh heavily in deciding what methodology to follow. Experience shows that no methodology is a perfect fit for every organization and for every system. But most experts in the industry seem to agree that any semblance of a process is better than no process at all. Of course, devotion to process for the sake of process leads to what Steve McConnell refers to as “cargo cult organizations”7 in which there is the perception that the production of process-related documentation guarantees a project’s success. But the reality is that the combination of a committed team and the right amount of process are key to a project’s success.

Most successful contemporary methodologies share one common trait: None are linear. Iterations, with discovery, assessment, and enhancement cycles, are the norm. Waterfall or “big-bang” development has proven ineffective and inflexible when dealing with the dynamic nature of contemporary applications. Incremental development with small, well-defined models and test-driven deliverables are winning the race and delivering on-time and on-budget quality software systems.

In the neverending debate over methodologies, contrasting lines have been drawn between the so-called heavyweight methodologies and their counterparts: the lightweight or agile methodologies. Describing and comparing both methodologies and process types is rather difficult. No proponent of a methodology refers to it as a heavyweight methodology; the term has been coined in a negative context to mean that a methodology focuses excessively on the actual process and documentation and not on the results. Agile methodologies have risen out of the frustrations caused by negative experiences in trying to follow rigid and predictive methodologies. By adapting rather than predicting, agile methodologies acknowledge that a map is hard to follow when the landscape is constantly changing. Agile methodologies focus on people first by accommodating the way programmers work and viewing coding not as a construction-only phase but also in large part as a design-refinement phase. This notion is a notable departure from the usual analogies to the construction trade, in which design is thought of as a creative process and construction is a repetitive, manual process. Agile methodologies view coding as an extension of the design as well as an equally creative process. Because creative processes are quite hard to predict, as agile proponents claim, it’s very hard to control such a process with a methodology that’s rigidly designed to control predictable processes.


It bears mentioning that proponents of methodologies considered heavyweight or formal are quick to show that their methodology can be implemented as a light or agile process. One common example is the Rational Unified Process (RUP) for which there are several references in the literature on how to implement an “RUP instance” in an agile fashion.

In this book you’ll draw ideas and best practices from several of the most prevalent methodologies. You’ll use ideas from the Unified Process (UP)8, Feature-Driven Development (FDD),9 and Extreme Programming (XP).10 As a guide for newcomers to the modeling world, the OMG suggests that you first select a methodology and then find a UML modeling tool that best supports it. Your approach will be simpler and much more cost effective, when possible, and for the sake of continuity you’ll use a tool that will enable you to evolve your models as your system development gets under way. Current tools aren’t as flexible as you’ll want them to be and aren’t conducive to collaborative work in the way that a simple whiteboard and a set of markers are. Therefore, if the tool is getting in the way of progress put it aside and go the low-tech way!

Methodology Lessons Learned

We’ve listed a brief set of best practices or general guiding principles from the methodologies previously outlined. These methodologies share many common traits that can be used by anyone to improve the quality of software.

A development model is needed to guide, document, and provide feedback to the customer, stakeholder, or client. In the race to deliver quality software on time and on budget, several methodologies have evolved to mitigate the often drastic trade-off between quality, time, and cost of construction. Most contemporary methodologies acknowledge the following:

  • Feedback to the customer in the form of working software, as opposed to reports or mockups, is of the utmost importance for a project to remain alive.


  • Any processes need to strive to minimize the overhead of applying the process. Programming is a creative endeavor and an overly constrained process is a quick way to kill creativity.



  • Models are only good if they guide the development of a system. A model is nearly useless in practice if the resulting code base isn’t a reflection of the models.


  • No methodology is a one-size-fits-all solution. Some work better with different team personalities, different project domains, and different levels of project complexity and different team sizes. If a model-driven methodology is selected hastily, it’s never too late to switch into a more appropriate methodology. The UML can make this transition smoother by enabling models to be universally usable by any methodology or process.


  • If at all possible, reinforce a methodology by selecting a CASE tool that enforces the values and practices of said methodology. But if no available CASE tool fits your team’s work methodology you can always rely on low-tech approaches to successfully mitigate the task of modeling.


We encourage teams to borrow practices from different methodologies. After all, only the application of a practice can help you discern those based purely on theory from those based solely on practice. For example, we usually borrow ideas from Jeff Sutherland’s SCRUM project’s management methodology, which includes daily SCRUM meetings in which we ask ourselves what has been accomplished since our last meeting, what roadblocks we’ve encountered, and what we plan on doing between now and the next meeting. Other practices we subscribe to include the minimization of static modeling and active on-the-job knowledge transfer.


SCRUM is a lightweight, agile way to manage a project that shares many of its ideals with XP. Like XP, it’s centered on the concept of an iteration as a period of planning and execution that results in a perceivable and measurable value. In SCRUM, a daily iteration is called a “scrum” though the external iteration is termed a “sprint,” which is a manageable “scrum” collection that makes up a milestone (usually not more than 30 days).
{mospagebreak title=Design Roadmap}

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


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 Open Source project, a mid-sized Open Source community focused on collaborative development tools ( ). ArgoUML is the most prominent and active project on the 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, see .


For more information on Java Web Start see
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-centricThe default view, it provides a hierarchical view of all
 packages, diagrams, and contained modeling elements.
Class-centricShows 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-centricA rootless view showing only diagrams as top-level
Inheritance-centricShows a hierarchy of modeling elements based on
 inheritance. This view is relevant mostly when dealing
 with a hierarchy of class elements.
Class AssociationsShows a hierarchy of classes and their associations
 (circular associations will be expanded ad infinitum!).
 It also shows all diagrams at the top level.
Navigable AssociationsSupposed to show associations among classes (not
 working as of version vPRE-0.14.a1).
State-centricThis view shows relationships between elements of a
 state diagram.
Transitions-centricShows 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 pathsThis view shows all transition paths between elements of
 a state diagram in a tree hierarchy. Circular paths can
 also be expanded ad infinitum.
Collaboration-centricA rootless tree showing all collaboration diagrams in the
 model and their elements.
Dependency-centricThis 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.


{mospagebreak title=The Editing Pane}

The Editing pane is the designer’s main work area, where UML diagrams are displayed and edited. A diagram-specific toolbar shows common operations and elements that can be added to the active diagram. You’ll learn about the operations and elements relevant to the creation of the models for the TCMS system throughout the rest of the chapter.

The Details Pane

The Details pane shows specific properties for the diagram or a selected model element. It’s presented as a tab pane with tabs for the following:

  • To-Do Items: Shows outstanding critic-generated and user-generated items for the selected model object. This pane allows the user to add new to-do items, resolve a to-do item (wizards guide you through the process), snooze the critic (temporarily ignore the item), or email a human expert for advice on how to resolve a critic-generated to-do item (partially implemented).


  • Properties: Displays the main, model-related properties of a model object such as name, stereotype, namespace, visibility, and association.


  • Documentation: Allows the designer to enterJavaDoc tags for items such as author, version, or whether an item is deprecated.


  • Style: Controls the appearance of the model object. Characteristics such as line and fill colors as well as size and shadow depth can be controlled from this pane.


  • Source: Displays the equivalent Java or UML definition of the selected item.


  • Constraints: Contains the UML Constraints Editor. UML constraints are invariants written (preferably) using the OCL.


  • Tagged Values: Contains the Tagged Values Editor. Tagged values are name-value pairs that can be associated with a model’s element. A property that has been tagged with a given name will be assigned the value associated with the tagged value. There are several predefined UML tags provided that can be used in a model.


  • Checklist: Will eventually provide a “user-level” to-do list. In the current release of ArgoUML this tab is currently grayed out.


The most important tab, and the one you’ll use the most is the Properties tab, which displays and enables you to edit any major features of the selected model element.

The To-Do Pane

The To-Do pane displays all to-do items (see the “Design Critics” section later in this chapter) in a tree-based view that can be dynamically sorted and grouped by priority, decision, goal, offender, poster, or knowledge type. To-do items can be of high, medium, or low priority. To-do items are categorized by design issue according to 16 predefined decision categories including Class Selection, Design Patterns, Code Generation, and others.

As you’ll learn later in this chapter, the To-Do pane also holds the output of the design critics. The grouping options By Decision, By Goal, By Offender, By Poster, and By Knowledge Type are intimately related to the work of the design critics.

The Menu Bar and Toolbar

The menu bar or main menu is organized around the following categories, and the toolbar offers shortcuts to commonly used menu items.

  • File: From here you can manage your ArgoUML projects and import source code to be reverse engineered into UML class diagrams. You’ll also find other utility functions like printing, saving a graphic of a given diagram, and others.


  • Edit: Provides the typical edit functions applied to the selected artifact(s) of the active diagram.


  • View: This menu provides navigation features like tab pane navigation, and enables you to switch to a given diagram. It also provides the more familiar view controls like zooming and diagram grid management. There is also an option to toggle notations between UML 1.3 and Java.


  • Create Diagram: From this menu you can create class, use case, state, activity, collaboration, deployment, and sequence diagrams.


  • Arrange: Provides functions for the alignment, distribution, z-order, and fine positional adjustments of diagram artifacts.


  • Generation: From this menu you can generate code for a class or all classes in a diagram.


  • Critique: From this menu you can control ArgoUML’s unique Design Critics feature as explained later in the chapter.


  • Tools: Currently unavailable, it will eventually provide a plug-in point for external tools.


  • Help: System information and the About screen. ArgoUML doesn’t ship with a program-accessible documentation set or a context-driven help system.


Initial State

Once started, ArgoUML will create a brand new project or open the last saved project automatically, as long as you configure it to do so by choosing Edit -> Settings and selecting Reload Last Saved Project on Startup.

Cognitive Features in ArgoUML

ArgoUML provides some powerful features not found in any other UML CASE tools. Many of these features stem from the field of cognitive psychology and attempt to make the software adapt to the working habits of the designer and in many areas it assists by making predictions on what the designer might do next.

The cognitive features of ArgoUML can be categorized as follows:

  • Reflection in action: Acknowledges that complex systems evolve and designers heavily reflect on their designs. To support reflection in action ArgoUML contains features like Design Critics, Corrective Automations, To-Do Lists, Checklists, and the partially implemented User Model.
  • Opportunistic design: Is based on the concept that designers follow a path of the least “cognitive cost”13 rather than a structured, hierarchical path. To support opportunistic design ArgoUML features To-Do Lists and Checklists and in the near future, a feature called Work Breakdown Structure. These tools help designers’ natural tendency to evolve their designs via a path of least resistance.


  • Comprehension and problem solving: ArgoUML includes multiple views or perspectives of the working model in order to help designers rapidly gain an understanding of a model and help them discern new connections between model elements. Features of ArgoUML supporting this theory include the navigational perspectives as shown in the Navigator and To-Do panes as well as many wizards.


Design Critics

Design Critics are an automated user interface feature that provides assistance to a designer. Design Critics are a process that works in the background as the design process is being carried out by the designer. Using a series of heuristics, Design Critics provide feedback on the decision-making process. You can think of them as a set of rules that are applied by a rule engine to the state of a model, which produces a set of actions in a form that the user can choose to ignore. It’s a very unobtrusive feature. Feedback from the Design Critics is called critiques and appears as to-do items in the To-Do pane.

Design critics act as a guide and automated mentor. It’s expected that as the designer gains more experience the number of critiques will diminish. Design Critics can flag perceived anomalies in a model and automatically correct them at the user’s request. Critics can also integrate with other expert human designers via email. This feature is currently partially implemented and it will default to sending an email to the discussion list for users of ArgoUML.

Each critic monitors a specific design criterion and the result of its work is called a critique, which is a recommendation or statement about an aspect of a model that doesn’t appear to follow good design practices.

ArgoUML Design Critics are configured via the Critique menu item. By default the option is turned on, but you can turn it off by selecting Critique -> Toggle Auto-Critique. The Critique menu also contains the following options that you’ll need to configure:

  • Design issues: Design issues have different categories and priorities assigned to them. In this particular window a list of the decision types with priorities ranging from zero to five (zero being off and five being the highest priority) is shown. The setting here is applied globally to all critics. Setting all decision priorities to zero will effectively deactivate the critics. The decision types available include Class Selection, Naming, Storage, Planned Extensions, State Machines, Design Patterns, Relationships, Instantiation, Modularity, Expected Usage, Methods, Code Generation, Stereotypes, Inheritance, and Containment.


  • Design goals: Higher-level guidance for the application of critiques. The same priority system used for the design issues applies to the goals of a critic. The setting on this window applies globally to all design goals. Currently there is only one design goal category: Unspecified. Setting the priority of this category to zero will effectively deactivate all critics.


ArgoUML also provides an option for browsing the existing critics by selecting Critique -> Browse Critics. In this window you can modify certain properties of a critic such as headline (name), priority, and long description. You can also turn a critic on or off (“snoozing” a critic in ArgoUML terms).

Critics also manifest themselves graphically on certain modeling elements. For example, in the case of a class element, a yellow note symbol will appear in the upper-left corner of the class when there are critiques associated with the class.

For example, on a newly added class, a critique telling you to name the class will appear.. To view the critique you can right-click the class and select Critiques -> Choose a Name. This will select the critique in the To-Do pane.

There are 85 built-in critics in ArgoUML. Some of them watch over the naming of model elements as well as the aesthetic aspects of the model—for example, in preventing overlapping graphical elements. Other critics watch for places in a model where a pattern like the singleton can be applied or decide whether two or more classes should be combined. Still other critics check more fundamental flaws and the correctness features of a model, such as, for example, circular composition, illegal generalization, nonpublic interface operations, and interfaces with attributes.

{mospagebreak title=Drawing Diagrams in ArgoUML}

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
SponsorA sponsor is an individual or company that is
 “sponsoring” a conference.
Conference administratorAn administrator is an individual that has privileged
 access to conference-related functions.
PresenterA presenter is an individual that presents one or more
AttendeeAn attendee is a registered user who is attending a
OrganizationA nonindividual legal entity.
ConferenceAn event that consists of one or more sessions.
Conference TrackA high-level classification of the topics covered in
 a conference.
PresentationA collection of materials and information to be conveyed
 to an audience in a predetermined amount of time.
SessionAn event that embodies the act of “presenting” a
ScheduleA 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 University14 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.


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.

{mospagebreak title=Object Modeling Using Archetypes and Color in UML}

An insightful and useful technique that hasn’t received the level of recognition it deserves is the use of color, as proposed by Peter Coad in his book Java Modeling in Color with UML: Enterprise Components and Process (Prentice Hall PTR). The color in UML technique hinges on the notion of an archetype, which is a concept similar to the concept of a stereotype in UML with the difference being in the rigidity of the definition and its effect on the target class. An archetype is a way to tag a class as something that more or less adheres to a certain set of characteristics. (This is a looser definition than inheritance for example.) Coad started using 3M Post-it Notes, which come in four colors, pink, yellow, blue, and green, to label model elements. Coad assigns a color to each one of the archetypes or class categories. The addition of color gives you a sense of spatial layering that enables designers to quickly capture both structure and behavior and helps you to see dynamism in an otherwise static class diagram. Coad defined the following four main archetypes and associated them with four colors:

  • Moment-Interval (pink): The moment-interval archetype represents an activity that can be tracked in time, something that occurs at a moment in time or over an interval of time. Registering for the conference, submitting payment, and browsing sessions are all examples of Moment-Intervals.


  • Role (yellow): The role archetype represents the way something participates in a moment-interval, for example, a person can participate in a conference while playing the role of attendee.


  • Description (blue): The catalog-entry description archetype represents a value or set of values that can be used to label a set of things. The easiest way to think of the description archetype is to think of information that classifies an entity but that doesn’t define its identity. For example, nationality and immigration status can be considered descriptions for a person while a passport number or green card number will be a part of that person’s identity information.


  • Party, place, or thing (green): The party, place, or thing archetype, PPT for short, represents the things that can play a role in the different activities of the system.


The four basic archetypes are interconnected in a way that repeats over and over in models. This pattern in its simplest form entails a PPT playing a role in a moment-interval, which might affect other PPTs. PPT also might have descriptions associated with them. In this pattern physical entities such as PPT never interact directly but instead are participants (as role players) in an activity.

For example, in the conference attendee example a person (party) is an attendee (role) in the context of a conference (moment-interval). The temporal relationship between the conference and the person is fulfilled by the attended role. This basic pattern is depicted in Figure 2-7.


In this book the colors for the Coad Archetypes are represented as shades of gray. Visually the power of the technique hinges on the use of color. To see the images in color visit http://www.ejdoab. com.

Figure 2-7. Basic relationships between the Coad archetypes

As you’ll see later in more detail the main formula is to find an activity (moment-interval), find the participants in that activity (roles), and find who or what is playing that role (party, place, or things). You begin by making a list of possible m-i classes that are central to the system in question. Eventually you’ll arrive at a model for which all classes belong to one of the four archetypes. Table 2-4 shows your initial list of m-i candidates. As you can see you started at the highest level and moved toward moments-intervals of finer and finer detail. For example, at the highest level you have the conference as the top m-i class. Conference is an m-i class because it’s something that happens over a period of time and can be tracked for legal and business reasons. You can also see that your four main stakeholders are roles played by either a person or an organization of some kind.


In their book Java Modeling in Color with UML: Enterprise Components and Process, Coad et al use an archetype called a moment-interval detail, which is also colored pink and labeled with the stereotype mi-detail. Moment-interval details are classes that hold information about a moment-interval class. They are usually associated with a moment-interval via aggregation. In this book we don’t use m-i details for the sake of simplicity.

Table 2-4. TCMS Candidate Moment-Interval Classes

Moment-Interval Participants (Roles)Role Player
ConferenceSponsors, Administrator,Person/Organization
 Presenter, Attendee 
Conference RegistrationAttendee, PresenterPerson
Conference TrackAttendee, PresenterPerson
ScheduleAttendee, PresenterPerson
SessionAttendee, PresenterPerson
Session EvaluationAttendeePerson
Call for PapersPresenterPerson

The Domain-Neutral Component

The Domain-Neutral Component The Domain-Neutral Component The Domain-Neutral Component The Domain-Neutral Component The Domain-Neutral Component The Domain-Neutral Component

A more encompassing set of interconnections between the four basic archetypes is the domain-neutral component (DNC), which is a template built upon the four archetypes based on roles being played by the three different entitylike elements (PPTs): party, place, and thing. This results in a template model with three legs or branches: the party branch, the place branch, and the thing branch. The DNC, as originally introduced by Coad, is shown in Figure 2-8.

Figure 2-8. The domain-neutral component

The result is a flexible, semantic-based class diagram template that you can use to build any kind of model. The best part is that it’s remarkably simple to use. You don’t have to fit your model into the DNC, rather, the DNC will guide you to make your model more complete. The trick about using the DNC is an understanding that archetypes are very flexible definitions, and that elements of the DNC template can be dropped out to simplify the model. Basically you start with a very complete model and progressively collapse or drop archetypes as you go along.

This takes a bit of effort in the beginning because programmers tend to model interactions or temporal relationships between elements as a method in one of the participating elements. The DNC and the four archetypes hinge on the notion of representing these relationships as elements themselves.

You might be asking yourself where we’re going with all this color stuff. The truth is that it takes a bit of time and a couple of models to begin to grasp the power of the technique. But once it sinks in it will help you produce better, more accurate, and complete models. To an extent it’s a completeness theorem of sorts, especially when it comes to modeling. That’s the main goal of the technique—to make you a better modeler.

{mospagebreak title=Adding Modeling Elements to the Class Diagram}

The next step is to graphically construct the model. Renowned object technologist Martin Fowler defines a domain model as “an object model of the domain that incorporates both behavior and data.”15

A domain model creates a web of interconnected objects, where each object represents some meaningful entity, whether it’s as large as a corporation or as small as a single entry in a user’s schedule. This seemingly static model is represented with a class diagram that shows the basic relationships between the candidate elements. A class diagram models structure and contents using design elements such as classes, packages, and objects. It also displays relationships such as containment, inheritance, associations, and others.

The slight difference in this approach from the traditional static domain entity model is that you’ll be adding relationships between entity classes in the form of moment-interval classes, and you’ll be identifying any other classes as belonging to one of the four Coad archetypes.

Let’s start with a small section of the domain, focusing on the session m-i candidate as shown in Table 2-3. Your basic strategy is to identify some m-i classes and plug other archetypes around them using the DNC as guide.

To add a new class to the diagram, follow these simple steps:

  • Select the diagram on the Navigator pane (entitled “Class Diagram”).


  • Click the class icon in the toolbar (yellow square with three compartments).


  • Click anywhere on the Editor pane.


The new unnamed class element should appear on the Editor pane at the location of the last mouse click as well as in the Explorer. Select the Properties tab on the Details pane and in the Name field enter person. Repeat these steps for the following classes: Presenter, Attendee, Session, SessionLocation, ContentToBePresented, Room, and Presentation. The class diagram should now resemble Figure 2-9.

Figure 2-9. Newly created classes

The next step is to associate the created classes with one of the four archetypes. To date the only tool that includes built-in support for the Color in UML techniques, the four basic archetypes, and the DNC is Borland’s Together line of products, formerly TogetherSoft’s TogetherJ. ArgoUML enables the creation of custom stereotypes and also enables a class color to be selected. Although at this point it isn’t possible to associate a specific stereotype with a class color or any other attribute. Therefore, for each class you need to manually assign a color. This is a small price to pay for the extra expressiveness that color brings into the process.

Creating a Custom Stereotype

Adding a new stereotype to ArgoUML is a little trickier than it needs to be (we expect the procedure to be simplified in future versions):

  • Select any class in the class diagram.


  • On the Details pane choose the Property tab and select any stereotype from the stereotype drop-down list.


  • Click the button next to the drop-down list. The button is unlabeled with a graphic of an arrow with a 90-degree bend. This should take you to the stereotype Property tab.


  • Click the New Stereotype button (the one adorned with guillemets).


  • Enter the name of the new stereotype, in this case enter party.


    Repeat the last two steps shown previously for the following stereotypes: place, thing, role, moment-interval, and description.


The ArgoUML manual cautions about a known bug. Apparently, in certain versions of ArgoUML the newly created stereotypes will not appear in the class property stereotype drop-down list until the entire model is saved and then reloaded.

{mospagebreak title=Assigning Archetypes and Creating Associations}

Now that the Coad archetypes have been added to the model, you can proceed to label your classes with the appropriate archetypes and create meaningful associations between the classes following the guidelines of the DNC.

To assign an archetype, simply select a class in the diagram and change its stereotype value to the appropriate archetype name on the Stereotype drop-down list. For the classes currently in your class diagram you should use the values shown in Table 2-5.

Design with ArgoUML
Table 2-5. Archetype Selection
Class ArchetypeExplanation
SessionMoment-IntervalA session is something you want to
 track for business purposes.
PersonPartyPeople are role players in the
 context of a session.
PresenterRoleA person presenting a session
 plays the role of a presenter.
AttendeeRoleA person attending a session plays
 the role of an attendee.
RoomPlaceA room is a place that plays a role
 in the context of a session.
Session LocationRoleIs the role played by a room in the
 context of a session.
ContentToBePresentedRoleIs the role played by the material
 and content in the context of
 a session.
PresentationThingThe material being presented.



Now that you’ve defined the archetypes that your classes fall into, you can add color to your classes by using the Style tab and selecting the appropriate color for each of the archetypes using the Fill drop-down list. Table 2-6 shows a quick summary of the archetypes, their color, and the position of the color in the Fill drop-down list in the version of ArgoUML that you’re using.

Table 2-6. Coad Archetypes and Their Corresponding Colors

Archetype Name ColorPosition in Drop-Down List



After choosing the Archetypes and corresponding colors you can make simple connections in your model following the basic archetypes relationship, which tells you that a PPT plays a role in the context of an m-i. This forms chains of PPT-role-m-i in your model. In the current case you have the following:

  • Person-Presenter-Session


  • Person-Attendee-Session


  • Room-SessionLocation-Session


  • Presentation-ContentToBePresented-Session


It’s now easy to see the pattern. In the case of the presenter role you can read the pattern as follows: “A person plays the role of a presenter in the context of a session.” Now proceed to associate the classes by clicking the Association icon in the toolbar, and then click one class and drag the cursor to the other class in the desired association. If you select an association you can change the name of the association as well as assign a stereotype to the association. All associations are one-to-one associations by default. To change the cardinality of either end of an association, right-click the association line closer to the end you want to affect, and select one of the options under the Multiplicity submenu. You can also change the nature of the association to be a composite or aggregate from the Aggregate submenu. Association directionality can also be changed from the same context menu by using the Navigability submenu.


Don’t worry too much about getting all multiplicity and cardinalities of the relationships in the domain model right the first time or even in there at all. This can lead to analysis paralysis.

The resulting class diagram should resemble Figure 2-10.

Figure 2-10. Archetypes, color, and the DNC applied to the partial model

At this point you can further simplify the model by correlating the model with the structural information and with the needs of the system in order to maintain certain information. For example, in the case of the Room- SessionLocation-Session and the Presentation-ContentToBe Presented-Session legs of the diagram, you can drop both the SessionLocation and the ContentToBePresented roles because you don’t need that level of detail or flexibility in the model. Therefore, you can directly connect the Green and the Pink elements in both legs of the diagram. The resulting simplified diagram is shown in Figure 2-11.

Figure 2-11. Simplified class diagram

After repeating this discovery and refinement process to the other moment-intervals identified, you’ll see the domain model shown in Figure 2-12. As you can see the strategy boils down to finding the pink, then yellow, then blue and green archetypes. Then for each leg of the model you should remove any classes where complexity outweighs the flexibility provided by the class. In the case of an analysis model, remove the class only if the meaning and understanding of the model is unaffected by the removal of the class. For a design model determine if the class can be collapsed onto one of the associated classes or if it can be removed altogether without affecting the functionality of the system or component.

Figure 2-12. The TCMS domain model class diagram

The beauty of the DNC, archetypes, and color technique is that they all greatly enhance the expressiveness of a model, imparting a level or dynamism to an otherwise static class diagram.

{mospagebreak title=Use Case Modeling}

The main goal of use case modeling is to understand user needs and to enable you to view a system from the customer’s point of view. Use cases describe how actors interact with the system in order to achieve some business purpose. They are procedural descriptions of the process of functional decomposition.

Even though use cases aren’t object-oriented in nature, this doesn’t mean that use cases have no value in OOAD, on the contrary, they are good vehicles for the understanding of user requirements and for the planning of deliverable milestones in a system.

That said, it’s important to use caution when modeling with use cases because they could lead to the definition of procedures without a proper understanding of the problem domain. This can lead to the creation of many “artificial” classes to support a specific use case that taints and distorts the essence of the domain being modeled. As long as you understand this you should have no problem with use cases.

In our experience use cases are of great value to the implementation of test cases and they promote a test-driven (test-first approach) process. In this sense the completion of a use case becomes a tangible deliverable that can provide instant feedback to the system’s stakeholders. With the current emphasis on service-driven architectures, use cases are a good vehicle to define the goals of services and are useful in the definition of service-oriented components (like session facades, as you’ll see in Chapter 5).

Use Cases and the Domain-Neutral Component

Applying the DNC makes for a great preamble to modeling use cases because it helps prevent one of the cardinal sins of use case modeling: uses cases dictating an object-model’s structure. When use cases drive a model’s shape the model effectively becomes a slave of the current functionality being addressed and no longer is a true representation of the business. This means that although a use case might give you a clear understanding of a single interaction between an actor(s) and the system, it doesn’t give you an understanding of the problem domain (as the domain model does), which can lead to “design tunnel vision.”

To an extent, you can equate the Moment-Interval classes with either a use case, part of a use case, or an encapsulation of one or more use cases. Use cases are typically documented as short but concise textual descriptions or scenarios— a concept similar to XP’s User Stories, which represents a “story” about how a system solves a particular problem.

Use Cases Overview

Use cases are primarily delivered as documents. There are many “templates” floating around in the industry that do a good job of explaining use cases, from flowing textual descriptions to enumerated bullet point step-by-step descriptions. These descriptions are usually structured around a normal flow of events, which are often referred to as a success scenario. These scenarios differ from the normal flow of events, which are documented as extensions or variations. For a sample template see Alistair Cockburn’s website (http:// www. ).

In use case modeling the concept of an actor plays a central role. An actor is a role that some entity plays while the system is being analyzed or designed. Typically, actors are classified as primary and secondary actors. Primary actors are those that are deriving business value from an interaction with the system, while secondary actors are those that the system interacts with in order to fulfill the needs of a primary actor. In the case of the TCMS system, your defined stakeholders map directly to primary actors in your use cases.

At a higher level, a use case diagram can show the associations among use cases and the primary and secondary actors involved. In the case of the TCMS system you started with a high-level use case diagram to get a birds-eye view of the functionality that the system must satisfy. Like class diagrams, use case diagrams provide display associations between the use cases in the system. A use case diagram helps you organize the functionality of a system. A use case diagram is the primary artifact used in defining the services and the components that fulfill them.

Use case diagrams consist of actors (usually represented by a stick figure), use cases (represented as an ellipse), and optionally, a rectangle enclosing the use cases, which denotes a system boundary or simply groups the use case model. There are three relations between use cases: extend, include, and generalization.

  • Extend: Represents an extension on behavior and not in structure. It signifies that the extending use case contains added behavior, not alternatives or exceptions. The new use case doesn’t alter the behavior produced by the base use case. Extension points are used to determine when the extended case applies inside the base case.
  • Include: Represents containment of behavior. Think of it as a use case that “invokes” the behavior of another use case at a specific point in a use case.


  • Generalization: Implies an “is like” relationship between use cases. Generalization is used whenever a use case is conceptually similar to another use case.


Creating a Use Case Diagram in ArgoUML

To create a use case diagram in ArgoUML you follow steps similar to those used to create a class diagram:

  1. Select the use case diagram. In the Explorer, under the tcms model, expand the domain package under the model and select Usecase Diagram. The toolbar should now change to the use case diagram controls.


  2. Add actors. Using the toolbar controls, you can add different elements to the diagram including actors. Add four actors: attendee, presenter, administrator, and sponsor. This is similar to working with classes. If you select an actor on the diagram its properties (such as the name) can be changed in the Details pane on the Property tab.


  3. Add use cases. Using the toolbar controls, you select the use case (white ellipse) and click anywhere on the diagram. Next, rename the use case to Browse Schedule. Repeat this step for a use case named Add Schedule Reminder.


  4. Add associations. Using the Association drop-down list on the toolbar, select the directed association (on first row, right-most element in the drop-down list, which is an arrow pointing to the right). Connect the attendee actor to the Browse Schedule use case. Next, using the extend association in the toolbar (the upward-pointing segmented arrow with an “E” on the left) connect the Add Schedule Reminder use case to the Browse Schedule use case.


The use case diagram should now resemble Figure 2-13.

Figure 2-13. Partial use case diagram

If you feel adventurous you can complete the use case diagram using the list of use cases shown in Table 2-7. A use case diagram consisting of the collection of all actors and all use cases. It’s referred to as the use case model.

Table 2-7. TCMS Preliminary List of Use Cases

Use Case ID NameActorsExtendsIncludes
UC-1Browse ScheduleAttendee, PresenterN/AN/A
UC-2Add Schedule ReminderAttendee, PresenterUC-1N/A
UC-3Remove Schedule EntryAttendee, PresenterUC-1N/A
UC-4Mail ScheduleAttendee, PresenterUC-1N/A
UC-5Browse SessionsAttendee, PresenterN/AN/A
UC-6Add Session To ScheduleAttendee, PresenterUC-5N/A
UC-7Browse Presenter SessionPresenterN/AN/A

Chapter 2 Table 2-7. TCMS Preliminary List of Use Cases (Continued)

Use Case ID NameActorsExtendsIncludes
UC-8Log InAttendee, PresenterN/AN/A
UC-9RegisterAttendee, PresenterN/AN/A
UC-10View ProfileAttendee, PresenterN/AN/A
UC-11Edit ProfileAttendee, PresenterUC-10N/A
UC-12Submit AbstractPresenterN/AN/A
UC-13Browse Abstracts PresenterN/A
UC-14Edit AbstractPresenterUC-13N/A
UC-15Evaluate AbstractAdministratorN/AUC-15
UC-16View NewsAnyoneN/AN/A
UC-17Edit NewsAdministratorUC-16N/A
UC-18Process RegistrationAdministratorN/AN/A
 at Venue   
UC-19View StatisticsAdministratorN/AN/A
UC-20Process Booth RequestAdministratorN/AN/A
UC-21Browse BoothsSponsorN/AN/A
UC-22Request BoothSponsorUC-21N/A

The resulting use case diagram—the TCMS use case model—is shown in Figure 2-14.

Figure 2-14. The TCMS use case diagram



{mospagebreak title=Refining Use Cases with Sequence Diagrams}


The UML sequence diagram models the dynamic behavior of a system by depicting object interactions over time. These interactions are expressed as a series of messages between objects. UML sequence diagrams are ideal for elaborating a use case execution in terms of objects from your domain model. One sequence diagram is typically used to represent a single use case scenario or flow of events. The message flow of a sequence diagram matches the narrative of the corresponding use case.

Sequence diagrams are an excellent way to document use case scenarios and refine and synchronize a use case diagram with respect to a domain model. A sequence diagram typically shows a user or actor and the object and components they interact with in the context of a use case execution.


Sequence diagrams aren’t working in ArgoUML as of the release of version v0.14. As an alternative, we suggest using the community edition of Poseidon UML, which is a commercial offering based on ArgoUML. We expect sequence diagrams to be available in the near future (hopefully by the time you read this!).

Whenever necessary use-sequence diagrams are used in the book to refine and validate a use case against the application’s domain model.


Don’t assign operations to a class without first refining complex use cases with sequence or interaction diagrams. By refining what capabilities a given class should have, you avoid the eventual generation of unneeded code. This practice aligns well with test-driven development and XP’s You-Ain’t-Gonna-Need-It (YAGNI).
Best Practices

Model-driven development is a practice that takes time to master, but the results are well worth the effort. We’ve compiled a list of best practices taken from the literature and from our own experiences to help you get started.

  • Keep models simple: Don’t over-model.
  • Use color in your models. As seen in this chapter color greatly enhances your ability to quickly grasp the both the static and dynamic elements of a model.


  • Choose model element names carefully. A model name can greatly influence the person that has to turn it into code.


  • Avoid design or implementation-specific constructs in the analysis model.


  • Keep models and source code synchronized: incremental changes are easier to incorporate.


  • In modeling, no single view is sufficient. Approach a complex system with a small set of independent views.


  • The best models are connected to reality and reality is all about trade-offs. Flexibility and performance are sometimes at odds when modeling a system.


  • There will be a point in a model’s life when the level of detail can only be expressed directly in code. Make sure that you don’t waste valuable time trying to overmodel something graphically that can be explained with a code sample or an annotation. UML notes are a great way to address some of these issues at the model level.



As you prepare for a journey into the J2EE world it’s important to remember that sound design practices—not technology—should drive the development of enterprise applications. Although at specific points you might have to make an implementation decision that’s driven by the shortcomings of a particular technology, you should always keep in mind the greater picture of a solid design based on the problem space rather than the solution space.

In this era of agile methodologies and techniques, many are quick to dismiss software modeling. But as Scott Ambler ( http://www. ) and others have demonstrated, software modeling can be just another weapon in your arsenal of agile methods.

In this chapter you’ve learned a solid set of techniques and with the help of Open Source modeling tools you can make your models more robust and resilient to requirements and technology changes.



1. Craig Larman, Applying UML and Patterns (Prentice Hall PTR, 2001).

2. Edward R. Tufte, The Visual Display of Quantitative Information
(Cheshire, CT:Graphics Press, 1983).

3. G.A. Miller, “The magical number seven, plus or minus two: Some
limits on our capacity for
processing information” (The
Psychological Review,
vol. 63, 1956) pp. 81–97.

4. Object Management Group, “OMG Unified Modeling Language
Specification,” Version 1.5
(March 2003), p. 1–1.

5. Craig Larman, Applying UML and Patterns (Prentice Hall PTR, 2001).

6. Jack Greenfield (Rational Software Corporation), “UML Profile For
EJB” [JSR-000026
UML/EJB(TM) Mapping Specification 1.0 Public
Review Draft] (2001), p. 8.

7. Steve McConnell, “From the Editor,” (IEEE Software, March/April
2000). Available online at

8. Jacobson et al, The Unified Software Development Process
(Addison-Wesley, 1999).

9. Coad et al, Java Modeling In Color With UML: Enterprise
Components and Process
(Prentice Hall PTR, 1999).

10. Kent Beck, Extreme Programming Explained (Addison-Wesley,






11. Scott Ambler et al, Agile Modeling (John Wiley & Sons, 2002). For
more information on agile
modeling also visit

12. Ambler et al, Agile Modeling.

13. ArgoUML online user manual, Chapter 8.

14. R. Chandra, A. Gupta, and J. L. Hennessy, “Integrating
Concurrency and Data Abstraction in
the Cool Parallel
Programming Language” (
IEEE Computer, February 1994).

15. Martin Fowler, Patterns of Enterprise Application
(Addison-Wesley, 2002).

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye