Differences

This shows you the differences between two versions of the page.

--- dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity [2020/11/14 18:35]
nick
+++ dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity [2021/08/11 13:01] (current)
murphy
@@ Line 1: / Line 1: @@
-====== 4.2.3.1 Modularity ======
+====== 4.3.3.1 Modularity ======
 [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability| Return to Maintainability]]
-  * **<color #FF0000><todo @char>Please Review</todo></color>**
 ===== About =====
-[[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity| Return to Top]]
+**[[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).
-**[[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 providing an interface that describes the functionality it offers to other components of the system. It optionally provides of a set of interfaces it requires in order to fulfill its functionality. In Object Orient programming, the functionality is encapsulated as set of data attributes. The [[dido:public:ra:xapend:xapend.a_glossary:m:module]] exposes access to the data attributes by defining public interfaces that 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).
-Many Modules are described by files that only describe the interface to the Module and contains no actual functionality. For example, in C/C++, these Module interfaces are described using header files (i.e., ''.h'', ''.hpp'') files; in Java the file is a regular ''.java'' file but contains the key word ''interface'' in the class descriptor; in [[dido:public:ra:xapend:xapend.a_glossary:c:corba]], interfaces are described as stubs. ECMAScript (i.e., JavaScript), PHP, etc. uses 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>
 {{  :dido:public:ra:1.4_req:2_nonfunc:20_maintainability:module_model.png?400  |}}
-<caption>Modeling Modules Provided and Required Interfaces.</caption>
+<caption>Modeling Modules with Provided and Required Interfaces.</caption>
 </figure>
-Regardless of kind of implementation (i.e., interface, stubs, DuckTyping, etc.), APIs need to be public, formalized and freely available to the general public at no cost. The benefit of using interfaces, stubs, or headers is that un-implemented or mismatched functionality can be checked at compile or link time. Dynamic [[dido:public:ra:xapend:xapend.a_glossary:p:plug_in]] interfaces (i.e, DuckTyping) can only be checked at runtime. However, dynamic type is very definitely modular. One way around the run-time error is to always provide a default implementation.
+Regardless of the kind of implementation (i.e., interface, stubs, DuckTyping, etc.), APIs need to be public, formalized and freely available to the general public at no cost. The benefit of using interfaces, stubs, or headers is that un-implemented or mismatched functionality can be checked at compile or link time. Dynamic [[dido:public:ra:xapend:xapend.a_glossary:p:plug_in]] interfaces (i.e, DuckTyping) can only be checked at runtime. However, dynamic type is very definitely modular. One way around run-time errors is to always provide a default implementation.
-The use of Modules allows for the architecture and design of a system or program to be re-factored by extracting functionality into new Modules, combining Modules into a new Module, or composing Modules from other Modules. Often the rules for refactoring a system of a program follow many of the same rules as data [[dido:public:ra:xapend:xapend.a_glossary:n:normalization]].
+The use of Modules allows the architecture and design of a system or program to be re-factored by extracting functionality into new Modules, combining Modules into a new Module, or composing Modules from other Modules. Often the rules for refactoring a system of a program follow many of the same rules as data [[dido:public:ra:xapend:xapend.a_glossary:n:normalization]].
 Yiming et al.(( Yiming Xiang, Weifeng Pan, Haibo Jiang, Yunfang Zhu, Hao Li,
@@ Line 25: / Line 20: @@
 February 2019, Entropy,
 Accessed 3 Aug 2020, [[https://www.mdpi.com/1099-4300/21/4/344/htm]]
-)) introduce complex network theory into software engineering to develop a metric for measuring Modularity. They analyze existing software by representing it as a network using feature coupling network (FCN). Each method and attribute are 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, is a weight of '''2''', 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, Ψ )''
@@ Line 35: / Line 30: @@
     * ''Ψ'' : the Edge Weight (number of invocation paths)
-Yiming et al., apply the Weyuker’s criteria which is widely used in the field of software metrics, to validate the modularity as a software metric theoretically, and also perform an empirical evaluation using open-source Java software systems to show its effectiveness as a software metric to measure software modularity.
+Yiming et al., apply Weyuker’s criteria, which are widely used in the field of software metrics, to validate modularity as a software metric theoretically, and also to perform an empirical evaluation using open-source Java software systems to show its effectiveness as a software metric to measure software modularity.
-===== DDS Specifics =====
+===== DIDO Specifics =====
 [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity| Return to Top]]
-Although the 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 attribute or methods to the number of [[dido:public:ra:xapend:xapend.a_glossary:p:publish-subscribe | Publishers and Subscribers]] , and the '''E''' to the number of couplings between the publishers and subscribers. '''Ψ''' would be a weighting for the volume of couplings between the 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:xapend:xapend.a_glossary:d:data_distribution_service_dds]] is about [[dido:public:ra:xapend:xapend.a_glossary:p:publisher | Publishers]] and subscribing data. The publishers and subscribers represent the Node Set, the Edge Set is represented by the Topics and the edge weight represents the volume of traffic.  The same question needs to be asked. Is it best to have one messages with a 100 attributes in the data structure, or 100 messages with no data attributes? Obviously the answer is somewhere between where each message is built around a data structure that is formulated on functionality.
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

DIDO Wiki

User Tools

Site Tools

Differences

Page Tools