2. Advanced Principles II Principles of Object-Oriented Component Design Copyright  1998-2006 by Object Mentor, Inc All Rights Reserved Portions of this material are Copyright © 1998, by Addison Wesley Longman,Inc. and have been reproduced here with permission. www.objectmentor.com www.junit.org

3. 2 Increasing Complexity Windows 95: 14,500,000 Windows NT: 35,000,000

4. 3 Complexity and Failure (Software’s Chronic Crisis, Scientific American, September, 1994)

5. 4 Complexity dilutes Productivity Because complexity of software can grow geometrically with size...

6. 5 Coupling Coupling is the term used to describe the dependence of one software module upon another. When coupling is high, there are many dependencies between the modules. In a system with n modules, the coupling can be as high O(n 2 ). 1 23 4 56 7

7. 6 Coupling – Impact of Change The impact of making a change to a module is a function of its coupling. Every module that depends upon the changed module must be inspected, compiled, tested, and redeployed. Moreover, the transitive closure of modules that depend upon a changed module must be recompiled, re-tested, and redeployed. That transitive closure can be as high as O(n); And since there are n such closures in the system… (A system with a fully coupled architecture) 1 23 4 56 7

8. 7 Dilution of Productivity As the application size grows, more and more effort is applied to dealing with coupled modules. At the knee of the curve more effort is applied to coupling than adding features. The effort expended to add new features drives the complexity upwards and drives the productivity downwards.

9. 8 So… Project effort increases geometrically with project size. … Project size increases Exponentially with time.

10. 9 Other costs of a highly coupled architecture Geometrically increasing compile time. Geometrically increasing unit test time. Componentization is infeasible. Making footprint and load-time issues unmanageable.

11. 10 Barrier to Components As footprint and load time grows, the desire to break the software into individual components -- that can be independently built, tested, and deployed -- increases. However, componentization depends critically upon being able to create subsystems that are independent. So long as coupling is high, and dependency cycles are rampant, componentization will be infeasible. 1 23 4567 1 23 4 56 7 ?

12. 11 Faulty Architecture: Dependency Cycles A single cyclic dependency in an otherwise acyclic structure can dramatically increase coupling. Note that the red dependency forces module six to depend upon every other module in the system. Such dependencies have a tendency to creep in over time as the system is being maintained and enhanced. Especially during schedule crunches. 1 23 4567

13. 12 The Solution Create a software architecture with well managed interdependencies.

14. 13 Flattening the Geometric Curve Coupling need not increase as O(n 2 ). Tree structures have no cycles and reduced coupling to O(nlog n); Productivity decreases with the log, not the square, of the number of modules. 1 23 4567 1 23 4 56 7

15. 14 Productivity Recaptured 1 23 4567 1 23 4 56 7 time See: Large Scale C++ Software Design by John Lakos.

16. 15 Principles of Object Oriented Component Design What is a component? Components on Class Diagrams The Triad of Component Principles REP: The Reuse/Release Equivalency Principle CCP: The Common Closure Principle CRP: The Common Reuse Principle

17. 16 Intro to Components Large systems of objects and classes would be overwhelming We have lots of small and simple classes A way must exist to deal with groups of classes Otherwise, it’s almost like building a sand castle from individual grains of sand “…the class is a necessary but insufficient vehicle for decomposition.” -- Grady Booch

18. 17 What is a component A group of classes. Some of the classes are public. Some of the classes are private. A C++ “Namespace”. A Java “Package”. A DLL. A releasable component. The “Simple” Answer

19. 18 Components on Class Diagrams Drawn as rectangle with a smaller rectangle above it. They can be drawn large with icons of classes and their interrelationships within them. Then the name should be in the “tab”. Also drawn as rectangle with two small rectangles on left. Looks like a file folder

20. 19 Package Relationships We will discuss two relationships between components Dependency Realizes Packages do not stand alone and must interact with other packages

21. 20 Dependency Structure Dependency structure of a n automated parking garage.

22. 21 Realizes Components may be composed of abstract classes.Other packages may provide implementations for the abstract classes. This is drawn as a dashed line (like dependency) with an open, triangular arrowhead (like inheritance). The relationship is officially known as “realizes”, but means that the concrete package implements the abstract package’s interface(s). This is another kind of dependency.

23. 22 Component Cohesion Principles REPReuse-release Equivalency Principle CCPCommon Closure Principle CRPCommon Reuse Principle

24. 23 (REP) The Reuse/Release Equivalency Principle What do you expect from a supplier of reusable modules? The granule of reuse is the granule of release

25. 24 Expectations Documentation. Accuracy. Maintenance. You expect the supplier to maintain the modules that you are reusing. Predictability. You expect that the module will not change out from under you. That you will be notified in advance of any changes That you will be given the option to use the old version.

26. 25 Reusers Expect Release Control In order to get users to agree to reuse a module: You must bind the reusable classes together into components. Each component need to be tracked in a release system. Each component needs release numbers. Each release needs release notes. Users must be able to continue to use the older versions for a while. Thus, the granule of reuse is the granule of release. Version numbers and release tracking.

27. 26 The granule of reuse is the granule of release. Single classes are seldom reusable They typically depend on other classes. They are not typically released alone. There are ramifications for component design The classes in a component should form both a releasable and a reusable module. This principle deals with a kind of cohesion.

28. 27 REP Review What is the REP? Are reuse groupings coincidental? Is it primarily concerned with coupling or cohesion? How does this differ from more traditional ways of grouping components? REP: Group for reusers

29. 28 (CCP) The Common Closure Principle Given an application to which changes need to be made: Do we want to change many components? Or as few as possible? Minimize the impact of change

30. 29 Scaling up the OCP The open closed principle states that a class should be “open for extension but closed for modification.” This cannot be completely achieved. Thus, we design our classes to be closed to the most likely kinds of changes that we can foresee. That important class design consideration is also an important component design consideration.

31. 30 Cohesion of Closure Classes within a component should be closed together. A component is cohesive if the classes within it are all closed to the same kinds of modifications. When this principle can be achieved, changes do not propagate through the system. Given a particular kind of change, either all of the classes within a package are closed to it, or they are all open to it.

32. 31 Non-Propagation of Changes Changes focus upon one, or a very few packages. The rest of the packages remain unaffected. This greatly lessens the number of packages that are affected by a change, and reduces the frequency with which components must be released.

33. 32 CCP and REP Sometimes these principles are in complete harmony The best of times Other times the two groupings may conflict somewhat. You can choose one to lean toward How much maintenance is expected? REP: Group for reusers CCP: Group for maintenance

34. 33 CCP Review What does the CCP tell us to do? Why is this a good idea? How is the CCP different from the REP? Do the CCP and REP direct us more toward broad horizontal (technical) partitioning, or vertical (functional) partitioning?

35. 34 (CRP) The Common Reuse Principle Classes within a component should be reused together Reuse creates a dependency upon the whole reused component. Reusable components are generally made of many collaborating classes.

36. 35 Reusers Depend on the Whole Component When a new release of that component is created, the reuser must reintroduce it into existing applications. There is a cost for this And a risk Therefore, the user will want each component to be as focused as possible. If the component contains classes which the user does not make use of, then the user may be placed in the position of accepting the burden of a new release which does not affect any of the classes within the component that he is using.

37. 36 Common Reuse Principle This is a principle that breaks up components. You will end up with some small, focused components. You’ll end up with some loose classes. Loose classes may be grouped with REP and CCP into more cohesive groups. Volatility should be considered. Given simply, the user should depend on the whole package. This is a scaled up version of Interface Segregation.

38. 37 Reusable Components Have Many Collaborating Classes The relationships between those classes bind them together Placing them in separate components will create dependencies between those components.

39. 38 Conflict in the Triad REP: Group for reusers CCP: Group for maintenance CRP: Split to avoid unneeded releases Will receive unneeded releases. Changes split among components Too little reuser convenience Where in this space does your package fall?

40. 39 CRP Review What does the CRP tell us to do in component design? How is it different from the REP? How is it different from the CCP? Could you draw the triad, and label the corners? Place a well-known library or component in the triangular space, showing how the tradeoffs were made.

41. 40 Package Cohesion Principles Summary REPGroup for convenience of (re)users CCPGroup for convenience of maintainers CRPSplit to prevent dependencies on partial packages

42. 41 Principles of Component Coupling (ADP) The Acyclic Dependencies Principle. (SDP) The Stable Dependencies Principle. (SAP) The Stable Abstractions Principle. Metrics: Management vs. random walks. Packages and Directory Structures. Source code configuration systems. The larger the project, the more critical it is to manage the relationships between components

43. 42 (ADP) The Acyclic Dependencies Principle Applications must be stabilized and released in pieces. Otherwise, the developers interfere with each other: The “Morning After” Syndrome. By carefully structuring components, the problem is avoided. The dependency structure for components must be a DAG.

44. 43 The “Morning After” Syndrome You work till 5PM getting something working. But when you come back the next day… Your stuff doesn't work. Somebody stayed later than you did… … or came in earlier And this repeats, day after day after day… The engineers on a project step all over each other. Time to stabilize a release is unpredictable.

45. 44 Dependency Structures The problem may be that the dependency structure of the project is poor, is not understood or is not respected. Changes are rippling through the system in several directions!

46. 45 Well structured packages prevent this problem Components can be released. Users that aren’t ready for the release can continue to use the old versions. The developers can continue to modify components without affecting the users. Components are stabilized and then released internally Changes flow in one direction only Dependency Cycles ruin this scheme.

47. 46 Well Structured Packages Prevents This Problem

48. 47 In the garage system (prev page), we have a sane structure. We can stabilize and plan in a rational way. Now there is a change: When there is a problem, we just rang an alarm Now we realize we need to display a message The ‘alarm’ programmers aren’t aware of the DAG... How do package structure problems occur?

49. 48 Dependency Cycles Ruin This Scheme The resulting structure is no longer a DAG.

50. 49 Breaking the Cycle It’s once again a DAG. Structure and sanity return to our little world.

51. 50 Cycles can also be broken by adding abstraction Imposing an abstract class can invert a dependency

52. 51 Stable Dependencies Principle A component should only depend upon others that are more stable than itself Stability is a measure of the difficulty in changing a component What makes a component hard to change?

53. 52 A Component with many dependents is “Responsible” Responsibility implies stability. Not free to change Irresponsibility implies instability. Free to change A Component that depends on many others is “Dependent”. Independence implies stability. Dependence implies instability. Stable Dependencies Principle

54. 53 Depending in the direction of INstability This is a bad thing Component A depends in a direction of INstability. B is free to change. When B changes, changes can ripple up to A. Since A is not free to change, this will create a problem. We wish to depend in the direction of Stability Stable Dependencies Principle

55. 54 Here, A is irresponsible and very dependent. B is responsible and independent. In this case, A is free to change on its own, and nothing in the system is impacted by the change. B is stable, and so it’s undesirable to change it. This is a healthy structure. Stable Dependencies Principle

56. 55 Stable Dependencies Principle Stability can be measured Define I. Instability metric I = Ce / ( Ca + Ce) Ce = Efferent couplings Ca = Afferent couplings I = 1 / ( 3 + 1 ) = 0.25 I = 0 I = 1

57. 56 Stable Abstractions Principle The abstraction of a package should be in proportion to its stability If all packages are maximally stable, the system would be unchangable Some packages should be stable Those that encapsulate high-level policy These packages should be abstract Some packages should be instable Those that encapsulate low-level implementation details

58. 57 Stable Abstractions Principle Abstractness of a package can be measured A = Na / N Na = number of abstract classes N = total number of classes

59. 58 Analyzing Metrics Packages have degrees of abstraction versus stability Packages along the line from (0,1) to (1,0) have a good balance (0,1) (1,0) Main Sequence

60. 59 Analyzing Metrics Abstractions without dependents are useless. Concretions with lots of dependents are painful. e.g. database schemae (0,1) (1,0) Main Sequence Zone of uselessness Zone of pain

61. 60 Main Sequence (cont.) Distance from Main Sequence (normalized) D = | A + I - 1 | Design can be analyzed for conformance to main sequence D

62. 61 Tools that Calculate the Metrics Smallworlds Headway Jdepend www.clarkware.com Depend.sh www.objectmentor.com

63. 62 Component and Directory Structures Our convention at Object Mentor, Inc. Each component is represented by a directory. All the.cc and.h files are placed in that directory. A library file (.a) is generated for that directory. Any documentation files should be included too Make file. The directory structure is generally flat. Nested packages are not impossible, but are rare. #include Written as # include “package/file.h”