1. Stability and Volatility is Software Design H. Rahnama Tutorial in software engineering

2. Good Software Design: Testability, Reusability On a large scale decomposition of the system represents significant design decisions Large scale modules in Java:.JAR, C#:DLL, C++:SO All systems should be designed so that they could be broken down into INDEPENDENTLY depolyable modules. Module independence: Better design

3. Reusability and Testability Reusability and testability depend of designs that supports independent deployability Modular Dependence: They make build order ambiguous Cause transitive dependency Prevent independent reuse of modules

4. Cyclic Graphs! Module A depends on Module B Module B depends on Module C Module C depends on Module A None of the modules can be reused independently

5. Good Design: ADP Acyclic Dependencies Principle Dependencies among modules must be arranged in a Directed Acyclic Graphs No cycles of dependencies among modules Eliminating cycles:First step in creating a modular design

6. ADP Principle These modules are dependent Document processor depends on two savers

7. ADP Principle Use Polymorphism instead of “If” Using the Interface Document Processor has no direct dependence on DatabaseSaver or FileSystemSaver Savers are VOLATILE

8. Volatility How changeable a module is. Saver module is more stable This lack of volatility allows the others to depend on it Other savers are safe from changes

9. Common Closure Principle (CCP) Codes with different kinds of volatility should be placed in different modules Modules should not depend on modules who are more volatile than they are. They should depend on less volatile ones.

10. Volatility vs. Stability Stability: How difficult a module is to change. Modules that are difficult to change are likely to be involatile Good design: Volatile Codes go to instable modules and involatile codes into stable modules.

11. Module X Is Module X Stable or Instable? Many other modules depend on it If its changes, others may need to be changed The more incoming dependencies a module has, the harder that module is to change, thus its more stable.

12. Module Y The module is easy to change: No other module depends on it So its instable Y has so many reasons to change, because it depends on many other modules.

13. Good design Volatile codes into modules like Y Involatile codes into modules like X Modules like X should never depend on Modules like Y What would happen if the author of X mentioned the name of some class in Y No code in Y has changed, yet Y is so difficult to change now

14. Measuring Module stability Stable Dependencies Principle (SDP) No module should depend on a module than it is less stable than it is Ce: (FanOut)-Number of modules that this modules depends upon Ca: (FanIn)- Number of modules that depend upon this module I(Instability) = Ce/(Ca+Ce) I is between [0,1] If I= 0, the module is very stable If I =1, the module is instable

15. Using I metrics Using I Metrics we can increase our modules ability to be independently deployable Applying I metrics can result in very stable, hard to change, inflexible modules What do about flexibility? OCP: Modules that are abstract can be extended without alteration. Abstraction: Flexibility

16. Dependency Inversion Principle ( DIP) Dependencies should point in the direction of abstraction Module Y contains classes that X wants to use How can we get X to use Y and not violate the SDP

17. Dependency Inversion Principle We create a new module called I, which contains an abstract class named AC Module X uses I and Y implements it X no longer depends on Y Volatile code in Y stays in Y Both X and Y depend on I X and Y depends in the direction of abstraction

18. Stable Abstraction Principle (SAP) The more stable a module is, the more abstract it should be Plot the instability of a module against its abstractness, the module should fall close to a line called : “The Main Sequence” Modules on the line are: Stable and Abstract Concrete and Instable

19. Measuring Module Abstractness A (Abstractness) = Na / Nc Na = Number of abstract classes Nc = Number of classes This metric falls between [1,0] How far a module can be from the Main Sequence: D (distance) = |A+I-1| : D Metrics Managers: D should be ZERO