Stability and Volatility is Software Design

H. Rahnama

Tutorial in software engineering

• 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

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

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

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

ADP Principle

• These modules are dependent

• Document processor depends on two savers

ADP Principle• Use Polymorphism instead of “If”• Using the Interface• Document Processor has no direct

dependence on DatabaseSaver or FileSystemSaver

• Savers are VOLATILE

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

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.

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.

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.

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.

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

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

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

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

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

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

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