Home arrow Practices arrow Design with ArgoUML

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)

  1. Design with ArgoUML
  2. The Unified Modeling Language
  3. Model-Driven Architecture and the UML
  4. Design Roadmap
  5. The Editing Pane
  6. Drawing Diagrams in ArgoUML
  7. Object Modeling Using Archetypes and Color in UML
  8. Adding Modeling Elements to the Class Diagram
  9. Assigning Archetypes and Creating Associations
  10. Use Case Modeling
  11. Refining Use Cases with Sequence Diagrams
By: Apress Publishing
Rating: starstarstarstarstar / 35
August 25, 2005

print this article



"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.

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

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: