UML and Design Patterns Prof. Dr. Eric Dubuis, V. June Engineering and Information Technology. On Package Design

Transcription

1 On Package Design Berner Fachhochschule Engineering and Information Technology Prof. Dr. Eric Dubuis Software Engineering and Design Version June

2 Content Package Design: Basic Principle Dependency Inversion Principle (DIP) Package Design: Coupling Principles Acyclic Dependency Principle (ADP) Stable-Dependencies Principle (SDP) Stable-Abstractions Principle (SAP) 2

3 Dependency Inversion Principle (DIP) The DIP stated: a) High-level classes should not depend on low-level classes. Both should depend on abstractions. b) Abstractions should not depend on details. Details should depend on abstractions. 3

4 Example: Layering Made Too Simple Policy Layer Policy Class Mechanism Layer Mechanism Class Utility Layer Utility Class 4

5 Example: Layering Respecting the DIP Policy Layer Policy Class «interface» Policy Service Interface Mechanism Layer Mechanism Class «interface» Mechanism Service IF Note: Factories are needed to create instances implementing the interfaces. Utility Layer Utility Class 5

6 Package Coupling: Acyclic-Dependency Principle (ADP) Consider: periodic or continuous builds per package testing The Acyclic-Dependency Principle stated: Allow no cycles in the package-dependency graph. Note: Cannot be avoided sometimes. 6

7 Example: Package Dependency Graph MyApplication TaskWindow MyTasks Database Windows Tasks MyDialogs 7

8 Example: Package Dependency Graph with a Cycle MyApplication TaskWindow MyTasks Database Windows Tasks MyDialogs 8

9 Example: Breaking the Cycle with Dependency Inversion MyDialogs MyApplication X Y MyDialogs MyApplication X X IF Y 9

10 Example: Breaking the Cycle with a New Package MyApplication TaskWindow MyTasks Database Windows Tasks MyDialogs New Package 10

11 Package Coupling: Stable-Dependency Principle (SDP) Stability: A software package is stable if lots of other packages depend on it. SDP stated: Depend in the direction of stability. 11

12 Illustration: Stable, Independent Package X Package X has three good reasons to be stable. It is responsible for those three packages. Package X depends on nothing, it is independent. 12

13 Illustration: Instable, Irresponsible, and Dependent Package Y Package Y is very instable. It has no other packages that depend on it; it is irresponsible. However, there are three other packages it depends on. Y is dependent. 13

14 Stability Metric The number of concrete and abstract classes (and interfaces) in the package is an indicator of the extensibility of the package. (Ca) Afferent Couplings: The number of other packages that depend upon classes within the package. (Responsibility) (Ce) Efferent Couplings: The number of other packages that the classes in the package depend upon. (Independence) (I) Instability: (Range [0, 1]) I = Ce Ca + Ce 14 Note: Originally [Martin2], the classes and interfaces were counted, not the packages.

15 Stability Metric Interpretation I = 1: no other package depend on this package (Ca = 0) this package depends on other packages (Ce > 0) it is instable, irresponsible, and dependent I = 0: this package is depended by other packages (Ca > 0) does not depend on other packages (Ce = 0) it is stable, responsible and independent 15

16 Stable-Dependencies Principle (SDP) and Stability Metric The SDP says that the instability metrics of a package should be larger than the instability metrics of the packages that it depends on. Or: The instability metrics should decrease in the direction of dependency. 16

17 Ideal Situation I = 1 I = 1 I = 1 Instable 1 Instable 2 Instable 3 I = 0 Stable 17

18 Example of SDP Violation Flexible: a package intended to be easy to change Stable: a package intended to be as stable as possible. Some developer, however, added a dependency on Flexible: e.g., some class in Stable depends on some class in Flexible Stable Flexible 18

19 Solution: Employing DIP Stable Flexible U C I Stable < I Flexible Stable not good... U I stable > 0 UInterface Flexible UI I UInterface = 0 C I Flexible = 1 19

20 On High-Level Design Some parts of the software should not change very often. (==> high-level [design] decisions.) We don't want these decisions to be volatile! ==> Put these decisions into stable packages (I = 0). Dilemma: Source code that represents these decisions will be difficult to change! How to package with maximal stability and still some flexibility for a change? ==> abstract classes, interfaces 20

21 Package Coupling: Stable-Abstractions Principle (SAP) The SAP stated: A package should be as abstract as it is stable. 21

22 Measuring Abstraction Nc: The number of classes in a package. Na: The number of abstract classes (and of interfaces in Java) in a package. A: Abstractness: A = Na Nc 22

23 The A-I Graph (0, 1) Zone of Uselessness A Axis outlined as it is with the JDepend plugin for Eclipse (0, 0) Zone of Pain I (1, 0) 23

24 Bibliography [Martin] Robert C. Martin, Agile Software Development, Prentice Hall, [Martin 2] Robert C. Martin, Stability, read December 20, 2007, 24