Sidebar
Table of Contents
4.3.3.2 Reusability
About
Reusability is a way to save time, resources and effort by reusing existing system or software assets that were created previously. Sometimes these assets maintain all the functionality they were originally constructed to provide (e.g., widgets in a Graphical User Interface (GUI)). Sometimes, well written modularized software is abstracted into generalized Modules that can then be used to serve one or more design patterns, e.g., a linked list, hash algorithm, etc.) When this is done, the software is considered to be reusable.
Reusability is defined as the ability of something to be used more than once. In contrast, reuse is defined as the action of using something more than once. Reusability promotes and enables reuse but does not ensure complete reusability.1). Therefore, merely creating a system or program for Reusability is not important unless there is also a “marketing effort” to promote the reuse of the system or product. Marketing in this context does not mean commercial marketing. Often marketing can be achieved just through making the code available as Open Source.
The meaning and application of 'reuse' also depends on who you ask. To a Software Engineer, they naturally think about reuse of code, executables or even software patterns, etc. To a Systems Engineer, reuse makes them think about use cases, state transition diagrams, etc. To an Ontologist, reuse means glossaries, vocabularies and ontologies. To a contracting officer, they makes them think of contracts and performance specifications. Thus, it is obvious that even within a technology area, there are lots of different ideas about what, where, and how to re-use artifacts.
Jones2) identifies 10 different areas within a software project where reuse can be applied:
- Architectures
- Data
- Designs
- Documentation
- Estimates
- Human Interfaces
- Plans
- Requirements
- Test Cases
Types of Reuse
Reuse is a multi-faceted idea, which requires an overall classification for the various types of reuse. Frakes and Terry 3) have developed a taxonomy for reuse based on an extensive review of the literature on Reuse and Reusability. Table 1 depicts the two major elements of the reuse taxonomy: Facets, which cover all the types of reuse, and Terms, which are used to describe each Facet. For example, the Development Scope Facet has two possible Terms within it: Internal and External. When describing the Development Scoping used in a company or project, this can be Internal, External or both. The Terms associated with 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-level | Abstract-level reuse is the use of high-level abstractions within an Object-Oriented (OO) inheritance structure as the foundation for new ideas or additional classification schemes. |
| ad-hoc | Ad-hoc reuse refers to the selection of components that are not designed for reuse from general libraries or where reuse is conducted by an individual in an informal manner |
| adaptive | Adaptive reuse is a reuse strategy that 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 | Carry-Over Reuse is when software used with one version of a software component is carried over and used as is in a subsequent version of the same system. |
| compositional | Compositional reuse is a reuse strategy that uses small parts as invariants and then uses variant functionality to link these 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 | Customization reuse is the use of object-oriented inheritance to support incremental development. A new application may inherit information from an existing class, overriding some methods in that class 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 using 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 | Horizontal scope 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 that are dependent on the environment of the application to achieve 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 | 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 derived from an external repository and used more than once divided by the total number of lower level items not derived from an external repository. See Private. |
| leveraged | Leveraged reuse is reuse with modifications. |
| private | Private reuse is“the extent to which modules within a product are reused within the same product.” See Internal . |
| public | Public reuse is “the proportion of a product which was constructed externally.” See External. |
| source-code | Source code reuse is the low-level modification of an existing object-oriented class in order to change its performance characteristics. |
| systematic (planned mode) | Systematic/planned mode reuse is the systematic and formal practice of reuse as found in software factories. |
| verbatim | Verbatim reuse is reuse of some item without modifications. See Black-Box. |
| vertical scope | Vertical scope 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 categorize 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 payoffs. 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 the percentages of reuse for life cycle objects. |
| Failure Modes Analysis | Identifies and orders the impediments to reuse in a given organization. |
| Reusability Metrics | Indicates the likelihood that an artifact is reusable. |
| Reuse Library Metrics | Manages and Tracks usage of a reuse repository. |
* Note: Organizations often encounter the need for these metrics and models in the order presented.
DIDO Specifics
Startup initialization is minimal because of DDS Discovery.
- To be added/expanded in future revisions of the DIDO RA
