Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

The Unified Modeling Language

The Object Management Group (OMG) adopted UML (version 1.0) in November 1997 (the most current release, version 1.4, was adopted in February 2001). This was a remarkable, unprecedented event because it marked the acceptance of a standard modeling language based on the best current practices for the analysis, design, and development of object-oriented software.

UML sprang from the combined efforts of the "three amigos": Grady Booch with his Booch method, James Rumbaugh with his Object Modeling Technique (OMT), and Ivar Jacobson with his Object-Oriented Software Engineering (OOSE) method. As mentioned earlier, some of the terminology and philosophy found in the Synergy Process is based on Jacobson's Objectory Process (later to be called Rational's Unified Process).

Beginning in 1994, under the auspices of Rational Software, UML began to take shape. Although UML clearly reflects the three amigos' combined approaches, it also includes the best practices of many others. Other contributions include insights from such organizations as Hewlett-Packard, IBM, and Microsoft, as well as other industry practitioners, such as Shlaer/Mellor, Coad/Yourdon, and Martin/Odell. UML was also submitted as a formal response to the OMG's Request for Proposal (RFP) for a standard object-oriented modeling notation.

The ramifications of the OMG's adoption of UML cannot be overestimated. Those of us who grew up in the Structured Analysis and Structured Design (SA/SD) world had numerous diagramming notations from which to choose and several software process models to apply. Wouldn't it have been wonderful if the likes of Ed Yourdon, James Martin, and Tom DeMarco, to name a few, had sat down one day in the late 1970s and agreed to put aside any and all egos and adopt one notation for the SA/SD approach to software development? Had there been only one way to express the application domain, many organizations would have benefited significantly. Not only would all of the organization's models have been similar, but also an individual moving from company to company or from application domain to application domain would have had a common notation as a baseline.

UML, then, is the first notation that has garnered consensus among most practitioners, software vendors, and academics as the de facto standard for expressing a business domain of the accompanying software solution.

The Place of UML in a Software Process

UML is not a software process model or a systems development methodology; it is a notation, a mechanism to "pen the problem" in such a way as to uncover the essence of an application domain. The combination of UML with a sound process model (Rational's Unified Process, Ernst and Young's Fusion, or the Synergy Process presented in this book) results in a powerful combination for building successful applications.

The goal of UML is twofold: One aim is to provide consistency in giving feedback to the project sponsor that the problem domain is well understood. The other is to provide a consistent model for proper software implementation. However, if you attempt to use UML without a sound process model and project plan (discussed throughout this book and fully presented in the appendices), your project will fail.

All of the artifacts that UML delivers are traceable. If developed in conjunction with a sound process, like the Unified Process, the UML models will build on one another. This element of traceability is key to the project. With UML, the project will not only produce less useless and "go-nowhere" deliverables, but it will serve as a checkpoint of the previous model's soundness. Because the UML models are interlocked in their creation, identifying when a component is missing or potentially incorrect is easier.

Some artifacts used in this book are not UML diagrams, nor are they covered in the Unified Process. As is explored later in the book, UML doesn't directly address some aspects of a project, including these:

  • Graphical user interface (GUI)
  • Process distribution
  • Data distribution

In all cases, though, the information needed from these vital areas is based on knowledge gained from the UML diagrams. For example, one artifact useful in distributed systems is the object/location matrix. This matrix details geographically interested locations in the domain and assesses the kind of usage that they perceive for the objects in the system. Its input consists of the classes identified on the class diagram and the locations uncovered in the use-cases. Again, all artifacts must be traceable; otherwise, they aren't worth creating.

The Essence of Modeling

A key benefit of modeling is that it provides a communication pipeline for project team members. Without sound models, team members render their knowledge of the system from their own perspectives. A project can't tolerate individualized perspectives of, for example, requirements. If it did, the project would end up not meeting "perceived" requirements. And regardless of what the project charter says, the project team would be blamed for not meeting someone else's agenda.

Booch says that modeling should accomplish the following four goals:

  1. Assist the project team in visualizing a system as it is or as it is intended to be.

  2. Assist in specifying the system's structure or behavior.

  3. Provide a template that guides in constructing the system.

  4. Document the decisions that the project development team has made.

All of these goals echo the common theme of maintaining good communication. Without good communication, the project will fail. UML meets these goals, and more.

The UML Diagrams

UML consists of nine different, interlocking diagrams of a system:

  1. Activity
  2. Class
  3. Collaboration
  4. Component
  5. Deployment
  6. Object
  7. Sequence
  8. State
  9. Use-case

The package diagram is also an important diagram in UML, but not one of the nine key diagrams. It was formerly called the subsystem diagram in other notations and can contain any and all of the diagrams listed here.

The diagrams are evolutionary in their construction. Nevertheless, they are merely different views of the domain. Because people have different backgrounds in modeling, categorizing the diagrams according to multiple perspectives can be helpful. (Figure 1-11 maps the nine diagrams to the five views of the software architecture, to be discussed shortly, for a given project.) The nine diagrams are divided into three categories: static, dynamic, and architectural.

A static diagram depicts the system's structure and responsibilities. Static diagrams are similar to the building contractor's "as-built" drawings, which depict multiple subsystems, all interacting within the framework of the physical structure. The static diagrams are

  • Class
  • Object
  • Use-case

A dynamic diagram depicts the live interactions that the system supports. Dynamic diagrams detail the interaction among structural artifacts from the static diagrams (classes). These dynamic interactions are discovered in the use-cases as pathways performed in response to an external system stimulus. Dynamic diagrams also provide a much clearer picture of the intended, realized behavior of the system. The dynamic diagrams are

  • Activity
  • Collaboration
  • Sequence
  • State
  • Use-case

An architectural diagram categorizes the system into running and executable components. Architectural diagrams also distinguish the physical location of execution and storage nodes and a framework within which they can interact. They often are produced very early in the project (e.g., during project scoping) to indicate the intended physical architecture. They are further detailed during the Construction and Transition phases to clarify early assumptions that will be physically implemented. The architectural diagrams are

  • Component
  • Deployment

UML and the 4+1 View of Architecture

An interesting perspective of a project's architecture and the UML modeling artifacts used to describe the system comes from the "4+1" view of software architecture. Developed by Philippe Kruchten and covered in his book The Rational Unified Process: An Introduction (published by Addison-Wesley), this view involves, in fact, five different views, as illustrated in Figure 1-11:

  • Use-case
  • Logical
  • Implementation
  • Process
  • Deployment

Figure 1-11 4+1 view of software architecture

The use-case view describes the functionality that the system should deliver as perceived by the external "actors" and the requirements of the system. Intended for users, analysts, designers, developers, and testers, the use-case view is central to all the other views because its contents drive the development of the other views. The use-case should be technology neutral, contain no object-speak, and focus on the what rather than the how of the system solution.

The logical view describes how the system functionality is provided. Intended mainly for designers and developers, it looks inside of the system, in contrast to the more macro use-case view. It describes both the static structure (classes, objects, and relationships) and the dynamic collaborations that occur when objects send messages in response to an external or internal event.

The implementation view describes the implementation modules and their dependencies. The modules can provide for cross-checks back to the other deliverables to ensure that all requirements are eventually actualized into code. It is mainly for developers and consists of the component diagram.

The process view (also called the concurrency view) describes the division of the system into processes and processors. This division allows for efficient resource usage, parallel execution, and the handling of asynchronous events. Intended for developers and integrators, it consists of the state, sequence, collaboration, and activity diagrams, as well as the component and deployment diagrams.

The deployment view describes the physical deployment of the system via the component and deployment diagrams. Developers, integrators, and testers utilize this view.

Using the UML Diagrams in Context

Although nine diagrams might seem a bit overwhelming, not every project will use all of them. For example, many projects might not require state or activity diagrams. A state diagram is used to model the lifecycle of instances of one class, and then only when that class exhibits complex or interesting dynamic behavior. Such classes are prevalent in embedded real-time applications but are not as common in business-oriented applications. Activity diagrams are useful for modeling complex steps within a use-case or an operation found in a class.

Other diagrams offer complementary views of the same thing, such as those found in the sequence and collaboration diagrams. Actually, many visual modeling tools allow you to create the collaboration diagram from the sequence diagram.

In practice, projects will always produce the following diagrams at a minimum:

  • Class/collaboration
  • Sequence
  • Use-case

Projects would also be well served if they produced component and deployment diagrams. In my consulting work, I have encountered the recurring problem of the project team's not taking enough time to visualize and model the design's physical realization. The team assumes a cavalier attitude toward component assembly and, more importantly, the assignment of components to actual processors. Often the requirements are realized and the design is elegant, but response times are poor or ongoing issues of component distribution affect the application's supportability. Many of these issues can be resolved by the use of rich and expressive syntax of the component and deployment diagrams.

This book offers hints regarding when to apply which diagrams. It also stresses the importance of traceability between the diagrams. Early in my career, success as an analyst or designer depended on the weight and thickness of the requirements and design documents. I would like to think that after finishing this book, you will know better when to use which diagrams and will end up with project documentation that is as light as possible and yet complete.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020