Packages provide a generic tool for grouping information and model elements. The contents of a package are entirely user-defined, so packages make a convenient tool for defining partitions. A package may be 1) named and 2) stereotyped, for example:
Dependency arrow: The Sales partition depends on the Show Pricing partition.
Dependency arrow: The Sales partition depends on the Show Pricing partition.
Package name and Stereotype (in label form; stereotypes may also be shown as icons
UML Packages
The use case model shown in the image contains two packages (or classes), each labeled with a stereotype `<< Domain Partition >>`.
The diagram also shows a dependency relationship between them.
Class/Package 1:
<< Domain Partition >>
Sales
Class/Package 2:
<< Domain Partition >>
Show Management
Relationship:
A "dependency arrow" is drawn from `Sales` to `Show Management`, indicating that:
Sales depends on Show Management
Additional Annotations (not classes but explanatory):
Package icon
Package name and Stereotype (in label form; stereotypes may also be shown as icons)
Dependency arrow: The Sales partition 'depends' on the Show Pricing partition. (Though note: it should probably read "Show Management partition" based on the actual class name in the diagram.)
Packages are UML constructs that enable you to organize model elements into groups, making your UML diagrams simpler and easier to understand. Packages are depicted as file folders and can be used on any of the UML diagrams, although they are most common on use-case diagrams and class diagrams because these models have a tendency to grow.
Packages and Dependencies
A package diagram shows packages and their dependencies. If you have packages for presentation and domain, you have a dependency from the presentation package to the domain package if any class in the presentation package has a dependency to any class in the domain package. In this way, interpackage dependencies summarize the dependencies between their contents. The UML has many varieties of dependency, each with particular semantics and stereotype. I find it easier to begin with the unstereotyped dependency and use the more particular dependencies only if I need to, which I hardly ever do. In a medium to large system, plotting a package diagram can be one of the most valuable things you can do to control the large-scale structure of the system. Ideally, this diagram should be generated from the code base itself, so that you can see what is really there in the system. A good package structure has a clear flow to the dependencies, a concept that is difficult to define
but often easier to recognize. Figure 4-3 shows a sample package diagram for an enterprise
application, one that is well-structured and has a clear flow.
Figure 4-3: An order request is sent to the Java EE server.
If you need some review of packages or package notation, please visit the Resources page and look at the pdf file UML Fundamentals_packages.
When you use a package to represent a subsystem, use the <<stereotype>> notation, for example, <<subsystem>>. This notation ensures that your model will be interpreted correctly. Like packages, stereotypes are pretty much up to you to define, but the UML standard does provide some standardized stereotypes.
Specifies a coherent set of roles that users of use cases play when interacting with these use cases
association
link end
Specifies that the corresponding object is visible by association
become
message
Specifies that the target is the same object as the source but at a later point in time and with possibly different values, state, orroles
copy
dependency
Specifies that the source a operation invokes the target operation
create
event or message
Specifies that the target object is an exact but independent copy of the source
derive
dependency
Specifies that the source may be computed from the target
destroy
event or message
Specifies that the target object is destroyed by the event or message
document
component
Specifies a component that represents a document
enumeration
class
Specifies an enumerated type, including its possible values as a set of identifiers
executable
component
Specifies a component that may be executed on a node
extend
dependency
Specifies that the source use case extends the behavior of the target use case at the given extension point in the target use case
facade
package
Specifies a package that is only a view on some other package
file
component
Specifies a package consisting of mainly patterns
friend
dependency
Specifies that the source is given special visibility into the target
global
link end
Specifies that the corresponding object is visible because it is in an enclosing scope
import
dependency
Specifies that the public contents of the target package enter the flat namespace of the source, as if they had been declared in thesource
implementation
generalization
Specifies that the child inherits the implementation of the parent but does not make public nor support its interface, thereby violatingsubstitutability
implementationclass
class
Specifies the implementation of a class in some programming language
include
dependency
Specifies that the source use case explicitly incorporates the behavior of another use case at a location specified by the source
instanceof
dependency
Specifies that the source object is an instance of the target classifier
instantiate
dependency
Specifies that operations on the source class create instances of the target class
invariant
constraint
Specifies a constraint that must always hold for the associated element
library
component
Specifies a static or dynamic object library
local
link end
Specifies that the corresponding object is visible because it is in a local scope
metaclass
classifier
Specifies a classifier whose objects are classes
parameter
link end
Specifies that the corresponding object is visible because it is a parameter
postcondition
constraint
Specifies a constraint that must hold after the invocation of an operation
powertype
class or dependency
Specifies a classifier whose objects are all the children of a given parent; specifies that the target is a powertype of the source.
precondition
constraint
Specifies a constraint that must hold before the invocation of an operation
process
class
Specifies a classifier whose instances represent a heavyweight flow
requirement
comment
Specifies a desired feature, property, or behavior of a system
responsibility
comment
Specifies a contract by or an obligation of a class
self
link end
Specifies that the corresponding object is visible because it is the dispatcher of the message
send
dependency
Specifies that the source operation sends the target event
stereotype
class
Specifies that the classifier is a stereotype that may be applied to other elements
stub
package
Specifies a package that serves as a proxy for the public contents of another package
system
package
Specifies a package representing the entire system being modeled
table
component
Specifies a component that represents a database table
thread
class
Specifies a classifier whose instances represent a lightweight flow of control
type
class
Specifies an abstract class that is used only to specify the structure and behavior (but not the implementation) of a set of objects
utility
class
Specifies a class whose attributes and operations are all class-scope
Purpose of Stereotypes
Because of UML 1, many people use the term stereotype to mean the same as keyword, although that is no longer correct.
Stereotypes are used as part of profiles. A profile takes a part of the UML and extends it with a coherent group of stereotypes for a particular purpose, such as business modeling. Unless you are into serious meta-model design, you are unlikely to need to create a stereotype yourself. You are more likely to use one created for a specific modeling purpose, but fortunately, use of a profile does not require you to know all of the details of how they are tied into the meta-model.
Packages and subsystem specifications
Packages may represent subsystems. In fact, "subsystem" is a UML keyword used with packages to specify "a grouping of elements of which some constitute a specification of the behavior offered by the other contained elements." The goal in domain partitioning is to place all of the model elements that define the behavior and the resources for the system into cohesive packages. Each package represents a subsystem, a subset of the complete functionality of the finished system.
Package Dependencies
Relationships between packages are expressed as dependencies[1].
A dependency is described with a dashed arrow and a stereotype or UML keyword. A dependency arrow indicates that the source package requires assistance from the target package, such as access to objects created or maintained by the target package, or functionality owned by the target package. In the booking system, for example, you cannot sell tickets for shows until the seats in the show have been defined and priced.
This subsystem will define the seat locations within the auditorium.
This subsystem tracks which seats are available for sale for each show.
This subsystem assigns prices to seats within each show.
Consequently, the Sales subsystem would depend on the Venue Management, which places the seats within the auditorium. The Sales subsystem would also depend on Show Management, which defines the shows; and Pricing, which assigns the prices to seats in each show.
Sales Subsystem Dependencies
Sales subsystem dependencies
You can organize your use case model by functionally related areas (subsystems), by release, or both.
One useful strategy is to identify all the use cases within a functional area on the use
case diagram, but write the narrative descriptions only for the use cases that will participate in the current release.
Create Reusable Subsystems
Model Based Systems Engineering provides the flexibility and expressiveness to define complex systems quickly effectively by reusing common entities across design projects. A Library is a package containing many reusable subsystems, parametric constraints, common data types and common value types, dimensions and units. The following diagram shows an example library model.
UML Library
In the example Library, each of the child packages contains child models that capture the following reusable entities:
Blocks defining systems such as those listed in the Components package, or those defined in the External package.
ConstraintBlocks defining parametric constraints for use in parametric models.
Value Types describing quantities, expressed as measurable dimensions in specific units.
Data Types and Flow Specifications describing data structures and Flows.
Domain Partitioning Packages
Click the Exercise link below to practice what you have learned about domain partitioning and packages. Domain Partitioning Packages
[1]Dependency: A relationship between two model entities in which a change to one (the independent model element) will affect the other (the dependent model element).
