You get a bonus - 1 coin for daily activity. Now you have 1 coin

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

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.

  • 1Types of connectivity
    • 1.1Procedure programming
    • 1.2 Object-Oriented Programming
  • 2 Disadvantages
  • 3 Performance issues
  • 4 Problem Solving
  • 5connectivity and connectedness
  • 6 connectivity of modules
  • 7 See also
  • 8 Footnotes

Types of connectivity

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

Conceptual connectivity model

Connectivity can be "weak" (or "low") or "strong" ("high"). Consider some types of connectivity in order from highest to lowest:

Procedural programming

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.

Object oriented programming

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]

disadvantages

Strongly connected systems typically exhibit the following design characteristics, which are often considered weaknesses:

  1. Changing one module usually causes a wave of changes in other modules.
  2. Collecting modules in a heap and docking will require more effort and time, due to the increase in inter-module dependencies
  3. A specific module will be harder to reuse and / or test, because you need to enable dependent modules.

Performance issues

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.

Solutions to problems

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

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.

Module connectivity

In the book "Software Engineering" connectivity describes a variant of the metric associated with this term.

For data connectivity and control flow:

  • d and : the number of input data parameters
  • c and : the number of input control parameters
  • d o : the number of output data parameters
  • c o : number of output control parameters

For global connectivity:

  • g d : number of global variables used as data
  • g c : number of global variables used for control

For media connectivity:

  • w : number of modules called (fan-out)
  • r : the number of modules calling the module which is considered (fan-in)

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

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:

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

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.

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

Connectedness

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.

Connectedness

  • 1 weak connectivity
  • 2 Types of connectedness
  • 3 See also
  • 4Sources
  • 5Link

Loose coupling

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 functionality built into the class methods has little in common.
  • Methods perform many different functions, often over over roughly granular or unrelated data sets.

The disadvantages of low (weak) connectivity are:

  • Complications of understanding modules.
  • Complications of module reuse, since most programs require a random set of operations provided by the module.

Types of connectedness

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.

Types of gearing

Gearing (dependency) and Connectivity in Object Oriented Programming (OOP)

Module connectivity and hooking

The types of gearing according to ISO / IEC / IEEE 24765-2010 include:

  • gearing on the common area (eng. common-environment coupling, common coupling );
  • engagement by content (eng. content coupling );
  • control gearing (English control coupling );
  • data engagement ( data coupling, input-output coupling );
  • mixed gearing (born hybrid coupling );
  • pathological coupling (English pathological coupling ) [2] .

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.

Methods to reduce gearing

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.

see also

  • GRASP
  • Demeter's Law


Comments

Andrew
06-02-2022
везде пишут наоборот:- связанность - взаимосвязь между модулями.- связность - целостность, "плотность" модуля.https://ru.wikipedia.org/wiki/Связность_(программирование)https://ru.wikipedia.org/wiki/Зацепление_(программирование)http://structuralist.narod.ru/dictionary/couplingandcohesion.htmhttps://dic.academic.ru/dic.nsf/ruwiki/680879

To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Object oriented programming

Terms: Object oriented programming