Guidelines:
Import Dependency in Design
Dependency |
An
import dependency in the design model is a stereotyped dependency
whose source is a design package and whose target is a different design
package. The import dependency allows the public contents of the target package to be referenced in the source package. |
Topics
Handling import dependencies between packages is an important aspect of
structuring an object model. A package depends on another if any of its classes
have relationships that are navigable to classes in the other package. To
express such dependencies you use the import dependency from
one package to the package on which it depends.
Dependencies between packages are expressed by import
dependencies.
You evolve import dependencies in the following manner:
- Before you start working with the object model, make outlines of
dependencies for use as guidelines during the work.
- When the model is completed, use it to show the dependencies actually
there. This entails updating the import dependencies in the object model.
- If you divided the model into packages early on, use the import
dependencies to show where dependencies are allowed.
- How packages depend on one another affects a system's tolerance to change.
An object model will be easier to change if you:
- Reference a minimum number of contained classes from outside each package.
If you reference many classes, the package may have too many different
responsibilities and should be divided into two.
- Make each package depend on few other packages.
- Test each package separately. This means that you should be able to test a
package by simulating the package on which it depends. You should not
require other packages to be completely or almost completely implemented. If
you can test a package separately, system development and maintenance for
each package will be easier.
- Place general parts of the object model in separate packages on which
other packages depend. If there is such a package, pay strict attention to
release handling, since several parts of the system may be affected by
changes to the package.
Example
Suppose you find something in common for the classes Customer
Panel and Operator Panel in the recycling machine. You
assign these general services to a new class, Panel that you
place in a new package, Panels. The other two classes may then
refer to this class to use the general services. Because the classes belong to
two separate packages, the two packages will depend on the new package. This
elimination of redundancy implies that changes to the common functionality only
needs to be done in one place.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|