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

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

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

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

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

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

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

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

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

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