Software Engineering with Reusable Components

1. Software Engineeringwith Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 14 and 15 Vinicius Cardoso Garcia

2. Summary • Component Engineering (Chapter 14) • Component Development • Component Generalization • Component Certification • Component Repositories • Component Classification • Application Engineering (Chapter 15) • Reuse-Driven Development • Component-Based Life Cycle • Domain Analysis and the Software Life Cycle

3. 14. Component Engineering

4. Component Engineering :: Chapter 14 • Software development for reuse • High-quality components with proper documentation • Components cannot be extracted from existing applications • Requires more effort • Components in applications: design for special requirements • They have to be generalized • Reusable components -> self-contained and coherent

5. Component Engineering :: Chapter 14 Component Development • Development with reusable components • Evaluate and integrate existing components in new context • Development for reuse • Develop components for reuse in other contexts than the one it was initially developed for • Attributes that influence reusability (Di Felice, 1993; Braun, 1994) • Generality, self-contained; high cohesion/minimal coupling; used for standardized architecture models and standardized interfaces; use of coding standards and naming conventions; modular/oo design; possibility of parameterization; independence; proper documentation

6. Component Engineering :: Chapter 14 • (De Mey, 1995) Guidelines for the design reusable components • Concepts used in a number of different places should be components, e.g., user interfaces; • If components require an undetermined or variable number of resources, these resources should be probably be components, e.g., role components; • Composite components should contain only a small number of components and take advantage of hierarchical decomposition; • Components should strike a balance between abstraction and concreteness.

7. Component Engineering :: Chapter 14 • The experience and talent of a software designer impact on the reusability of the resulting components. “An excellent programmer can write highly reusable software with most technologies.” (Mittermier, 1990) • OO decomposition of software is a design approach that to some extent supports the reuse of components • Does not implicitly lead to reusable components either

8. Component Engineering :: Chapter 14 Component Generalization • Should be independent of applications for which they were initially developed. • (Karlsson, 1995) Techniques for generalization • Widening: can be generalized by widening their scope (extending the requirements) • Narrowing: we can also narrow the scope and limit their functionality • Isolation: isolating specific requirements helps in constructing the rest independently • Configurability: a set of smaller components which can be composed in various ways in order to meet different needs. • Generalizing components is important, but there is also the danger of over-generalization • Balance must be found between reuse potential and ease of implementation

9. Component Engineering :: Chapter 14 Component Certification • Software developers should only reuse components they can trust and should refuse to reuse components of either low or unknown quality. • Some effort has to be made in order to quantify their characteristics • Focusing in testing only, important aspects of quality are not being considered • The idea behind certification of components is to guarantee that a specific set of quality guidelines has been met (Dunn, 1993)

10. Component Engineering :: Chapter 14 Component properties • (Dunn, 1993; Patel, 1992) • Guidelines • Testing standards • Performance standards • Conceptual clarity • Coupling and cohesion • Some of these properties are still vague and have to be refined • In not restricted to a component’s reusability, there are desirable for any piece of software

11. Component Engineering :: Chapter 14 Certification levels • (Merrit, 1994) propose 4 levels of certification • A component is described with keywords and an abstract and is stored for automatic retrieval. No tests are performed; the degree of completeness is unknown. • A source code component must compile to be worthy. Metrics are determined if defined for the particular language. • Testing, test data and test results are added. • A reuse manual is added.

12. Component Engineering :: Chapter 14 Quality Assurance

13. Component Engineering :: Chapter 14 Component repositories • Database for the storage and retrieval of reusable components. • Contain software components with all relevant information about them • Is the link between development for reuse and development with reuse • Availability of potentially reusable components in the repository • Also depends on the mechanism to find components and programmers ability to search

14. Component Engineering :: Chapter 14 • Local repository • Stock a broad range of general-purpose components • Domain-specific repository • Provide a special purpose components within a well-defined scope and offer more depth • Reference repository • Assist in finding components in other repositories. They archive (references to) published components and serve as yellow pages

15. Component Engineering :: Chapter 14 • Evaluating repositories (Banker, 1993) • The level of reuse does not grow as the number of available components grow; • Most of the components are reused within the same projects • Programmers tend to reuse components that they developed themselves. • Griss et al (Griss, 1994) suggest the use of different search mechanisms depending on the size of repository

16. Component Engineering :: Chapter 14 Component Classification • Is used to group similar components, i.e., all members of a group sharing one characteristic that components of other groups do not. • In literature the term component classification is used with two slightly different meanings • It can mean a component taxonomy (chapter 9) – classification of components in general • It is used for the classification of particular components – How to classify concrete components in order to retrieve them for reuse in certain contexts?

17. Component Engineering :: Chapter 14 • Free text and keyword classification • Is the simplest form of identify suitable components for reuse • Keywords entered by the developer -> Query • The major advantage is that can easily be fully automate • However, it is also quite inaccurate and can allow retrieval of unsuitable components • Enumerated Classification • Schemes hierarchical categories divided into subcategories, sub-subcategories, and so on. • Is that they easy to understand and use • Shortcoming: Inflexibility and ambiguity (components can fit perfectly into various categories)

18. Component Engineering :: Chapter 14 • Faceted Classification • Based on attribute-value pairs and can be considered as perspectives, viewpoints or dimensions of particular domains (Prieto-Díaz, 1987) • Complex relationships can be created by combining facets and terms; and facets can be changed individually without affecting other ones. • Attribute-Value Classification • Very similar to Faceted Classification; faceted uses a small number of facets, this limit isn’t common for attribute definitions. • Facets and terms usually have an ordering, which isn’t typical for attributes and values. Finally, synonyms cannot be handled properly. • Similar to enumerated, a shortcoming is ambiguity.

19. Component Engineering :: Chapter 14 • Automatic Indexing • Low-cost way to construct retrieval systems. • Classification based on knowledge bases with semantic information about application domains requires human resources to build these bases. • Indexing Vocabularies • Controlled vocabularies • Uncontrolled vocabularies

20. Component Engineering :: Chapter 14 • Frakes and Pole have presented an empirical study for the comparison (Frakes, 1994) • The four methods did not show any significant differences in search effectiveness (but produced partly different results) • All four methods did only ‘moderate well’ in terms of search effectiveness • Users did not clearly prefer any of the four methods • Differences in user search times were significant, with the best results for enumerated searching, the worst for keyword searching.

21. 15. Application Engineering

22. Application Engineering :: Chapter 15 • Is software engineering with systematic reuse of existing components and domain knowledge. • Application should be built by assembling components • In case needed components are not available they have to be specified and provided by component group • Is responsible for finding and possibly adapting suitable components • Use of components form beginning of project

23. Application Engineering :: Chapter 15 Reuse-Driven Development • Development with reuse • High-level design and specifications are created • Search for a suitable components will be incorporated • Reuse-driven development • System specification and architecture design are influenced by available components • Results in a higher degree of reuse • Causing the design to be less efficient • Compensated by lower development costs and higher quality

24. Application Engineering :: Chapter 15 Create system specification Search components Modify system specification Design architecture Search components Specify components Adapt components Reuse-driven development Integrate components

25. Application Engineering :: Chapter 15 Component reuse • It must be easier to find components than to develop them from scratch • Does not mean finding exactly what is need • Locating similar components can be sufficient • After components have been found, they must be understood • What the component does ? • Understanding becomes even more important when the component has to be modified

26. Application Engineering :: Chapter 15 Component Modification and Adaptation • In many cases a component does not perfectly fit the required needs -> modifications are required • Modifications (Sommerville, 1992): • Adding functionality • Additional requirements that did note exist • Removing functionality • Have more functionality than is required • Generalizing • Component may not be general enough • Adaptation -> minor modifications • Reengineering clearly goes beyond adaptations • White-box reuse

27. Application Engineering :: Chapter 15 Component-Based Life Cycle • Integral part of the software life cycle • Detailed information about component’s functionality • Guarantees that the component successfully performs the functions it claims to do • Information about possible modifications/adaptations and their consequences for the overall function of a component

28. Application Engineering :: Chapter 15 Reuse Activities • (Hooper, 1991) e (Kang, 1987) • Understanding • Reconfiguration • Retrieval • Adaptation • Integration • Evaluation • Systematic reuse: incorporated into the software life cycle Development with reuse Development for reuse

29. determine objectives, alternatives and constraints understanding, retrieval, reconfiguration evaluate alternatives: identify and resolve risks assessment, evaluation plan next phase evaluation, consolidation develop, verify next-level product modification, adaptation, integration Application Engineering :: Chapter 15 Reuse Spiral • (Boehm, 1988) • Explicit and early consideration of reuse • Identifying alternate means for the implementation

30. Application Engineering :: Chapter 15 Software Evolution • Requirements are not static • change over time • Maintenance efforts became increasingly difficult • system has not been design for maintenance • Components are continuously added, changed and removed from a system • Any changes in the set of components involve one or more cycles in reuse spiral

31. Application Engineering :: Chapter 15 Domain Analysis and the Software Life Cycle • Ongoing process with constant refinement of domain models domain analysis domain models . . . . . . software life cycle specification i application i . . . . . . reusable components

32. References (1) • SAMETINGER, J. Software Engineering with Reusable Components. Springer-Verlag, 1997. • DI FELICE, P. Reusability of mathematical software: A contribution. IEEE Transactions on Software Engineering, 19(8):835-843, August 1993. • BRAUN, C. L. Reuse. In Encyclopedia of Software Engineering, pages 1055-1069. 1994. • MITTERMIER, R. T. and ROSSAK, W. Reusability. In Modern Software Engineering: Foundations and Current Perspectives, chapter 7, pages 205-235. 1990. • Dunn, M. F. and Knight, J. C. Certification of reusable software parts. Technical Report CS-93-41, University of Virginia, August 31, 1993. • PATEL, S. et al. Certification of reusable software components. In 5th Workshop on Institutionalizing Software Reuse, California, October 1992. • MERRIT, S. Reusable Software. In Encyclopedia of Software Engineering, pages 1069-1071. 1994. • GRISS, M. L. et al. Managerial and organizational issues – starting and running a software reuse program. In , chapter 3, pages 51-78. 1994. • PRIETO-DÍAZ, R. and FREEMAN, P. Classifying software for reusability. IEEE Software, pages 6-16, January 1987. • FRAKES, W. B. and POLE, T. P. An empirical study of representation methods for reusable software components. IEEE Transactions on Software Engineering, 20(8):617-630, August 1994. • SOMMERVILE, I. Software Engineering. Addison-Wesley, 4th edition, 1992. • HOOPER, J. W. and CHESTER, R. O. Software Reuse: Guidelines and Methods. Plenum Press, New York 1991.

33. References (2) • KANG, K. O. A reuse-based software development methodology. In Workshop on Software Reuse. Boulder, CO, October 1987. • BOEHM, B. W. A spiral model of software development and enhancement. IEEE Software, 25(5):61-72, May 1988.