|
For more info about using Package diagrams and lots of other useful info, buy Jim Conallen’s book “Building Web Applications with UML”, Addison Wesley, 2000.
Notes about JVISION appear in italics interspersed throughout this quote from Jim Conallen:
“One of first activities of the analysis team is to create the package hierarchy of the analysis model. As with any complex system, one natural way to attack the task of representing the problem
and solution space in a comprehensible way is to ‘divide and conquer.’ The UML mechanism for this is the package. A package is nothing more than a ‘chunk’ of the model: small enough
that one can understand its purpose and significance in the model. Packages contain elements of the model; classes, diagrams, components, interfaces, and so on. Every element in the model is
owned by exactly one package. This does not limit model elements from appearing in the diagrams of other packages or from participating in relationships of elements in other packages. Classes
in a package can be made public or private. (In JVISION a package symbol, represented as a folder icon, can be linked to a class diagram. Pay attention to how you decide which classes are public.) Classes in a package can be made public or private. A public class in a package is visible to and can be used by elements outside of the package. In a way, these classes represent the public interface of the package and should be chosen carefully.
Packages themselves can be further subdivided into more packages; hence, it is possible for a model to be represented by a hierarchy of packages. The most important property of a package is that it
should be comprehensible. A person should be able to understand and to comprehend a package’s purpose, significance, major elements, relations, and relations to elements owned by other packages.
A package is rendered graphically as a tabbed folder (This is the symbol JVISION uses for a link). A package has a name that is unique throughout the model. (In JVISION you are
responsible for enforcing this yourself). Each package forms a namespace, meaning that two elements can have the same name as long as they are owned by two different packages. (In JVISION we
recommend that you do not reuse names for different elements.)
Packages can have relationships with one another. The two types of relations are dependency and generalization. A dependency relationship typically means that one package depends on,
or has structural knowledge of, elements in the other. This relationship is drawn with a dashed line and an arrowhead pointing to the package that the other depends on.
A generalization relationship is like generalization in classes; the subpackages represent specializations of a package. For example a User Interface package might have two
subpackages; Active-Enabled UI, and Java-Enabled UI. Both contain elements that support the goal of providing a use interface, but each subpackage does so with a different architecture.
Throughout the process, the package can also be used to denote ownership. Typically, a package is “owned” by one analyst or designer. The public classes of the package are that
package’s interface to the other packages of the system. The designer is free to add additional classes or to alter the methods of private classes in the package without impacting the rest of
the team. Changes in public classes and operations, however, need to be agreed on. A properly maintained model should be able to quickly answer the question, ‘Who uses this
class’s public interface?’ Since they are ‘owned’ by team members, packages make for a convenient unit of version control and are checked out of the configuration management system
by the analyst or designer when being worked on.”
|
