Web services programming tips and tricks: Applying packages on UML diagrams

How to simplify complex diagrams

Read these tips on using packages to simplify and organize your UML software diagrams. This article was modified from Chapters 3 and 6 of The Object Primer 2nd Edition.

Scott W. Ambler, Practice Leader, Agile Development, Rational Methods Group, IBM, Software Group

Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com.



30 November 2000

Also available in Japanese

Packages are Unified Modeling Language (UML) constructs that enable you to organize model elements, such as use cases and classes, into groups. Packages, when applied effectively, are used to simplify your software diagrams. In the UML, packages are depicted as file folders, as you see in Figure 2, and may be used on any UML diagram. However, packages are most commonly applied to use case diagrams and class diagrams because these models have a tendency to grow and hence have a greater need to be partitioned.

An example: Simplifying a use case diagram

Figure 1 depicts a complex use case diagram (use case diagrams are described in "Modeling essential use cases"), and Figure 2 shows how you would partition it using packages. By introducing packages, the use case diagram becomes simpler and easier to understand. Each package, in turn, would be documented by another use case diagram, such as the one presented in Figure 3.

Figure 1. A partial use case model for a university system
Partial use case model for a university system
Figure 2. A use case model organized with packages
A use case model organized with packages
Figure 3. The "Manage seminar registration" package
The Manage Seminar Registration package

Rules of thumb for applying packages

  • Apply packages when diagrams become cluttered
    I typically use packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single page. Packages can be used to organize a large diagram into several smaller ones. A good heuristic is that a diagram should have 7 +/- 2 bubbles on it, where each bubble is a use case or class.
  • Packages should be cohesive
    Anything you put into the package should make sense when considered with the rest of the contents of the package. A package is likely cohesive if you can give it a short, descriptive name. If you can't, you may have put several unrelated things into the package.
  • For use case diagrams, start with related use cases
    To identify packages on use case diagrams, I like to start with use cases that are related to one another via extend and include associations. My heuristic is that included and extended use cases belong in the same package as the base/parent use case. This rule works well because these use cases typically were introduced by "pulling out" their logic from the base/parent use case to start with. I then analyze the use cases with which my main actors are involved. What you will find is that each actor will interact with your system to fulfill a few main goals; for example, students interact with your system to enroll in the university, manage their schedules, and manage their financial obligations with the university.
  • For class diagrams, start with related classes
    I take a similar approach for UML class diagrams. First, classes in the same inheritance hierarchy typically belong in the same package. Second, classes related to one another via aggregation or composition often belong in the same package. Third, classes that collaborate with each other a lot -- information reflected by your sequence diagrams and collaboration diagrams -- often belong in the same package. Fourth, the desire to make your packages cohesive will often drive your other decisions to put a class into a package.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=11457
ArticleTitle=Web services programming tips and tricks: Applying packages on UML diagrams
publish-date=11302000