UML  «Prev 

Object-Oriented Methodologies

What is and is not included in the UML specification

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.

The class diagram in particular

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.