1. Module 11: Packages
Lawrence Chung
CS6359.OT1: Module 11

2. Overview Packages Modeling groups of elements Lawrence Chung
CS6359.OT1: Module 11

3. Basics
Package — general-purpose mechanism for organizing elements into groups.
Names
Simple name — textual string distinguishing one package from others.
Path name — simple name prefixed by any enclosing package.
simple names
path names
Client
enclosing package name
+ OrderForm
package name
+ TrackingForm
Business rules
- Order
Sensors::Vision
{ version = 2.24 }
extended packages
Lawrence Chung
CS6359.OT1: Module 11

4. Owned/Nested Elements
Composite relationship (When the whole dies, its parts die as well, but not necessarily vice versa)
Destroyed if enclosing package is destroyed
textual nesting
graphical nesting
visibility
Client
Client
+ OrderForm
+OrderForm
+ TrackingForm
- Order
-Order
+TrackingForm
Lawrence Chung
CS6359.OT1: Module 11

5. Visibility
You can control the visibility of the elements owned by a package just as you can control the visibility of the attributes and operations owned by a class.
Packages that are friends to another may see all the elements of that package, no matter what their visibility.
If an element is visible within a package, it is visible within all packages nested inside the package.
Lawrence Chung
CS6359.OT1: Module 11

6. Importing & Exporting Importing
Grants a one-way permission for elements in one package to access the elements in another package.
Dependency with stereotype <<import>>
Exporting
Public parts of a package.
Server
Client
+ OrderForm
+Database
+ TrackingForm
+LoggingService
- Order
Is <<import>> transitive?
Is visibility transitive?
Does <<friend>> apply to all types of visibility: +, -, #?
exports
Policies
<<import>>
+OrderRules
-GUI:Window
GUI
<<import>>
+Window
imports
+Form
#EventHandler
Lawrence Chung
CS6359.OT1: Module 11

7. Standard Elements Façade — only a view on some other package.
Framework — package consisting mainly of patterns.
Stub — a package that serves as a proxy for the public contents of another package.
Subsystem — a package representing an independent part of the system being modeled.
System — a package representing the entire system being modeled.
Lawrence Chung
CS6359.OT1: Module 11

8. Modeling Groups of Elements
Look for “clumps” of elements that are semantically close to one another.
Surround “clumps” with a package.
Identify public elements of each package.
Identify import dependencies.
Java.awt
utd.administration
registration
Tools.db
db interfaces
Cloudscape
Oracle
Lawrence Chung
CS6359.OT1: Module 11

9. Summary Packages Modeling groups of elements Basics Visibility
Importing & Exporting
Standard Elements
Modeling groups of elements
Lawrence Chung
CS6359.OT1: Module 11

10. Points to Ponder
Dependencies between two packages reflect dependencies between any two classes in the packages. For example, if a class in Package A uses the services of a class in Package B, Package A is dependent on Package B.  Would you try to maximize dependencies between packages or minimize?
A package can be considered logically equivalent to a Java package and dependencies between packages can be mapped to Java import statements. Give an example of such a mapping.
Can two different elements in two different packages have the same name?
Is packaging a good mechanism for testing? Why or why not?
Lawrence Chung
CS6359.OT1: Module 11