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/08/09 12:45] murphy |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity [2021/08/11 13:01] (current) murphy |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== 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 [[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 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 [[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). | 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). | ||
| Line 20: | 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, Ψ )'' | ||
dido/public/ra/1.4_req/2_nonfunc/20_maintainability/modularity.1628527530.txt.gz · Last modified: 2021/08/09 12:45 by murphy
