Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 © Dennis Hart 2001 OOAD Packages, Dependencies & Interfaces Dr Dennis Hart.

Similar presentations


Presentation on theme: "1 © Dennis Hart 2001 OOAD Packages, Dependencies & Interfaces Dr Dennis Hart."— Presentation transcript:

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


Download ppt "1 © Dennis Hart 2001 OOAD Packages, Dependencies & Interfaces Dr Dennis Hart."

Similar presentations


Ads by Google