As a model may have hundreds (if not thousands) of model elements, how do you organize the elements that make up a system and their relationships? And how do you use this information to determine how best to develop the system while considering technical trade-offs concerning the system, including which elements may be developed in parallel, which elements may be purchased rather than built, and which elements may be reused? Packages and subsystems, called model management elements, address these questions.
A package is a grouping and organizing element in which other elements reside, which must be uniquely named. In the UML, packages are used in a manner similar to the way directories and folders in an operating system group and organize files. For example, the project management system may be decomposed into a collection of classes organized into packages as follows:
Date, time, and other utility classes
Worker class and
other worker-related classes in which the
class is contained inside of a package named
Generic classes such as
Worker class and any other worker-related classes
UnitOfWork class and
any other work-related classes
WorkProduct class and
any other work product-related classes
A package housing classes responsible for providing a user interface through which users may interact with the system
A package housing ...