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/09 14:42] char |
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]] | ||
| - | |||
| - | <wrap hide>* **<color #FF0000><todo @char #char:2021-06-05>Please Review</todo></color>** </wrap> | ||
| ===== About ===== | ===== About ===== | ||
| 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 developed a 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}}. | + | )) 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-level | 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 that are not designed for reuse from general libraries or where reuse is conducted by an 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 that 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. | | ||
| Line 65: | Line 63: | ||
| ^ 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 | <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 | 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.| | + | ^ 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**. | | ||
| Line 72: | Line 70: | ||
| ^ 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 | Horizontal scope 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 that are dependent on the environment of the application to achieve 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 | | ||
| 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> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||