Connascence
Connascence () is a software quality metric invented by Meilir Page-Jones to allow reasoning about the complexity caused by dependency relationships in object-oriented design much like coupling did for structured design. In software engineering, two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system. In addition to allowing categorization of dependency relationships, connascence also provides a system for comparing different types of dependency. Such comparisons between potential designs can often hint at ways to improve the quality of the software. Strength

A form of connascence is considered to be stronger if it is more
likely to require compensating changes in connascent elements. The
stronger the form of connascence, the more difficult and costly it
is to change the elements in the relationship. Degree

The acceptability of connascence is related to the degree of its
occurrence. Connascence might be acceptable in limited degree but
unacceptable in large degree. For example, a function or method that
takes two arguments is generally considered acceptable. However, it is
usually unacceptable for functions or methods to take ten arguments. Elements with a high degree of connascence incur greater difficulty, 
and cost, of change than elements that have a lower degree. Locality

Locality matters when analyzing connascence. Stronger forms of
connascence are acceptable if the elements involved are closely
related. For example, many languages use positional arguments when
calling functions or methods. This connascence of position is
acceptable due to the closeness of caller and callee. Passing arguments
to a web service positionally is unacceptable due to the relative
unrelatedness of the parties. The same strength and degree of
connascence will have a higher difficulty and cost of change, the
more distant the involved elements are. Types
This is a list of some types of connascence ordered approximately from weak to strong forms. Static connascences 
Connascenses are said to be "static" if they can be found by visually examining the code. Connascence of name (CoN)
Connascence of name is when multiple components must agree on the name of an entity. Method names are an example of this form of connascence: if the name of a method changes, callers of that method must be changed to use the new name. Connascence of type (CoT)
Connascence of type is when multiple components must agree on the type of an entity. In statically typed languages, the type of method arguments is an example of this form of connascence. If a method changes the type of its argument from an integer to a string, callers of that method must be changed to pass a different argument than before. Connascence of meaning (CoM) or connascence of convention (CoC)
Connascence of meaning is when multiple components must agree on the meaning of particular values. Returning integers 0 and 1 to represent false and true, respectively, is an example of this form of connascence. Connascence of position (CoP)
Connascence of position is when multiple components must agree on the order of values. Positional parameters in method calls are an example of this form of connascence. Both caller and callee must agree on the semantics of the first, second, etc. parameters. Connascence of algorithm (CoA)
Connascence of algorithm is when multiple components must agree on a particular algorithm. Message authentication codes are an example of this form of connascence. Both sides of the exchange must implement exactly the same hashing algorithm or the authentication will fail. Dynamic connascence

Connascenses are said to be "dynamic" if they can only be discovered at runtime. Connascence of execution (CoE)
Connascence of execution is when the order of execution of multiple components is important. Connascence of timing (CoT)
Connascence of timing is when the timing of the execution of multiple components is important. Connascence of values (CoV)
Connascence of values is when several values must change together. Connascence of identity (CoI)
Connascence of identity is when multiple components must reference the same entity. Reducing connascence

Reducing connascence will reduce the cost of change for a software
system. One way of reducing connascence is by transforming strong
forms of connascence into weaker forms. For example, a method that
takes several arguments could be changed to use named parameters. This would change the connascence from CoP to CoN. Reducing the degree and increasing locality of involved elements constitute other ways to
reduce connascence. References
  Grand Unified Theory of Software Design,  Jim Weirich
 Meilir Page-Jones, Comparing techniques by means of encapsulation and connascence, Communications of the ACM, Volume 35, Issue 9
 What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones, Dorset House Publishing,  
 Fundamentals of Object-Oriented Design in UML, Meilir Page-Jones, Addison-Wesley Pub Co; 
 Manuel Rivero; Aug 9, 2018; Connascence: A Look at Object-Oriented Design in Java

Software architecture