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/09 14:45] char |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability [2021/10/30 15:01] (current) nick |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| [[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 ===== | ||
| [[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. | [[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. | ||
| Line 33: | 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 39: | 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 57: | 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 64: | 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 71: | 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 113: | 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.1623264329.txt.gz · Last modified: 2021/06/09 14:45 by char
