Home arrow Practices arrow Page 6 - Introducing UML: Object-Oriented Analysis and Design

Package Diagrams - Practices

The purpose of UML, or Unified Modeling Language, is communication; to be specific, it is to provide a comprehensive notation for communicating the requirements, architecture, implementation, deployment, and states of a system. This article will offer an overview of Object Oriented Analysis and Design, focusing in on the three most important concepts it encompasses: objects, analysis, and design. It is excerpted from the book UML Applied: A .Net Perspective, by Martin Shoemaker (Apress, 2004; ISBN: 1590590872).

  1. Introducing UML: Object-Oriented Analysis and Design
  2. Analysis
  3. UML
  4. UML Diagrams
  5. Component Diagrams
  6. Package Diagrams
  7. It’s All About Communication
  8. Summary
By: Apress Publishing
Rating: starstarstarstarstar / 169
July 21, 2005

print this article



A Package Diagram depicts how related elements of your design are grouped together, as well as how the groups depend upon each other. It’s useful for dividing a complex design into multiple, more manageable smaller designs. Figure 1-9 presents an example of a Package Diagram from the Kennel Management System.   

Figure 1-9.  Package Diagram of the Kennel Management System

Exercise 108:  Reading a Package Diagram

Answer the following questions about the diagram:

  1. Which packages make use of information from the KMS Interfaces package?

  2. Which packages does the KMS Central Classes package make use of?

“Wait a Minute! Those Arrows Are Pointing in the Wrong Direction!”

An Apology to Database Modelers and Data Flow Diagrammers

If you come from the database-modeling world and are used to entity relationship diagrams (ERDs), you probably got Exercise 108 exactly wrong. The same is probably true if you come from the world of data flow diagrams (DFDs). In both of those diagramming techniques, the arrows on a diagram indicate the direction of data flow. In UML, the dependency arrows (- - - - >) indicate the direction of knowledge and control. To those people familiar with ERDs and DFDs, this seems exactly backwards. Their instinct is to interpret Figure 1-9 as meaning that KMS Interfaces make use of Care Giver Classes, Accounting Classes, Reservation Classes, and KMS Central Classes.

The UML convention isn’t quite as backwards as it seems. How would a class in Care Giver Classes make use of an interface in KMS Interfaces? By calling its methods, of course. And very likely, the class would pass data to the interface as well. So control and even some data do indeed flow in the direction of the dependency arrow.

And if that doesn’t help you to keep the meaning of the arrows straight, I can only apologize, and claim innocence: I didn’t write the UML (though its convention seems “correct” in my biased perspective). I do know that this is a source of confusion for ERD and DFD practitioners; and I hope that this warning will help to minimize your confusion.

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: