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
- Grady Booch: Object-Oriented Analysis and Design with Applications, second edition, Addison-Wesley, 1994
- Coad/Yourdon: Peter Coad and Edward Yourdon
Object-Oriented Analysis, second edition, Yourdon Press, 1991
- Embley: David W. Embley, Barry D. Kurtz, and Scott N. Woodfield
Object-Oriented Systems Analysis: A Model Driven Approach, Yourdon Press, 1992
Hewlett-Packard; Derek Coleman, Stephanie Bodoff, and Patrick Arnold
Object-Oriented Development: The Fusion Method, Prentice Hall, 1994
- Object Modeling Technique
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen
Object-Oriented Modeling and Design, Prentice Hall, 1991
James Martin and James J. Odell
Object-Oriented Methods: Pragmatic Considerations, Prentice Hall, 1996
Ivar Jacobson, Christerson, Jonsson, and Overgaard
Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1994
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.