Merge pull request #12 from ucudal/feature/concepts

Added coupling, cohesion and connascence

4_Conceptos/4_Acoplamiento.md

@@ -0,0 +1,53 @@
+# Conceptos
+
+## Acoplamiento
+
+El acoplamiento es una de las formas con las que se mide la modularidad en
+ingeniería de software —las otras son la [cohesión](./4_Cohesion.md) y la
+[co-nascencia o *connascence*](./4_Connascence.md)—. Refiere a la conexión
+entre partes de diferentes módulos o entre diferentes módulos, y puede ser
+aferente —hacia adentro— o eferente —hacia afuera—[^1]:
+
+* El acoplamiento aferente mide el número de conexiones entrantes a una parte de
+un módulo.
+
+* El acoplamiento eferente mide las conexiones salientes con otras partes en
+  otros módulos.
+
+Además de los módulos y sus partes es importante la conexión entre las partes de
+diferentes módulos y la conexión entre los diferentes módulos; cuando las partes
+de diferentes módulos están conectadas, los módulos de esas partes también están
+conectados, aunque el tipo de conexión puede ser diferente; veamos algunos
+ejemplos:
+
+* Cuando una clase en un espacio de nombres en C# declara una propiedad, un
+  parámetro, una variable local, o el resultado de un método de un tipo definido
+  en otro espacio de nombres, es necesario incluir la cláusula `using` para
+  referenciar este último espacio de nombres; es decir, un espacio de nombres
+  **usa** tipos del otro[^2]. El espacio de nombres que usa tipos del otro tiene
+  un acoplamiento eferente con el espacio de nombres usado; y éste último un
+  acoplamiento aferente con el primero.
+
+* En ese mismo ejemplo, si la primera de esas clases está en un ensamblado y la
+  segunda está en otro ensamblado, es necesario agregar una **referencia** en la
+  definición del proyecto donde se declara la primera clase al ensamblado donde
+  está la segunda clase. El ensamblado referenciado tiene un acoplamiento
+  eferente con el ensamblado donde se lo referencia; y este último tiene un
+  acoplamiento aferente con el primero.
+
+El acoplamiento es menos discrecional que la cohesión, las conexiones salientes
+y entrantes están bien determinadas.
+
+Continuando con los ejemplos anteriores, un ensamblado en C# está altamente
+acoplado si referencia a varios otros ensamblados; esto puede ser un problema
+porque si hay cambios en los tipos de los otros ensamblados, por ejemplo porque
+cambian firmas de métodos o nombres de clases, hay grandes chances de tener que
+modificar el primero; cuando desplegamos una nueva versión de los otros
+ensamblados, hay grandes chances de tener que desplegar una nueva versión del
+primero.
+
+[^1]: Yourdon, E. & Constantine, L. (1979). Structured Design: Fundamentals of a
+    Discipline of Computer Program and Systems Design. Prentice-Hall.
+[^2]: Es posible evitar esto usando el calificador completo del tipo de datos;
+    esto simplifica la escritura de código pero no elimina la conexión —la
+    dependencia— entre las clases de los diferentes espacios de nombres.

4_Conceptos/4_Cohesion.md

@@ -0,0 +1,58 @@
+# Conceptos
+
+## Cohesión
+
+La cohesión es una de las formas con las que se mide la modularidad en
+ingeniería de software —las otras son el [acoplamiento](./4_Acoplamiento.md) y
+la [co-nascencia o *connascence*](./4_Connascence.md)—. Refiere a hasta qué
+punto las partes de un módulo deben estar contenidas dentro del mismo módulo. En
+otras palabras, es una medida de qué tan relacionadas están las partes entre
+sí[^1].
+
+Qué es un módulo y cuáles son sus partes depende del contexto, veamos algunos
+ejemplos —la lista no es exhaustiva—:
+
+* En el contexto del despliegue —*deployment*— un módulo puede ser un ensamblado
+  —*assembly*— de C# y sus partes pueden ser los tipos de datos definidos en ese
+  ensamblado.
+
+* En el contexto de la definición de tipos un módulo puede ser un espacio de
+  nombres —*namespace*— de C# y sus partes también pueden ser los tipos de datos
+  definidos en ese espacio de nombres.
+
+* En el contexto de un lenguaje de programación orientado a objetos un módulo
+  puede ser la clase y sus partes pueden ser los atributos de esa clase y los
+  métodos de esa clase.
+
+* En el contexto de la programación estructurada un módulo puede ser una función
+  o un procedimiento y sus partes la lógica que implementan.
+
+Además de los módulos y sus partes es importante la conexión entre las partes de
+diferentes módulos y la conexión entre los diferentes módulos; mira el concepto
+de [acoplamiento](./4_Acoplamiento.md).
+
+Cohesión y acoplamiento van de la mano, es decir, cuando aumenta la cohesión
+también tiende a aumentar el acoplamiento, y cuando disminuye la cohesión
+también tiende a disminuir el acoplamiento. El problema es que es bueno para la
+modularidad que la cohesión sea alta, pero también que al mismo tiempo el
+acoplamiento sea bajo. Lo mismo aplica para cohesión y co-nascencia.
+
+Idealmente, un módulo cohesivo es aquel en el que todas las partes deben estar
+juntas, porque dividirlas en partes más pequeñas —o separarlas en diferentes
+módulos— requeriría acoplar las partes —crear nuevas conexiones entre módulos—
+para lograr un resultado equivalente.
+
+Cabe reconocer que la cohesión es muchas veces discrecional, es decir, queda a
+criterio del arquitecto la mejor forma de distribuir las partes entre diferentes
+módulos.
+
+Continuando con los ejemplos anteriores, un ensamblado en C# es altamente
+cohesivo si los tipos que están definidos en él esta bien que estén todos
+juntos, por ejemplo, porque cuando desplegamos o cuando usamos uno de esos tipos
+hay grandes chances de desplegar o de usar otros tipos del mismo ensamblado: si
+hay nuevas versiones de uno de los tipos es muy probable que haya también nuevas
+versiones de los demás tipos del ensamblado; o si usamos uno de los tipos del
+ensamblado es muy probable que tengamos que usar otros tipos del mismo
+ensamblado.
+
+[^1]: Richards, M. (2020). Fundamentals of Software Architecture. O'Reilly.

4_Conceptos/4_Connascence.md

@@ -0,0 +1,73 @@
+# Conceptos
+
+## Co-nascencia o _connascence_
+
+> [!NOTE]
+> El término [nascencia](https://dle.rae.es/nascencia?m=form) se define como la
+> acción y efecto de nacer. Por lo tanto, co-nascencia sería algo así como la
+> acción y efecto de nacer al mismo tiempo. Sin embargo, este término no es muy
+> común en español y en algunos casos se prefiere simplemente usar el término en
+> inglés _connascence_.
+
+La co-nascencia es una de las formas con las que se mide la modularidad en
+ingeniería de software —las otras son el [acoplamiento](./4_Acoplamiento.md) y
+la [cohesión](./4_Cohesion.md)—. Refiere a que dos partes son co-nascentes si
+un cambio en una de ellas requiere modificar la otra para mantener la
+corrección general del sistema[^1]. La co-nascencia refina los conceptos de
+[acoplamiento](./4_Acoplamiento.md) eferente y aferente para los lenguajes de
+programación orientada a objetos[^2].
+
+Existen dos tipos de co-nascencia:
+
+* Estática. Refiere al acoplamiento en tiempo de compilación, opuesto al
+  acoplamiento en tiempo de ejecución cubierto en la co-nascencia dinámica.
+  Puede ser:
+
+  * De nombres. Múltiples partes deben ponerse de acuerdo en el nombre de una
+    entidad, por ejemplo, un identificador. Consideren el _refactoring_ que
+    tienen varios IDE de renombrar identificadores, para que lidiar con este
+    tipo de acoplamiento sea trivial.
+
+  * De tipos. Múltiples partes deben ponerse de acuerdo en el tipo de una
+    propiedad, un parámetro, una variable local, o del resultado de un método.
+
+  * De significado o de convención. Múltiples partes deben ponerse de acuerdo en
+    la semántica de ciertos valores. Por ejemplo, que `true` es `1` y que `false`
+    es `0` o que el primer elemento de un vector es `0` o es `1`.
+
+  * De posición. Múltiples partes deben ponerse de acuerdo en el orden de los
+    valores. Por ejemplo, en el orden de los parámetros del mismo tipo en la
+    firma de un método y en la invocación de ese método.
+
+  * De algoritmos. Múltiples partes deben ponerse de acuerdo en el algoritmo
+    utilizado. Por ejemplo, la función [`LOOKUP`](https://support.microsoft.com/en-us/office/lookup-function-446d94af-663b-451d-8251-369d5e3864cb)
+    de Excel, que busca un elemento en un vector, requiere que el vector esté
+    en orden ascendente; probablemente use internamente un algoritmo de
+    [búsqueda binaria](https://en.wikipedia.org/wiki/Binary_search_algorithm).
+
+* Dinámica. Refiere al acoplamiento en tiempo de ejecución. Puede ser:
+
+  * De orden de ejecución. El orden en que se ejecutan diferentes partes es
+    importante. Por ejemplo, cuando en un
+    [ORM](https://en.wikipedia.org/wiki/Object–relational_mapping), debo asignar
+    todas las propiedades de un nuevo objeto, antes de persistirlo en la base de
+    datos.
+
+  * De tiempo. El momento de la ejecución de múltiples partes es importantes.
+    Por ejemplo, una [condición de carrera](https://en.wikipedia.org/wiki/Race_condition).
+
+  * De valores. Cuando varios valores están relacionados entre sí y deben
+    cambiar simultáneamente. Por ejemplo, las transacciones en una base de
+    datos, permiten lidiar con este tipo de acoplamiento.
+
+  * De identidad. Cuando varias partes deben referenciar a la misma entidad. Por
+    ejemplo, una clave primaria en una base de datos.
+
+La co-nascencia dinámica es más difícil de determinar que la estática,
+típicamente por la falta de herramientas que permitan analizar el comportamiento
+dinámico de un sistema, a diferencia de las herramientas de análisis estático de
+código.
+
+[^1]: Page-Jones, M. (1996). What Every Programmer Should Know About
+    Object-Oriented Design. Dorset House.
+[^2]: Richards, M. (2020). Fundamentals of Software Architecture. O'Reilly.

4_Conceptos/4__Conceptos.md

@@ -1,7 +1,13 @@
 # 4 Conceptos
 
+## [Acoplamiento](./4_Acoplamiento.md)
+
 ## [Caso de uso del negocio](./4_Caso_de_uso_del_negocio.md)
 
 ## [Caso de uso del producto](./4_Caso_de_uso_del_producto.md)
 
+## [Co-nascencia o *connascence*](./4_Connascence.md)
+
+## [Cohesión](./4_Cohesion.md)
+
 ## [Evento de negocio](./4_Evento_de_negocio.md)