Sidebar
This is an old revision of the document!
Table of Contents
4.2.3.2 Reusability
- [char]Please Review
About
Reusability is one way to save time, resources and effort by reusing existing system or software assets that were created previously. Sometimes the assets maintain all the functionality they were originally constructed for (i.e., widets on a Graphical User Interface (GUI)). Sometimes, well written, modularized software has been abstracted to a generalized Modules that solve a particular pattern, in these cases, the software is reusable for an new purposes (i.e., a linked list, hash algorithm, etc).
Reusability is the ability of something to be used more than once. Reuse is the action of using something more than once. Reusability promotes and enables reuse but does not ensure it.1). Therefore, creating a system or program for Reusability is not important unless there is a “marketing effort” to help the system or product be reused. Marketing in this context does not mean the same as commercial marketing. Often the marketing can be done just through just making the code available as Open Source.
When a Software Engineer is asked about reuse, they naturally think about reuse of code, executable or even software patterns, etc. Ask a systems engineer, they think about use-cases, state transition diagrams, etc. Ask an Ontologist and they will think about glossaries, vocabularies and ontologies. Ask a contracting officer and they think of contracts and performance specifications. So, obviously even with the technology area, there are lots of different ideas about what, where and how to re-use artifacts.
Jones2) identifies 10 different areas just within a software project where reuse can play a part:
- Architectures
- Data
- Designs
- Documentation
- Estimates
- Human Interfaces
- Plans
- Requirements
- Test Cases
Types of Reuse
Reuse is a multi-faceted idea that requires a classification for the types of reuse. Frakes and Terry 3) have done an extensive review of the literature on Reuse and Reusability and have developed a taxonomy for reuse. Table 1 captures types of reuse called Facets in the taxonomy and uses Terms to describe each Facet. For example, the Development Scope Facet has two possible Terms within it: Internal and External. When describing the the Development Scoping used in a company or project, it can be Internal, External or both. The Terms used within each Facet are defined in Table 2.
| Facet | |||||
| Development Scope1) | Modification2) | Approach3) | Domain Scope4) | Management5) | Reused Entity6) |
|---|---|---|---|---|---|
| Internal (Private) | White Box | Generative | Vertical | Systematic (Planned ) | Code |
| External (Public) | Black Box (vrbatum) | Compositional | Horizontal | Ad Hoc | Abstract Level |
| Adaptive (porting) | In-the-Small | Instance Level | |||
| In-The-Large | Customization Reuse | ||||
| Indirect | Generic | ||||
| Direct | Source Code | ||||
| Carried Over | |||||
| Leveraged | |||||
Clear definitions of types of reuse are necessary prerequisites to measurement. Table 2 provides a faceted classification of reuse definitions gathered from the literature Each column specifies a facet, with the facet name inbold.
| Type of Reuse | Description |
|---|---|
| abstract-levelreuse | Abstract-level reuse is the use of high-level abstractions within an object-oriented inheritance structure as the foundation for new ideas or additional classification schemes |
| ad-hoc | Ad-hoc reuse refers to the selection of components which are not designed for reuse from general libraries; reuse is conducted by the individual in an informal manner |
| adaptive | Adaptive reuse is a reuse strategy which uses large software structures as invariants and restricts variability to low-level, isolated locations. An example is changing arguments to parameterized modules |
| black-box | Black-box reuse is the reuse of software components without any modification. See verbatim. |
| Carry-Over Reuse | Carry-Over Reuse is when software that occurs when one version of a software component is taken to be used as is in a subsequent version of the same system. |
| compositional | Compositional reuse is a reuse strategy which uses small parts as invariants; variant functionality links those parts together. Programming in a high level language is an example. Compositional reuse is the use of existing components as building blocks for new systems. The Unix shell is an example |
| customization reuse | Customization reuse is the use of object-oriented inheritance to support incremental development. A new application may inherit information from an existing class, overriding certain methods and adding new behaviors. |
| direct | Direct reuse is reuse without going through an intermediate entity. |
| external | External reuse level is the number of lower level items from an external repository in a higher level item divided by the total number of lower level items in the higher level item. See Public. |
| generative | Generative reuse is reuse at the specification level with application or code generators. Generative reuse offers the “highest potential payoff.” The Refine and MetaTool systems are state of the art examples. |
| generic | Generic reuse is reuse of generic packages, such as templates for packages or subprograms. |
| horizontal scope | Horizontal reuse is reuse of generic parts in different applications. Booch Ada Parts and other subroutine libraries are examples. |
| In-the-large | Reuse-in-the-large is the use of large, self-contained packages such as spreadsheets and operating systems. |
| In-the-small | Reuse-in-the-small is the reuse of components which are dependent upon the environment of the application for full functionality. Favaro asserts that component-oriented reuse is reuse-in-the-small. |
| indirect | Indirect reuse is reuse through an intermediate entity. The level of indirection is the number of intermediate entities between the reusing item and the item being reused |
| instance-level reuse | Instance-level reuse is the most common form of reuse in an object-oriented environment. It is defined as simply creating an instance of an existing class. |
| internal | Internal reuse level is the number of lower level items not from an external repository which are used more than once divided by the total number of lower level items not from an external repository. See Private. |
| leveraged | Leveraged reuse as reuse with modifications. |
| private | Private reuse as “the extent to which modules within a product are reused within the same product.” See Internal . |
| public | Public reuse as “the proportion of a product which was constructed externally.” See External. |
| source-codereuse | Source code reuse is the low-level modification of an existing object-oriented class to change its performance characteristics. |
| systematic(planned mode) | Planned reuse is the systematic and formal practice of reuse as found in software factories. |
| verbatim | Verbatim reuse as reuse of some item without modifications. See Black-Box. |
| vertical scope | Vertical reuse is reuse within the same application or domain. An example is domain analysis or domain modeling. |
| white-box | White-box reuse is the reuse of components by modification and adaptation. |
Types of Metrics and Models
Frakes and Terry also go on to develop a categorization of the kinds of metrics and models that can be used for evaluating reuse.
| Metric or Model | Description |
|---|---|
| Cost-Benefit Analysis | Uses models to include economic cost/benefit analysis as well as quality and productivity payoff.Maturity assessment models categorize reuse programs by how advanced they are in implementing systematic reuse. |
| Maturity Assessment | Uses models to categorize reuse programs by how advanced they are in implementing systematic reuse. |
| Amount of Reuse | Uses metrics to assess and monitor a reuse improvement effort by tracking percentages of reuse for life cycle objects. |
| Failure Modes Analysis | Identifies and order the impediments to reuse in a given organization. |
| Reusability Metrics | Indicates the likelihood that an artifact is reusable. |
| Reuse Library Metrics | Manage and Tracks usage of a reuse repository. |
* Note: Organizations often encounter the need for these metrics and models in the order presented.
DDS Specifics
Data Distribution Service (DDS) can not address all the reuse potential within a system or program. However, there are some aspects where DDS can play a big role.
- Because DDS is a Publish-Subscribe architecture, any other parts of the system or program that use the publish-subscribe architectural style, are potential places where design, implementation and testing of the Topics are good candidates for reuse. For example, reusing a Topic that describes temperature sensors.
- The source code for the Publishers and Subscriber for a topic can be reused many times within a system, a program , or across systems and programs.
- The Data published and subscribed can easily be reused simply by adding a new listeners within a DDS Domain to the data being published. The data can also be filtered to address the use of data at different locations within the automation hierarchy described in 04_data_integrity.
- Designs can be reused by simply looking at the Network Topology and reusing it to solve similar problems i.e., the Supervisory Control and Data Acquisition (SCADA) design for one dam can be used by other dams.
- Documentation for Datatypes, data structures, topics and even a domain can be reused anywhere there is a similar reuse as described in steps 1 through 4 above.
- Estimates for costing and sizing are very reusable by simple multiplication. For example, if the cost of getting one medical
sensor working is X dollars, the cost of have100 sensors is 100*X. Since DDS is scalable without the need to purchase new infrastructure (i.e., real or virtual servers). - Human-machine interface (HMI) or Graphical User Interface (GUI) because of the nature of the publish-subscribe paradigm a specific interface can be reused as long as the interface is true to the function (i.e., interfaces for temperature and pressure in manufacturing can be reused, it would not work to try and use that interface for airplanes). However, there can be generalized human interfaces that can be reused such as performance monitors or Network Topology monitors.
- Plans because DDS is scalable and supports backward compatibility (see Extensible and Dynamic Topic Types for DDS (DDS-XTypes)), upgrade plans can be used over and over again.
- Requirements can definitely be reused. Especially those for non-functional requirements (see nonfunctional);
- Test Cases can definitely be reused and should be simplified because there are fewer parts to test and startup initialization is minimal because of DDS Discovery.
