Download presentation
Presentation is loading. Please wait.
Published byJulian Lawrence Modified over 9 years ago
1
1 © Dennis Hart 2001 OOAD Packages, Dependencies & Interfaces Dr Dennis Hart
2
2 © Dennis Hart 2001 OOAD Complexity n Many systems involve a significant level of analysis and design complexity n Human capacity to manage complexity is limited n Psychologists have found we can deal with around 7 to10 items at once before starting to get overloaded and confused
3
3 © Dennis Hart 2001 OOAD Systems & Complexity n A very small system might have a class diagram with 7 to 10 items (classes) n A medium sized system might have 30 to 100 classes n A large system might have many hundreds, or possibly over a thousand, classes
4
4 © Dennis Hart 2001 OOAD Packages & Complexity n The UML concept for dealing with complexity is the package n A package is a “grouping of model elements and diagrams” n A package can be viewed as a subsystem – in fact in the UML a “subsystem” is just a particular kind of package
5
5 © Dennis Hart 2001 OOAD The Package Symbol Package symbol (“folder”) Package creation tool Subsystem creation tool (subsystems are just specialized packages)
6
6 © Dennis Hart 2001 OOAD Package Example n Suppose we needed to extend our MPMS model to include other personnel related matters like: Discipline & LegalDiscipline & Legal RecruitingRecruiting Honours & AwardsHonours & Awards … and so on …… and so on …
7
7 © Dennis Hart 2001 OOAD Package Example n We would wind up with a greatly expanded and much more complex model if we just added the necessary use cases, classes, interaction diagrams, etc needed n Instead we can use packages to organize the increased complexity
8
8 © Dennis Hart 2001 OOAD Package Example New (empty) packages New package (empty) for our existing model
9
9 © Dennis Hart 2001 OOAD Reorganizing the Model n Now we need to move all the existing model elements (that concern promotions & postings) into the appropriate package n Select the elements to be moved (in the Explorer window) and then drag and drop them onto the package icon
10
10 © Dennis Hart 2001 OOAD Reorganizing the Model Drag & drop
11
11 © Dennis Hart 2001 OOAD Reorganizing the Model Model elements now in “Promotions & Postings” package After minimzing “Promotions & Postings” package
12
12 © Dennis Hart 2001 OOAD “Discipline & Legal” Package (Partial) Class Diagram Clearly we need “Member” on this diagram (Members are charged with offences), but it is in a different package
13
13 © Dennis Hart 2001 OOAD “Discipline & Legal” Package (Partial) Class Diagram Drag and drop from Explorer window into class diagram
14
14 © Dennis Hart 2001 OOAD Package Element Visibility However, if an attempt is made to connect the “Member” class to (say) the Offence class with an association then …
15
15 © Dennis Hart 2001 OOAD Packages, Visibility & Dependency n The elements inside a package are not generally visible outside the package n If an element (e.g. a class) inside one package needs to “see” an element inside another package then there is (or should be) a dependency between them
16
16 © Dennis Hart 2001 OOAD Packages, Visibility & Dependency n To establish the dependency, create a new class diagram for the MPMS system n This diagram will show the two packages between which the dependency exists
17
17 © Dennis Hart 2001 OOAD Package Dependency Drag and drop the relevant packages from the Explorer window into the new class diagram
18
18 © Dennis Hart 2001 OOAD Package Dependency … and create the dependency between them Dependency tool The dependent package The package depended upon The dependency link
19
19 © Dennis Hart 2001 OOAD Inter-Package Associations Associations between classes in different packages Note that the associations can only be created from the other class(es) to “Member” (Why?)
20
20 © Dennis Hart 2001 OOAD Inter-Package Class Visibility n Once a dependency has been created, which classes (in the package depended upon) are visible and which aren’t? n This is determined by the specified visibility of each class
21
21 © Dennis Hart 2001 OOAD Inter-Package Class Visibility Visible to dependent packages Invisible to dependent packages
22
22 © Dennis Hart 2001 OOAD Packages within Packages n Packages can contain other packages (as, indeed, the MPMS package contains the others “Promotions & Postings”, “Discipline & Legal”, etc) n Nesting of packages to more than 2 or perhaps 3 levels is unusual
23
23 © Dennis Hart 2001 OOAD Designing Packages n What principles govern what should be contained in a package? n The basic considerations are the same as those that apply when assigning responsibilities: Low couplingLow coupling High cohesionHigh cohesion
24
24 © Dennis Hart 2001 OOAD Designing Packages n Essentially, there should be: Minimal associations, interactions and other types of dependencies between the elements in different packagesMinimal associations, interactions and other types of dependencies between the elements in different packages High functional cohesion between the elements within a particular package (e.g. it should be easy to give the package a meaningful name) …High functional cohesion between the elements within a particular package (e.g. it should be easy to give the package a meaningful name) …
25
25 © Dennis Hart 2001 OOAD Designing Packages n … Relatively few elements in one package that need to be visible to and/or used by elements in other packagesRelatively few elements in one package that need to be visible to and/or used by elements in other packages
26
26 © Dennis Hart 2001 OOAD Interfaces n Interfaces are used to model the edges or “seams” in a system n An interface defines a service (i.e. a set of available operations) offered by a model element – for example, a package
27
27 © Dennis Hart 2001 OOAD Interfaces n An interface is an abstract class (i.e. cannot have any instantiated objects) that has No attributesNo attributes Abstract operationsAbstract operations n The operations are available to clients, outside the element offering the interface, to use
28
28 © Dennis Hart 2001 OOAD Realizing an Interface n Eventually, an element (e.g. a package) offering an interface must realize that interface n That is, one or more classes in the package must implement the operations defined in the interface
29
29 © Dennis Hart 2001 OOAD Interface Symbol aPackage uses (i.e. is dependent upon) the interface operations offered or “realized” by bPackage Dependency Interface
30
30 © Dennis Hart 2001 OOAD Questions? ? Next
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.