Chapter 15 - Software reuse
Chapter 16 - Component Based SWE

# Quiz

  1. Component-based software engineering is not a reuse-based approach. It is mean to develop systems that are implemented once and solely used for that application.

  2. To make independent, distributed components work together, you need middleware support that handles component communications.

  3. One of the only ways to meet the demands of secure, dependable, and quickly deployed software is to use component based SWE.

  4. At the highest level, there are two types of CBSE processes:

    1. Development for reuse
    2. Development with resue
  5. Which of these are not a method for component composition

    • Sequential composition
    • Hierarchical composition
    • Additive composition
    • Parameter composition
  6. Reuse-based software engineering is an approach to development that tries to minimize the reuse of existing software.

  7. Match the following benefit of Software Reuse with its explanation.

    1. Accelerated development

    Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time may be reduced.

    1. Effective use of specialists

    Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge.

    1. Increased dependability

    Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed.

    1. Lower development costs

    Development costs are proportional to the size of the software being developed. Reusing software means that fewer lines of code have to be written.

    1. Reduced process risk

    The cost of existing software is already known, while the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is especially true when large software components such as subsystems are reused.

    1. Standards compliance

    Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface.

  8. Web application security frameworks may help implement user authentication (login) and access control to ensure that users can only access permitted functionality in the system.

  9. The advantages of software reuse are lower costs, and faster software development. A disadvantage is higher risks.

  10. Potential problems with application system reuse include lack of control over functionality, performance, and system evolution

# Exercise

  1. What major technical and nontechnical factors hinder software reuse? Do you personally reuse much software and, if not, why not?

    Technical issues tend to focus on how reusable the software is? That means the potential of software for adaptation. Non-technical issues include how a project is managed and funded.
    The non-technical problems in reusing components include increased maintenance costs, finding understanding, and adapting reusable components. If the source code of a reused software system is not available, then maintenance costs may be higher.
    Technical issue is not the one for reusability to reach its full potential, non technical factors are also to be considered. These factors are related to the motivational and organizational issues. Managers may be unwilling to compromise their requirements to allow reusable components to be used. Also there may be lack of tool support.
    Software reuse must be considered when development cost and time reduced. But there is also a significant cost associated with whether or not a component is suitable for reuse in a particular situation. In that situation software reuse must not be considered.

  2. List the benefits of software reuse and explain why the expected lifetime of the software should be considered when planning reuse.

    Accelerated development: Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time may be reduced.
    Effective use of specialists: Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge.
    Increased dependability: Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed.
    Lower development costs: Development costs are proportional to the size of the software being developed. Reusing software means that fewer lines of code have to be written.
    Reduced process risk: The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused.
    Standards compliance: Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface.

  3. Most desktop software, such as word processing software, can be configured in a number of different ways. Examine software that you regularly use and list the configuration options for that software. Suggest difficulties that users might have in configuring the software. Micro- soft Office (or one of its open-source alternatives) is a good example to use for this exercise.

    List of configuration facilities in Microsoft Word:

    1. Preferences screen
    2. Customization screen
    3. Organizer screen
    4. Definition of templates
    5. Definition of styles
    6. Definition of macros
    7. Inclusion of add-ins (e.g. Endnote)
      In MS-Word 2007 there are difficulties to set a password to the document. It is not like previous versions where a menu bar is included. MS-Word 2007 has settings with all options (paragraphs, page layouts etc) embedded in the relative tool but difficult to find. For example, word option is included in circular office button on upper left corner. The Options dialog box used to be accessible by choosing Options from the Tools menu in previous versions. It is impossible to see or print the settings of all system preferences on a single screen.
  4. What are the significant benefits offered by the application system reuse approach when compared with the custom software development approach?

    1. As with other types of reuse, more rapid deployment of a reliable system may be possible.
    2. It is possible to see what functionality is provided by the applications, and so it is easier to judge whether or not they are likely to be suitable. Other companies may already use the applications, so experience of the systems is available.
    3. Some development risks are avoided by using existing software. However, this approach has its own risks, as I discuss below.
    4. Businesses can focus on their core activity without having to devote a lot of resources to IT systems development.
    5. As operating platforms evolve, technology updates may be simplified as these are the responsibility of the application system vendor rather than the customer.
  5. Explain why adaptors are usually needed when systems are constructed by integrating application systems. Suggest three practical problems that might arise in writing adaptor software to link two application systems.

    1. Lack of control over functionality and performance
      Although the published interface of a product may appear to offer the required facilities, the system may not be properly implemented or may perform poorly. The product may have hidden operations that interfere with its use in a specific situation. Fixing these problems may be a priority for the system integrator but may not be of real concern for the product vendor. Users may simply have to find workarounds to problems if they wish to reuse the application system.
    2. Problems with system interoperability
      It is sometimes difficult to get individual application systems to work together because each system embeds its own assumptions about how it will be used. Garlan et al. (Garlan, Allen, and Ockerbloom 1995), reporting on their experience integrating four application systems, found that three of these products were event-based but that each used a different model of events. Each system assumed that it had exclusive access to the event queue. As a consequence, integration was very difficult. The project required five times as much effort as originally predicted. The schedule was extended to two years rather than the predicted six months.
      In a retrospective analysis of their work 10 years later, Garlan et al. (Garlan, Allen, and Ockerbloom 2009) concluded that the integration problems that they discovered had not been solved. Torchiano and Morisio (Torchiano and Morisio 2004) found that lack of compliance with standards in many application systems meant that integration was more difficult than anticipated.
    3. No control over system evolution
      Vendors of application systems make their own decisions on system changes, in response to market pressures. For PC products in particular, new versions are often produced frequently and may not be compatible with all previous versions. New versions may have additional unwanted functionality, and previous versions may become unavailable and unsupported.
    4. Support from system vendors
      The level of support available from system vendors varies widely. Vendor support is particularly important when problems arise as developers do not have access to the source code and detailed documentation of the system. While vendors may commit to providing support, changing market and economic circumstances may make it difficult for them to deliver this commitment. For example, a system vendor may decide to discontinue a product because of limited demand, or they may be taken over by another company that does not wish to support the products that have been acquired.
  6. What are the design principles underlying the CBSE that support the construction of under- standable and maintainable software?

    Apart from the benefits of reuse, CBSE is based on sound software engineering design principles:

    • Components are independent so do not interfere with each other;
    • Component implementations are hidden;
    • Communication is through well-defined interfaces;
    • One components can be replaced by another if its interface is maintained;
    • Component infrastructures offer a range of standard services.
  7. The principle of component independence means that it ought to be possible to replace one component with another that is implemented in a completely different way. Using an example, explain how such component replacement could have undesired consequences and may lead to system failure.

    In Ariane 5 launcher system, the developers reused the component from a previous version of the launcher (the Inertial Navigation System) Ariane 4 which was successful without any exceptions. The component was not modified for Ariane 5, it also consists of additional functionality that was not required for Ariane 5. First test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off. The software failed due to unhandled exception that caused the run-time system to shutdown. The functionality that failed in this component was not required in Ariane 5.

  8. In a reusable component, what are the critical characteristics that are emphasized when the component is viewed as a service?

    Viewing a component as a service provider emphasizes two critical characteristics of a reusable component:

    1. The component is an independent executable entity that is defined by its inter- faces. You don’t need any knowledge of its source code to use it. It can either be referenced as an external service or included directly in a program.
    2. The services offered by a component are made available through an interface, and all interactions are through that interface. The component interface is expressed in terms of parameterized operations, and its internal state is never exposed.
  9. Why is it important that components should be based on a standard component model?

    Component based software engineering is the process of defining, implementing and integrating independent components into a system. The standards define how component interface should be specified and how components communicate. If components conform to standards, then their operation is independent of their programming language. The components written in different languages can be integrated into the same system.

  10. What are the essential differences between CBSE with reuse and software processes for original software development?

    The essential differences between CBSE with reuse and software processes for original software development are as follows:

    1. The user requirements are initially developed in outline rather than in detail, and stakeholders are encouraged to be as flexible as possible in defining their requirements. Requirements that are too specific limit the number of components that could meet these requirements. However, unlike incremental development, you need a complete description of the requirements so that you can identify as many components as possible for reuse.
    2. Requirements are refined and modified early in the process depending on the components available. If the user requirements cannot be satisfied from available components, you should discuss the related requirements that can be supported by the reusable components. Users may be willing to change their minds if this means cheaper or quicker system delivery.
    3. There is a further component search and design refinement activity after the system architecture has been designed. Apparently, usable components may turn out to be unsuitable or may not work properly with other chosen components. You may have to find alternatives to these components. Further requirements changes may therefore be necessary, depending on the functionality of these components.
    4. Development is a composition process where the discovered components are integrated. This involves integrating the components with the component model infrastructure and, often, developing adaptors that reconcile the interfaces of incompatible components. Of course, additional functionality may also be required over and above that provided by reused components.