How do you develop FOR reuse?

1. Capture the initial requirements, collecting the set of requirements to make an initial solution.

2. Define an initial solution or identify previous solutions to the same set of requirements. It is best to keep the solution in a form that customers can understand and validate. In the case of re-engineering, the result of this step should be the identification of previous solutions. A cost estimation for developing the actual solution should be made or updated at this time.

3. Identify possible generalizations. This is the inventive step in which we try to see the generality in our requirements and our solution, based on both the requirements and the initial solution. At this step the component's reuse potential should be discussed with the product management and the plan for following steps should be refined.

4. Identify potential reusers and collect their requirements. Potential reusers are important to ensure that the generality we include in our component is really justified.

5. Estimate the cost and benefit of added functionality. For each added requirement we must estimate:
   • the benefit for reusers who will use it
   • the extra cost (e.g. time to understand, remove) for reusers who do not need it

   Each potential reuser should also estimate the effort needed to develop the functionality he needs from scratch, and the probability that he will reuse the component.

6. Analyze the added requirements with respect to invariants and variation. This is the step that involves making a requirements hierarchy such as that illustrated in Figure 78. The hierarchy usually impacts the initial solution, and we should therefore be prepared to modify it if necessary.

7. Propose a generalized solution with specializations and cost estimates. Here we reconcile the different requirements into one solution by applying techniques to represent generality from the appropriate models.

8. Present the solution to reusers and reuse experts for validation and approval. Each reuser must ensure that the solution covers his requirements. He should also refine the estimate of how much it will cost him to reuse the component. The reuse expert's role is to ensure that the solution is satisfactory, to check that the proposed specializations are appropriate.

   Based on this input, we can decide if we will develop the component for reuse. All the estimates made during the analysis of requirements and solutions should be saved to enable comparison with actual data (see Chapter 4). Note that this step is taken before we start the bulk of the development effort.

9. Develop and document the solution. This is the final step where we implement the component or system. If we are developing a high-level component (Figure 76) we may repeat this process for reusable subcomponents. We discuss the documentation needed separately in Section 7.7.

Development FOR reuse guidelines

General guidelines
1. Gather information from as many sources as possible. [p299]

2. Capture all requirements as parts of the analysis models. [p300]

3. Use a notation that is easy to understand.

4. Present the models in a clearly visible way to all project members.

5. Refine and formalize the analysis models. [p301]

6. Conduct a formal review of the outputs from the analysis phase.

OO guidelines
7. Use inheritance to express specialization on types.

Reuse-specific guidelines
8. Analyze existing applications within the domain and identify commonalities. [p302]

9. Generalize in such a way that future alterations of the component are supported (i.e. introduce high level abstractions).

10. Pinpoint variants among existing and future systems within the domain.

General guidelines
11. Make optional parts of the system as subsystems. [p308]

12. Distribute system intelligence evenly.

OO guidelines
13. Make subsystems of strongly coupled classes that implement one unit of functionality.

14. Factor common responsibilities as high as possible up the inheritance hierarchy.

15. State responsibilities as generally as possible. [p309]

16. Minimize the number of collaborations a class has with other classes or subsystems

17. Minimize the number of subsystems.

18. Make subsystems out of classes which are likely to be affected by the same minor change in requirements.

Reuse-specific guidelines
19. Create as many abstract classes as possible. [p310]

20. Introduce subsystems late in the architectural design phase.

OO guidelines
21. If general properties of some classes can be identified and viewed as making up a generalization or abstraction of the classes, create a superclass for this generalization, gathering the identified general properties using inheritance. [p311]

22. Use multiple inheritance rarely.

23. If an operation X of a class is implemented by performing a similar operation on another class, then that operation should also be named X (recursion introduction). [p312]

24. One task - one method. Each method should perform only one task to keep it simple. For example, decompose a method called "put_and_print" into two methods.

25. Subclasses should be specializations.

26. The top of a class hierarchy should be abstract. [p313]

27. Keep a small total protocol for a class.

28. Keep classes small - avoid introducing too many methods.

Reuse-specific guidelines
29. Use abstract classes as far as possible in inheritance hierarchies.

30. Class hierarchies should be fairly deep and narrow. [p314]

31. Factor implementation differences into new abstractions.

32. Favor uniformity over specificity in naming conventions.

33. Keep method signatures consistent. [p315]

OO guidelines
34. Do not use multiple inheritance just to minimize code. [p330]

35. All methods intended to be overloaded or redefined in subclasses must be declared as virtual.

36. Do not cast down the inheritance hierarchy unnecessarily.

36. Try to avoid inheritance with cancellation.

38. Do not use private inheritance. [p331]

39. Keep classes small - avoid large total protocols.

40. Keep classes small - avoid the introduction of too many methods.

41. Keep the number of method arguments small.

42. Keep methods small.

43. Declare member methods "const" when possible. [p332]

44. Declare parameters "const" when possible.

45. Always make destructors virtual in the base class.

46. Eliminate "switch" statements on object types.

47. Specify attributes as "private". [p333]

48. Use "protected" methods instead of protected attributes in the base class, for interfacing the subclasses.

49. Avoid using "friends" if possible.

50. Avoid implicit "inline", that is, implementation and code in header files.

Reuse-specific guidelines
51. Inhibit classes intended to be abstract from being instantiated. [p334]

52. Implement implicitly generated class methods: constructor, destructor, copy constructor, and assignment operator.

53. When copying or assignment makes no sense, hide the copy constructor and the assignment operator in the "private" part of the class specification.

General guidelines
54. If a component is small and will be reused many times, or if is vital that it is totally reliable, it is better to perform a proof of correctness than to use conventional testing. [p336]

OO guidelines
55. Couple specific test cases and test beds to the component they are intended for. [p339]

56. Couple specific test cases and test beds to the component, components, or users they are intended to represent.

Reuse-specific guidelines
57. Couple specific test cases and test beds, or parts of them, to the parts of the component that represent specific functionality.

58. Record the test beds used for a component.

How do you develop WITH reuse?

1. Identify the components needed to build the application and which could be reused, derived, or adapted from existing reusable components.

   These components can be of several types:

   • Specific components which can be reused as is
   • General components which must be specialized
   • Libraries or other configurable components

   Note that in some cases (e.g. in a mature domain), guidelines, standards and application generators may be of benefit, but here we mainly deal with components which will compose the application.

2. Formalize the requirements for these components in terms of search conditions, and search for candidate components. The search for components can start as soon as we have some idea of the needed functionality. Early retrieved components can serve as a basis for refining the requirements.

3. Evaluate the retrieved candidates. During the analysis phase it may be possible to negotiate requirements with the customer. If the customer can save 90% of the cost by sacrificing 10% of the functionality, he should at least be aware of the option. It might also be that the retrieved components provide some functionality which the customer might want in addition to the functionality he has specified.

4. Choose the best candidate and investigate the chosen component thoroughly. Detailed understanding may lead you to reject the chosen component and consider another candidate.

5. Adapt the component if necessary, and integrate it (possibly with adaptation) into the application.

Development WITH reuse guidelines

59. Use different abstraction levels for the requirements depending on the phase of the development. The earlier in the development life cycle, the more general must be the requirements. [p346]

60. Enlarge the scope of the search for reusable components as widely as possible within the company, and do not ignore external sources of reusable components. [p347]

61. Use the taxonomy put forward by the company. [p348]

62. Use the appropriate view of a component to understand it.

63. Use domain analysis results, if available, to understand the characteristics of the component.

64. Consult experienced people. [p349]

65. Carry out a study of a high-level component so that you fully understand it and can make an appropriate selection if time allows.

66. Study the technical solutions for implementing adaptations based on your chosen mode of reuse. [p350]

67. Determine the appropriate level of investigation of components depending on the component type and the types of requirements to be fulfilled. [p351]

68. Evaluate the distance between candidate components and the requirements.

69. When using evaluation models based on metrics, consider the different evaluation levels of FCM (factor-criteria-metrics). [p352]

70. Do not forget to study the adaptations you need to integrate the component into the application development.

71. When selecting components, you should choose standardized ones in the absence of any other criteria. [p354]

72. Use a project-wide or module-wide prefix for each outstanding global name.

73. Define a standard communication protocol.

74. When making adaptations of a component in a given phase, do not forget to carry this information forward to the following phases.

75. Identify reuse opportunities during the specification phase, and identify specific reuse requirements that support them. [p359]

76. Do not over-specify requirements.

77. Use the domain analysis and validate new application requirements.

78. Use the products from domain analysis to understand the context in which the application takes place, and its dynamics.

79. Use available documentation as much as possible when learning about a reuse repository. [p360]

80. Select well-documented frameworks. [p362]

81. Consider downstream detailed design for framework evaluation.

82. Preserve the strategy implemented in the framework when adapting it.

83. Keep the life cycle sequencing for framework adaptation.

84. Use inheritance to customize reused frameworks. [p363]

85. Using browsers during the implementation phase is very useful in understanding components. [p365]

86. Establish implementation standards that facilitate the ease and safety of code reuse.

87. Control and document each modification performed on the component.

88. Rename programming entities when necessary.

89. Keep the naming coherent. [p366]

90. Keep coherence when manipulating programming entities.