Standards: Packages -
Overview
 |
A package is a collection of classes, relationships, use-case realizations, diagrams,
and other packages; it is used to structure the design model by dividing it into smaller
parts. Packages are used primarily for model organization and typically serve as a unit of
configuration management.
In Rose, packages are also used to represent subsystems.
|
| Related Information: |
|
Topics
Introduction 
Packages are used to decompose models by dividing them into smaller parts.
Without the use of packages the end result is large, flat models in which all elements
have to be uniquely named. This would soon become unmanageable especially when
attempting to integrate and manage elements developed by multiple developers and multiple
teams.
The package is also the unit of configuration in Rose – the models must be split
into packages to support multi-user development (each package can become a controlled
unit).
Packages can also be involved in more than one model at a time. This is very
common when using the models to facilitate the analysis and design of component based
developments. In this case the packages should be read-only in all the models except
their initial design model, the one in which their development actually takes place.
Packages are used to decompose models in many ways:
- packages are used to represent the layering applications
- to group the classes into logical packages
- to identify the logical subsystems of the application
- to hold the architectural views required to define, and describe, the architecture
- to provide a higher level of abstraction than that provided by individual classes.
Note: if a package contains too many public classes to easily display on a single class
diagram then the package is probably too large and should be split into multiple packages.
Packages are also used to organize the Use-Case focused part of the dynamic model. In
this case:
- the packaging is used to facilitate the realization of the Use Case Model by instances
of the classes defined in the static object model
- the packaging is used to provide a more functional view of the system
- the packaging is used to partition the use case focused aspects of the dynamic model
– the use case realizations.
Note: Packages are also used to partition the Use Case Model – these standards are
not covered by this document they are dealt with in the Use Case Modeling Guidelines.
Naming Standard
Begin package names with an upper case letter. Package names can include spaces
and punctuation where this clarifies the model. In practice package names are short
groupings of nouns or noun phrases drawn from the vocabulary of the domain.
The names of the packages should communicate their purpose.
General Documentation
All packages will have their brief description completed. This will be a one or
two paragraph description summarizing the purpose of the package. This should be
entered in the "General Tab" for the package documentation.
Note: additional documentation is required for each package stereotype used. The
stereotypes are defined in the table below and linked to pages describing the specific
standards to be applied in each case.
Note: packages can be marked as global – a package can only be global if it is a
top-level package or its parent package is global.
Use of Stereotypes
Stereotypes are used to clarify the intent and purpose of the packages in the model.
Individual documentation and diagramming standards are defined for each stereotype.
The stereotypes are grouped by their underlying purpose:
- Organizational - those that denote packages purely used to organize the model.
Organizational package stereotypes include <<dynamic>>, <<layer>>,
<<model>>, <<view>>
and <<work>> (See Standards: Organizational Packages for more details).
- Structural - those that denote the packages that logically represent the pieces of the
system (including subsystems) that are to be implemented.
Structural package stereotypes include: <<facade>>,
<<implementation>>, <<subsystem>>
and <<utility>> (See Standards:
Structural Packages for more details).
Note: if a package is unstereotyped it is considered to be work in progress and treated
as if it used the <<work>>
stereotype.
The UML also defines the following package stereotypes:
- <<framework>>
- <<top package>>
- <<system>>
No standards are defined for these stereotypes - they are only mentioned to prevent
their local use without consideration of their wider UML definition. These will not
be used in the current models. |
