Software Engineering with Reusable Components

1
Software Engineeringwith Reusable Components

• RiSEs Seminars
• Sametingers 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 -gt self-contained and coherent

5
Component Development
Component Engineering Chapter 14

• 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 Generalization
Component Engineering Chapter 14

• 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 Certification
Component Engineering Chapter 14

• 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 properties
Component Engineering Chapter 14

• (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 components reusability,
  there are desirable for any piece of software

11
Certification levels
Component Engineering Chapter 14

• (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
Quality Assurance
Component Engineering Chapter 14
Emphasis Advantages Disadvantages Typical uses
Static analysis Automated Limited application, lack of available tools Checking simple design rules
Formal inspection Widely applicable, exploits human skills Labor intensive, checking possibly incomplete Checking functional correctness
Testing Flexible, gives some confidence in components Resource intensive, not rigorous Checking the implementation
Usage modeling Simply to understand and apply, gives confidence in components Labor and resource intensive Checking the implementation (mean time between failures)
Formal verification High degree of assurance Time consuming, lack of available tools Checking safety-critical components
Benchmarks Provides quantification Limited application Measurement of time and space performance
13
Component repositories
Component Engineering Chapter 14

• 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 Classification
Component Engineering Chapter 14

• 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 -gt 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 isnt
  common for attribute definitions.
• Facets and terms usually have an ordering, which
  isnt 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
Reuse-Driven Development
Application Engineering Chapter 15

• 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
Component reuse
Application Engineering Chapter 15

• 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
Component Modification and Adaptation
Application Engineering Chapter 15

• In many cases a component does not perfectly fit
  the required needs -gt 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 -gt minor modifications
• Reengineering clearly goes beyond adaptations
• White-box reuse

27
Component-Based Life Cycle
Application Engineering Chapter 15

• Integral part of the software life cycle
• Detailed information about components
  functionality
• Guarantees that the component successfully
  performs the functions it claims to do
• Information about possible modifications/adaptatio
  ns and their consequences for the overall
  function of a component

28
Reuse Activities
Application Engineering Chapter 15

• (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
Reuse Spiral
Application Engineering Chapter 15

• (Boehm, 1988)
• Explicit and early consideration of reuse
• Identifying alternate means for the implementation

30
Software Evolution
Application Engineering Chapter 15

• 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
Domain Analysis and the Software Life Cycle
Application Engineering Chapter 15

• 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.