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)
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
Used for Modeling
Relationships of actors and use cases
within a system
Class structure and relationships
Message exchanges (time perspective)
Organization 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.
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.