dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability [2021/06/04 21:42] char [DIDO Specifics] |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability [2021/10/30 15:01] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== 4.3.3.2 Reusability ===== | ====== 4.3.3.2 Reusability ===== | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability| Return to Maintainability]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability| Return to Maintainability]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary:r: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., widgets on a [[dido:public:ra:xapend:xapend.a_glossary:g:gui]]). Sometimes, well written, modularized software is abstracted into generalized Modules that solve a particular pattern. In these cases, the software is made reusable to support new purposes (i.e., a linked list, hash algorithm, etc). | + | [[dido:public:ra:xapend:xapend.a_glossary:r: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 [[dido:public:ra:xapend:xapend.a_glossary:g: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 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.((Luis Zafra, __Know the Difference: Reusability vs. Reuse__, Global Logic, 22 September 2015, Accessed 3 August 2020, [[https://www.globallogic.com/latam/blog/know-the-difference-reusability-vs-reuse/]])). 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 making the code available as Open Source. | + | //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.((Luis Zafra, __Know the Difference: Reusability vs. Reuse__, Global Logic, 22 September 2015, Accessed 3 August 2020, [[https://www.globallogic.com/latam/blog/know-the-difference-reusability-vs-reuse/]])). 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 of 'reuse' depends on who you ask. To a Software Engineer, they naturally think about reuse of code, executable 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. Finally, ask a contracting officer about reuse and they will think of contracts and [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec|performance specifications]]. So, obviously even within a technology area, there are lots of different ideas about what, where and how to re-use artifacts. | + | 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 [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec|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. |
| Jones((Jones, C. __Software return on investment preliminary analysis__, 1993, Software Productivity Research, Inc., | Jones((Jones, C. __Software return on investment preliminary analysis__, 1993, Software Productivity Research, Inc., | ||
| - | )) identifies 10 different areas just within a software project where reuse can play a part: | + | )) identifies 10 different areas within a software project where reuse can be applied: |
| - Architectures | - Architectures | ||
| Line 28: | Line 26: | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability| Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability| Return to Top]] | ||
| - | Reuse is a multi-faceted idea that requires a classification for the types of reuse. Frakes and Terry (( | + | Reuse is a multi-faceted idea, which requires an overall classification for the various types of reuse. Frakes and Terry (( |
| William Frakes and Carol Terry, | William Frakes and Carol Terry, | ||
| __Software Reuse and Reusability Metrics and Models__, | __Software Reuse and Reusability Metrics and Models__, | ||
| Line 34: | Line 32: | ||
| Accessed on 4 August 2020, | Accessed on 4 August 2020, | ||
| [[https://pdfs.semanticscholar.org/53d3/37f49c7d1ef98968ae5ed7e699096974db10.pdf]] | [[https://pdfs.semanticscholar.org/53d3/37f49c7d1ef98968ae5ed7e699096974db10.pdf]] | ||
| - | )) have done an extensive review of the literature on Reuse and Reusability and have developed a taxonomy for reuse. Table {{ref>ReuseTaxonomy}} 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 {{ref>reusedefs}}. | + | )) have developed a [[dido:public:ra:xapend:xapend.a_glossary:t:taxonomy|taxonomy]] for reuse based on an extensive review of the literature on Reuse and Reusability. Table {{ref>ReuseTaxonomy}} 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 {{ref>reusedefs}}. |
| Line 40: | Line 38: | ||
| <caption>Types of Software Reuse<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3 | 3)]]</sup></caption> | <caption>Types of Software Reuse<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3 | 3)]]</sup></caption> | ||
| | **Facet** |||||| | | **Facet** |||||| | ||
| - | ^ Development Scope[(notes:>**Development Scope** refers to whether the reusable components are from a source external or internal to a project.)] ^ Modification[(notes:>**Modification** refers to how much a reusable asset is changed.)] ^ Approach[(notes:>**Approach** refers to different technical methods for implementing reuse. )] ^ Domain Scope[(notes:>**Domain Scope** refers to whether reuse occurs within a family of systems or between families of systems.)] ^ Management[(notes:>**Management** refers to the degree to which reuse is done systematically. )] ^ Reused Entity[(notes:>**Reused Entity** refers to the type of the reused object.)] ^ | + | ^ Development Scope[(notes:>**Development Scope** refers to whether the reusable components are from a source external or internal to a project.)] ^ Modification[(notes:>**Modification** refers to how much a reusable asset is changed.)] ^ Approach[(notes:>**Approach** refers to different technical methods for implementing reuse. )] ^ Domain Scope[(notes:>**Domain Scope** refers to whether reuse occurs within a family of systems or between families of systems.)] ^ Management[(notes:>**Management** refers to the degree to which reuse is done systematically. )] ^ Reused Entity[(notes:>**Reused Entity** refers to the type of the reused [[dido:public:ra:xapend:xapend.a_glossary:o:object|object]].)] ^ |
| | Internal (Private) | White Box | Generative | Vertical | Systematic (Planned ) | Code | | | Internal (Private) | White Box | Generative | Vertical | Systematic (Planned ) | Code | | ||
| | External (Public) | Black Box (vrbatum) | Compositional | Horizontal | Ad Hoc | Abstract Level | | | External (Public) | Black Box (vrbatum) | Compositional | Horizontal | Ad Hoc | Abstract Level | | ||
| Line 58: | Line 56: | ||
| <caption>Definitions of Types of Reuse<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3 | 3)]]</sup></caption> | <caption>Definitions of Types of Reuse<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3 | 3)]]</sup></caption> | ||
| ^ Type of Reuse ^ Description ^ | ^ 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 | | + | ^ abstract-level | Abstract-level reuse is the use of high-level abstractions within an [[dido:public:ra:xapend:xapend.a_glossary:o:oo]] 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 | | + | ^ 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 which uses large software structures as invariants and restricts variability to low-level, isolated locations. An example is changing arguments to parameterized modules | | + | ^ 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**. | | ^ 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. | | + | ^ 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 | <WRAP>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 | <WRAP>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</WRAP>| | + | Compositional reuse is the use of existing components as building blocks for new systems. The [[dido:public:ra:xapend:xapend.a_glossary:u:unix|Unix]] shell is an example</WRAP>| |
| - | ^ 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.| | + | ^ customization | Customization reuse is the use of object-oriented inheritance to support incremental development. A new [[dido:public:ra:xapend:xapend.a_glossary:a:application|application]] may inherit information from an existing [[dido:public:ra:xapend:xapend.a_glossary:c:class|class]], overriding some methods in that class and adding new behaviors.| |
| ^ direct | Direct reuse is reuse without going through an intermediate [[dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]]. | | ^ direct | Direct reuse is reuse without going through an intermediate [[dido:public:ra:xapend:xapend.a_glossary:e:entity|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**. | | ^ 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.| | + | ^ 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. | | ^ 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. | | + | ^ 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-large | Reuse-in-the-large is the use of large, self-contained packages such as spreadsheets and [[dido:public:ra:xapend:xapend.a_glossary:o:os|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. | | + | ^ 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 | | ^ 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 | [[dido:public:ra:xapend:xapend.a_glossary:i:instance|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. | | + | ^ instance-level | [[dido:public:ra:xapend:xapend.a_glossary:i:instance|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**.| | + | ^ 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 as reuse with modifications. | | + | ^ leveraged | Leveraged reuse is reuse with modifications. | |
| - | ^ private | Private reuse as "the extent to which modules within a product are reused within the same product." See **Internal** .| | + | ^ private | Private reuse is"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**.| | + | ^ public | Public reuse is "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 [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] characteristics. | | + | ^ source-code | Source code reuse is the low-level modification of an existing object-oriented class in order to change its [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] characteristics. | |
| - | ^ systematic(planned mode) | Planned reuse is the systematic and formal practice of reuse as found in software factories. | | + | ^ systematic (planned mode) | Systematic/planned mode 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**. | | + | ^ verbatim | Verbatim reuse is 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. | | + | ^ 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. | | ^ white-box | White-box reuse is the reuse of components by modification and adaptation. | | ||
| </table> | </table> | ||
| Line 90: | Line 88: | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability| Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability| Return to Top]] | ||
| - | Frakes and Terry also go on to develop a categorization of the kinds of metrics and models that can be used for evaluating reuse. | + | Frakes and Terry categorize the kinds of metrics and models that can be used for evaluating reuse. |
| <figure reusemetric> | <figure reusemetric> | ||
| Line 100: | Line 98: | ||
| <caption>Descriptions of Reuse Metrics and Models<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3| 3)]]</sup></caption> | <caption>Descriptions of Reuse Metrics and Models<sup>[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability#fn__3| 3)]]</sup></caption> | ||
| ^ **Metric or Model** ^ **Description** ^ | ^ **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. | | + | ^ 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. | | ^ 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. | | + | ^ 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 order the impediments to reuse in a given organization. | | + | ^ Failure Modes Analysis | Identifies and orders the impediments to reuse in a given organization. | |
| ^ Reusability Metrics | Indicates the likelihood that an artifact is reusable. | | ^ Reusability Metrics | Indicates the likelihood that an artifact is reusable. | | ||
| - | ^ Reuse Library Metrics | Manage and Tracks usage of a reuse repository. | | + | ^ 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. | * **Note:** Organizations often encounter the need for these metrics and models in the order presented. | ||
| </table> | </table> | ||
| Line 114: | Line 112: | ||
| Startup initialization is minimal because of DDS [[dido:public:ra:xapend:xapend.a_glossary:d:discovery]].\\ | Startup initialization is minimal because of DDS [[dido:public:ra:xapend:xapend.a_glossary:d:discovery]].\\ | ||
| - | //<color #FF0000><todo>TBD - May be added/expanded in future revisions of the DIDO RA</todo></color>// | + | |
| + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/20_maintainability/reuseability.1622857335.txt.gz · Last modified: 2021/06/04 21:42 by char
