Why was UML created?

The UML was a milestone in the history of software methodologies, and represented a continuum of change in software development techniques. The UML was created out of controversy over the best methodology to use to develop and specify software. Dozens of methods were and are in use, each with a loyal following. Unfortunately, many of us were forced to choose between these warring factions and bear the overhead and frustration of finding software tools and training.

• Three Amigos: In 1994, Grady Booch and James Rumbaugh, the two market share leaders in object-oriented (OO) software methods, formally joined forces to develop a notation standard. A year later, they published the Unified Method version 0.8. Ivar Jacobson, yet another of the most noteworthy names in OO development, joined the team. The team of Rumbaugh, Booch and Jacobson were soon after referred to as the "three amigos" within OO circles.
• OMG RFP: At the same time, the Object Management Group (OMG) was establishing the Object-Oriented Analysis and Design OOA Task Force. In June 1996, the task force issued a request for proposal (RFP) for a standardized metamodel and technology to support the exchange of CASE tool models. This was an important first effort in developing a standard for specifying software systems and working toward an end to the notation wars plaguing our industry. The RFP allowed only CASE tool vendors responsible for implementing the standard to sponsor proposals. By October 1996, a number of leading CASE tool manufacturers, including IBM and Microsoft, had partnered with Rational Software to sponsor the UML proposal to the task force. In November 1997, the OMG formally approved the UML version 1.1. In the next lesson, the UML specification will be discussed.

Many people seek out the UML as the answer to their methodology questions. Methodologies include a notation and a process. The UML provides only the notation, so after you finish this course your search is not over. You will still need to evaluate the process or processes that will work best for your development environment. Here are some starting places: Booch

1. Grady Booch: Object-Oriented Analysis and Design with Applications, second edition, Addison-Wesley, 1994
2. Coad/Yourdon: Peter Coad and Edward Yourdon
   Object-Oriented Analysis, second edition, Yourdon Press, 1991
3. Embley: David W. Embley, Barry D. Kurtz, and Scott N. Woodfield Object-Oriented Systems Analysis: A Model Driven Approach, Yourdon Press, 1992
4. Fusion
   Hewlett-Packard; Derek Coleman, Stephanie Bodoff, and Patrick Arnold
   Object-Oriented Development: The Fusion Method, Prentice Hall, 1994
5. Object Modeling Technique
   James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen
   Object-Oriented Modeling and Design, Prentice Hall, 1991
6. Odell
   James Martin and James J. Odell
   Object-Oriented Methods: Pragmatic Considerations, Prentice Hall, 1996
7. OOSE/Objectory
   Ivar Jacobson, Christerson, Jonsson, and Overgaard
   Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1994
8. Shlaer/Mellor
   Sally Shlaer and Stephen J. Mellor
   Object-Oriented Systems Analysis: Modeling the World in Data, Yourdon Press, 1989

• The Yin and Yang of UML 2: In UML 2 there are two basic categories of diagrams: structure diagrams and behavior diagrams. Every UML diagram belongs to one these two diagram categories. The purpose of structure diagrams is to show the static structure of the system being modeled. They include the class, component, and or object diagrams. Behavioral diagrams, on the other hand, show the dynamic behavior between the objects in the system, including things like their methods, collaborations, and activities. Example behavior diagrams are activity, use case, and sequence diagrams.
• Structure Diagrams in General:
  As I have said, structure diagrams show the static structure of the system being modeled. focusing on the elements of a system, irrespective of time. Static structure is conveyed by showing the types and their instances in the system. Besides showing system types and their instances, structure diagrams also show at least some of the relationships among and between these elements and potentially even show their internal structure. Structure diagrams are useful throughout the software lifecycle for a variety of team members. In general, these diagrams allow for design validation and design communication between individuals and teams. For example, business analysts can use class or object diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy. Architects can use the component and deployment diagrams to test/verify that their design is sound. Developers can use class diagrams to design and document the system's coded (or soon-to-be-coded) classes.

UML 2 considers structure diagrams as a classification; there is no diagram itself called a "Structure Diagram." However, the class diagram offers a prime example of the structure diagram type, and provides us with an initial set of notation elements that all other structure diagrams use. And because the class diagram is so foundational, the remainder of this article will focus on the class diagram's notation set. By the end of this article you should have an understanding of how to draw a UML 2 class diagram and have a solid footing for understanding other structure diagrams when we cover them in later articles.

• Purpose of Notations: Notations enable us to articulate complex ideas succinctly and precisely. In projects involving many participants, often of different technical and cultural backgrounds, accuracy and clarity are critical as the cost of miscommunication increases rapidly. For a notation to enable accurate communication, it must come with well-defined semantics, it must be well suited for representing a given aspect of a system, and it must be well understood among project participants. In the latter lies the strength of standards and conventions: when a notation is used by a large number of participants, there is little room for misinterpretation and ambiguity. Conversely, when many dialects of a notation exist, or when a very specialized notation is used, the notation users are prone to misunderstandings as each user imposes its own interpretation. UML provides a spectrum of notations for representing different aspects of a system and has been accepted as a standard notation in the industry. In this module, we first describe the concepts of modeling in general and object-oriented modeling in particular. We then describe five fundamental notations of UML that we use throughout the course:
  
  1. use case diagrams,
  2. class diagrams,
  3. interaction diagrams,
  4. state machine diagrams, and.
  5. activity diagrams
  For each of these notations, we describe its basic semantics and provide examples. We revisit these notations in detail in later modules as we describe the activities that use them. Specialized notations such as UML deployment diagrams are introduced later.
• Goal of UML:
  The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. For example, UML includes the use case diagrams introduced by OOSE and uses many features of the OMT class diagrams. UML also includes new concepts that were not present in other major methods at the time, such as extension mechanisms and a constraint language. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (for example, distributed systems, analysis, system design, deployment). System development focuses on three different models of the system.