Lecture
Connectivity (English Coupling ) or dependence (English Dependency ) is a measure in which the module (component) of the program depends on each other module (uses some information about it).
Connectivity is usually contrasted with connectedness. Software metrics connectivity and connectivity, invented by Larry Constantin, the first developer of Structured Design, [1] who was also their first proponent (see also SSADM). Weak connectivity is often a sign of a well-structured computer system, and a good architecture, and in combination with high coherence, it can achieve good readability and code quality.
Conceptual connectivity model
Connectivity can be "weak" (or "low") or "strong" ("high"). Consider some types of connectivity in order from highest to lowest:
Connected content (strong)
Appears when one module modifies or depends on the internal content of another module (for example, uses its variables).
Therefore, changing the way in which the second module processes the data will require changing the dependent module.
Data connectivity
When two modules have common global data (global variables).
Changing a shared resource involves changing all the modules that use it.
external connectivity
Appears when two modules share an externally imposed data format, communication protocol, or device interface. This is usually due to interaction with external instruments or equipment.
control connectivity
Appears when one module controls the progress of the other, passing information about what to do.
Dependence-stamp (dependence on structured data)
when modules have a common complex data structure, and use only parts of it, possibly different (for example, a function is transferred to the record, although it only requires a part of it).
data connectivity
Data connectivity occurs when modules share common data through, for example, parameters. Each given is elementary, and the only one which is divided (for example, the transfer of the number of a function is a calculated square root).
Connectivity for messages (weak)
Weak type of connectivity. Achieved through state decentralization (in objects). The interaction of components is done through parameters and message exchange.
missing
Modules do not interact at all.
subclass connectivity
Describes the relationship between ancestor and descendant. The descendant is tied to the ancestor, but the ancestor is not.
temporal connectivity
When two actions are packed into one module only because they can occur simultaneously.
In recent labor, other connectivity concepts have been studied and used as indications of various modularity principles used in practice. [2]
Strongly connected systems typically exhibit the following design characteristics, which are often considered weaknesses:
Regardless of the strength of connectivity, system performance is reduced through the creation of messages and parameters, their transmission, translation and interpretation. See event-oriented programming.
Post creation costs
Creation of any message requires additional costs for the processor and memory. Creating an integer message (which can be a string, array, or other data structure) is less expensive than creating a complex message such as in SOAP. For optimization, you need to reduce the length of the message and increase the degree of content that is embedded in it.
Messaging costs
Since to receive the content, the message must be transmitted completely, it must be optimized. In short, messages are sent and received faster.
The cost of broadcasting messages
Protocols of messages, and they often contain redundant information (for example, a description of the package and its structure). Therefore, the recipient often requires converting the message into a simple form, removing additional symbols of the structure information and / or converting the type of values to the desired one. To optimize the translation processes, the message is again to be as short as possible, for as much content as possible.
Message Interpretation Costs
All messages are interpreted by the receiver. Simple messages, such as targets, may not require additional processing. However, complex messages, such as SOAP, require a parser and string conversion to play the content.
One approach to reducing connectivity is functional design, which attempts to limit the modules' responsibility for functionality.
Weak connectivity arises when one module interacts with another through a simple and stable interface and does not care how the other module is implemented. (see: Encapsulation).
Systems like CORBA or COM allow objects to communicate with each other without the need to know anything about each other’s implementations. Both systems even allow interaction between objects written in different languages.
Connectivity and connectedness are two terms that are very often used together. They describe the qualities that modules should have. Connectivity characterizes the relationship between modules, and connectedness describes the relationship of functions within a module. Low connectivity causes a situation where a module performs various unrelated tasks, and begins to create problems when a module becomes large.
In the book "Software Engineering" connectivity describes a variant of the metric associated with this term.
For data connectivity and control flow:
For global connectivity:
For media connectivity:
Coupling (C) is the more important, the more connected is the module. This number ranges from about 0.67 (weak connectivity) to 1.0 (strong connectivity)
For example, if a module has only one input and one output parameters:
If the module has 5 input and output parameters, the same number of control parameters, and uses 10 global variables, calls 3 modules, and calls four.
Connectivity (eng. Cohesion ) in programming is a measure of how closely related code is in one module of a program (for example, through common semantics). Methods for assessing coherence vary from qualitative evaluations of a program text using headings with a hermeneutic approach to quantitative measurements of the degree of coherence of a program code. Connectedness is an ordinal value, and is usually expressed in conversation as "high connectedness" or "low connectedness". Highly connected modules are preferred because high connectivity is associated with several desirable software features, including fault tolerance, reliability, reusability, and comprehensibility, while low connectivity is associated with undesirable features such as difficulty supporting, testing, reuse and understanding.
Connectivity is often contrasted to connectivity - a different concept, but high connectivity often correlates with weak connectivity. Software metrics such as connectivity and connectivity are invented by Larry Constantin [1] and are based on the characteristics of "good" programming practices that reduce the cost of modification and support.
In OOP, if the methods of a certain class are usually similar in many aspects, then the class is considered to be highly connected.
Connectivity decreases if:
The disadvantages of low (weak) connectivity are:
Connectivity is a qualitative measure, that is, the program text is examined by rubrics to classify relatedness. Types of connectedness in order from worst to best:
Accidental connectedness (worst)
Random coherence occurs when parts of a module are added to it arbitrarily; the only thing that binds them is that they belong to the same module (for example, the "Utilities" class).
logical connectivity
parts of a module are grouped together because they logically perform the same function, even if they are different in nature. For example, grouping all keyboard and mouse input routines.
temporal relatedness
parts of the module are grouped depending on at what point in time the need for their use arises. For example, functions called upon detection of an error, which close open files, write an error to the log, and inform the user.
procedural connectedness
parts of the module are grouped because they all follow a specific sequence of actions. For example, functions that check permissions for a file, and then open it.
communication connectivity
parts of the module are grouped because they work with the same data.
sequential connectedness
parts of the module are grouped in that the output of one part is transmitted to the input of another, as in a conveyor. For example, functions that read data from a file, process them and write back.
Functional Connectivity (Best)
parts of a module are grouped together that they work together on other, clearly defined tasks for that module. For example, lexical analysis of text or XML.
Studies by many people, such as Larry Konstantin, Edward Yourdon, and Steve McConnell [2] show that the first two types of connectivity are bad, communication and consistent connectivity are good enough and functional is the best, although not always achievable. There are cases when communication connectivity is the best that can be achieved under the circumstances.
Module connectivity and hooking
The types of gearing according to ISO / IEC / IEEE 24765-2010 include:
Gearing on the general area
A type of link in which two software modules share a common data area.
Linked by content
A type of gearing in which some or all of the software modules are included in a module as integral parts.
Control gearing
A type of link in which one software module communicates with another module with the explicit goal of affecting its subsequent execution.
Gearing by data
A type of engagement in which the output of one software module serves as input to another module.
Mixed gear
A type of link in which different subsets of the values of a data element are used in several software modules for different and unrelated purposes.
Pathological engagement
Type of gearing in which one software module depends on or affects the details of the internal implementation of another module.
There are various methods to reduce gearing (English decoupling ). As a rule, they are described in the form of design patterns. One of the key methods is inversion of control, and, in particular, dependency injection.
The use of a multi-layer application architecture, for example, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel, etc., also helps to reduce engagement.
Comments
To leave a comment
Object oriented programming
Terms: Object oriented programming