dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity
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:modularity [2021/06/01 17:35] char |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity [2021/08/11 13:01] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== 4.3.3.1 Modularity ====== | ====== 4.3.3.1 Modularity ====== | ||
| [[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:m:modularity]]** describes a characteristic of a system or program to be organized into smaller, reusable components. Each component is self-contained and provides an interface that describes the functionality it offers to other components of the system. It optionally provides a set of interfaces required to fulfill its functionality. In [[dido:public:ra:xapend:xapend.a_glossary:o:oop]], this functionality is encapsulated as set of data attributes. The [[dido:public:ra:xapend:xapend.a_glossary:m:module]] exposes access to these data attributes by defining public interfaces other components can call to manage and manipulate the data attributes of the object (i.e., Module). If the component relies on other components, then it can specify the required components (i.e., Modules). | + | **[[dido:public:ra:xapend:xapend.a_glossary:m:modularity]]** describes a characteristic of a system or program to be organized into smaller, reusable components. Each component is self-contained and provides an [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interface]] that describes the functionality it offers to other components of the system. It optionally provides a set of interfaces required to fulfill its functionality. In [[dido:public:ra:xapend:xapend.a_glossary:o:oop]], this functionality is encapsulated as set of data attributes. The [[dido:public:ra:xapend:xapend.a_glossary:m:module]] exposes access to these data attributes by defining public interfaces other components can call to manage and manipulate the data attributes of the [[dido:public:ra:xapend:xapend.a_glossary:o:object|object]] (i.e., Module). If the component relies on other components, then it can specify the required components (i.e., Modules). |
| - | Many Modules are described by files that only describe the interface to the Module and contain no actual functionality. For example, in C/C++, these Module interfaces are described using header files (i.e., ''.h'', ''.hpp'') files; in Java these files are regular ''.java'' files but contain the key word ''interface'' in their class descriptor; in [[dido:public:ra:xapend:xapend.a_glossary:c:corba]], interfaces are described as stubs. ECMAScript (i.e., JavaScript), PHP, etc. use the concept of [[dido:public:ra:xapend:xapend.a_glossary:d:ducktyping]] at runtime to accomplish the equivalent of interfaces (i.e., it is based on the methods defined within a Module at runtime rather than on a static, abstract fixed interface). | + | Many Modules are described by files that only describe the interface to the Module and contain no actual functionality. For example, in C/C++, these Module interfaces are described using header files (i.e., ''.h'', ''.hpp'') files; in Java these files are regular ''.java'' files but contain the key word ''interface'' in their [[dido:public:ra:xapend:xapend.a_glossary:c:class|class]] descriptor; in [[dido:public:ra:xapend:xapend.a_glossary:c:corba]], interfaces are described as stubs. ECMAScript (i.e., [[dido:public:ra:xapend:xapend.a_glossary:j:javascript|JavaScript]]), PHP, etc. use the concept of [[dido:public:ra:xapend:xapend.a_glossary:d:ducktyping]] at runtime to accomplish the equivalent of interfaces (i.e., it is based on the methods defined within a Module at runtime rather than on a static, abstract fixed interface). |
| <figure Modulemodle> | <figure Modulemodle> | ||
| Line 23: | Line 20: | ||
| 14 February 2019, Entropy, | 14 February 2019, Entropy, | ||
| Accessed 3 Aug 2020, [[https://www.mdpi.com/1099-4300/21/4/344/htm]] | Accessed 3 Aug 2020, [[https://www.mdpi.com/1099-4300/21/4/344/htm]] | ||
| - | )) introduced the use of complex network theory into software engineering with which to develop metrics for measuring Modularity. They analyzed existing software by representing it as a network using a feature coupling network (FCN). Each method and attribute is considered a node in the node network. Couplings between methods and attributes are considered edges. Edge Weight represents a weighted value based on the number of invocation paths for the node (i.e., method '''A''' is called 2 times, has a weight of '''2''', each attribute is used once, gets a weight of '''1'''). | + | )) introduced the use of complex network theory into software engineering with which to develop metrics for measuring Modularity. They analyzed existing software by representing it as a network using a feature coupling network (FCN). Each method and attribute is considered a node in the [[dido:public:ra:xapend:xapend.a_glossary:n:node_network|node network]]. Couplings between methods and attributes are considered edges. Edge Weight represents a weighted value based on the number of invocation paths for the [[dido:public:ra:xapend:xapend.a_glossary:n:node|node]] (i.e., method '''A''' is called 2 times, has a weight of '''2''', each attribute is used once, gets a weight of '''1'''). |
| : ''FCN = ( N, E, Ψ )'' | : ''FCN = ( N, E, Ψ )'' | ||
| Line 38: | Line 35: | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity| Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity| Return to Top]] | ||
| - | Although Modularity was primarily developed to look at software, it can also be applied to distributed systems by changing the definition of '''N''' from the number of attributes or methods to the number of [[dido:public:ra:xapend:xapend.a_glossary:p:publish-subscribe | Publishers and Subscribers]], and '''E''' to the number of couplings between the publishers and subscribers. '''Ψ''' would then be a weighting for the volume of couplings between publishers and subscribers. | + | Although Modularity was primarily developed to look at software, it can also be applied to [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed systems]] by changing the definition of ''N'' from the number of attributes or methods to the number of [[dido:public:ra:xapend:xapend.a_glossary:p:publish-subscribe | Publishers and Subscribers]], and ''E'' to the number of couplings between the publishers and subscribers. ''Ψ'' would then be a weighting for the volume of couplings between publishers and subscribers. |
| - | In practice this means that centralizing functionality into a normalized set of [[dido:public:ra:xapend:xapend.a_glossary:e:endpoint | Endpoints]], that couplings are the connections between the endpoints and the volume of traffic represents a weighting, then we are reduced to three variables: ''N, E'' and ''Ψ''. This comes down to the age old question: is it better to have one command with 100 options, 100 commands with no options or a set of commands that can share a restricted set of options. Its obvious that the first two choices are unacceptable. The key comes down to the last option where the options are all related based on the functionality of the command. | + | In practice this means that if functionality is centralized into a normalized set of [[dido:public:ra:xapend:xapend.a_glossary:e:endpoint | Endpoints]] such that couplings become the connections between endpoints and the volume of traffic represents a weighting, the end result is that we are reduced to three variables: ''N'', ''E'' and ''Ψ''. Thus, we must address the age old question: is it better to have one command with 100 options, 100 commands with no options, or a set of commands that can share a restricted set of options? It's obvious that the first two choices are unacceptable so we are left with with the last choice where the options are all related based on the functionality of the command. |
dido/public/ra/1.4_req/2_nonfunc/20_maintainability/modularity.1622583323.txt.gz · Last modified: 2021/06/01 17:35 by char
