Este documento analiza los conceptos de modularidad en la construcción de software orientado a objetos según el libro "Object-Oriented Software Construction" de Bertrand Meyer. Explica que la modularidad implica criterios como la descomposición, composición, comprensibilidad y protección; reglas como interfaces pequeñas y explícitas; y principios como unidades modulares lingüísticas y acceso uniforme. El objetivo es desarrollar software que mantenga su integridad estructural a pesar de cambios futuros.

1. Universidad Distrital Francisco José de Caldas, Hermosa Martin, Construcción orientada a objetos modularidad.
Abstract—This document is an analysis of the
third chapter of the book "Object-Oriented Software
Construction" by French writer residing in
California, USA. Bertramd Meyer.
The construction of software contains among its
features modularity which consists of a set of
criteria, rules and principles to create software that
is understandable for its user as for other
programmers taking into account this set of
activities makes maintenance and modifications to
Software is performed correctly without affecting
the synergy that it must maintain.
Resumen—Este documento es un análisis sobre el
tercer capítulo del libro “Object-Oriented Software
Construction”1
del escritor francés residente en
california, USA. Bertramd Meyer.
La construcción de software contiene entre sus
características la modularidad la cual consiste en un
conjunto de criterios, reglas y principios para crear
un software que sea entendible para su usuario
como para otros programadores teniendo en cuenta
este conjunto de actividades hace que el
mantenimiento y modificaciones a un software se
realicen correctamente sin afectar la sinergia que
este debe mantener
Palabras Clave—Programación, Orientada a
objetos, módulos, criterios, reglas, principios,
software, descomposición, composición,
comprensibilidad, continuidad, protección,
modularidad, correspondencia directa, pocas
interfaces, pequeñas interfaces, interfaces explicitas,

1
https://sophia.javeriana.edu.co/~cbustaca/docencia/POO-2016-
01/documentos/Object%20Oriented%20Software%20Construction-Meyer.pdf
ocultación de la información, estructuras, unidades
modulares lingüísticas, auto-documentación, acceso
uniforme, abierto – cerrado, elección única,
I.INTRODUCCIÓN
En este documento se intentará dar explicación al
tema de modularidad el cual se desprende los
criterios, reglas y principios que deberían regir cada
software creado en el paradigma de programación a
objetos y extendido a algunos otros paradigmas de
programación.
II. CINCO CRITERIOS
El método de criterios se ha ganado el carácter de
modular atreves de la historia estos deben cumplir
cinco requisitos fundamentales: Descomposición,
composición, comprensibilidad, continuidad,
protección.
(fig1. Descomposición.)
La descomposición modular (fig1.) es aquella en
la que se descompone un problema de software en
varios subsistemas los cuales son más sencillos de
abordar que todo el sistema en sí. Como requisito es
que los subsistemas estén relacionados y numerados
para poderlos integrar posteriormente haciendo que
la solución de cada subsistema solucione un todo
original. La mayoría de veces se suele graficar en
Construcción de Software Orientada a Objetos
MODULARIDAD
Hermosa Martín, Juan David
juan_music1020@hotmail.com
Universidad Distrital Francisco José de Caldas
1

2. Universidad Distrital Francisco José de Caldas, Hermosa Martin, Construcción orientada a objetos modularidad.
forma de árbol. (fig2.) aunque un contraejemplo
típico es aquel en que varias variables se inicializan
al mismo tiempo realizando procesos como crear
archivos o inicializar variables haciendo que estos
procesos se desarrollen antes de la ejecución
primordial del software.
(fig2. Una Jerarquía Descendente.)
La composición modular consta en que los
elementos conforman sistemas con otros elementos
distintos a su función original o de su sistema
original. (fig3.) Es muy utilizado cuando hay un
banco de datos con el cual se pueden referenciar a
distintos sistemas además de su sistema original.
(fig3. Composición.)
La comprensibilidad modular es la capacidad que
tienen los sistemas de ser entendidos en su
completitud por separado del sistema general
logrando así un entendimiento del todo como un
software completo. (fig4.)
(fig4. Comprensibilidad.)
La continuidad modular modifica o cambia
algunos o un módulo intentando mantener una
continuidad del software en general algo parecido a
una continuidad matemática en la que sus partes la
homogeneidad del todo. (fig5.)
(fig5. Continuidad.)
La protección modular consta de que los procesos
realizados en un módulo solo sean de conocimiento
de este y de algunos módulos cercanos algo muy
similar que en el principio del egoísmo con el fin de
limitar la propagación y reduciendo en consumo de
memoria. (fig6.)
(fig6. Descomposición.)
III. CINCO REGLAS
De los cinco criterios anteriormente mencionados
se desprenden estas cinco reglas que se deben seguir
para garantizar la modularidad; correspondencia
directa, pocas interfaces, pequeñas interfaces,
interfaces explicitas, ocultación de la información.
La correspondencia directa se deriva de los
criterios de continuidad y descomposición, esta
debe cumplir con que la estructura modular
obtenida del proceso de descomposición del
software debe ser entendido en su totalidad para que
genere y mantenga una continuidad con los demás
módulos del sistema.
2

3. Universidad Distrital Francisco José de Caldas, Hermosa Martin, Construcción orientada a objetos modularidad.
La regla de pocas interfaces dice que cada módulo
debe comunicarse con el menor número de módulos
posible. Diciendo que un sistema se descompone en
n módulos entonces el número de conexiones
debería estar lo más cerca posible de n-1 (fig7.), que
el máximo n(n-1) /2 (fig8.) en el caso de la figura 7
(fig.7) es centralizada pero también existen
estructuras igualitarias (fig9.)
(fig7. Tipos de Estructuras de Interconexión entre
Módulos A)
(fig8. Tipos de Estructuras de Interconexión entre
Módulos B.)
(fig9. Tipos de Estructuras de Interconexión entre
Módulos C.)
La regla de pequeñas interfaces también llamada
acoplamiento débil se refiere al tamaño de las
conexiones que deben tener los módulos de la
estructura(fig10.)
(fig10. Ancho de la banda de comunicaciones
entre módulos.)
La regla de interfaces explicitas como su nombre
lo indica debe quedar claro de que va a pasar con el
dato ingresado o perteneciente a un módulo (fig11.)
(fig11. Compartir Datos.)
La regla de ocultación de información consta en
que no todos los datos de un módulo son visibles
para el usuario u otros módulos se suele comparar
con un iceberg (fig12.) donde solo es visible una
pequeña parte de la información.
(fig12. Módulo bajo la Ocultación de
Información.)
IV. CINCO PRINCIPIOS
Como las reglas que surgen de los criterios los
principios surgen a su vez de las reglas para la
construcción de software; estos principios son;
unidades modulares lingüísticas, auto-
3

4. Universidad Distrital Francisco José de Caldas, Hermosa Martin, Construcción orientada a objetos modularidad.
documentación, acceso uniforme, abierto – cerrado,
elección única.
El principio de unidades modulares lingüísticas
consta de que cada modula pueda ser independiente
pudiéndose compilar por separado sin afectar la
estructura del software, este debe estar
sintácticamente delimitado desde su alcance de
información hasta su composición conjunta en el
software final.
Este principio tiene como base conceptos
anteriormente explicados como lo son: la
continuidad, la correspondencia directa, la
composición, y la protección.
El principio de auto-documentación rige como se
deben documentar los módulos en el cual debe
poseer absolutamente toda su estructura y sus
respectivas operaciones con los datos del software.
El principio de acceso uniforme funciona en el
sentido de que cada módulo conoce su información
y puede conocer la información o resultado de los
módulos más cercanos (fig13.). sin importar si es
resultado de un cálculo o de un almacenamiento.
(fig13. Representación de una cuenta bancaria.)
El principio de elección única en la construcción
de un software específica a un solo elemento en
toda la estructura y su única ruta de acceso.
El principio de abierto y cerrado es aquel en el
que un software debe estar abierto para ampliar el
programa, agregarle extensiones y cerrado para la
edición y modificación de un código ya existente.
V. CONCLUSIONES
La modularidad es el conjunto de los criterios
(descomposición, composición, comprensibilidad,
continuidad, protección), reglas (correspondencia
directa, pocas interfaces, pequeñas interfaces,
interfaces explicitas, ocultación de la información.)
y principios (unidades modulares lingüísticas, auto-
documentación, acceso uniforme, abierto – cerrado,
elección única) que se necesitan para poder
desarrollar un software con la capacidad de
mantener su integridad estructural con el paso del
tiempo teniendo en cuenta posibles requerimientos
nuevos o creación de nuevas secciones en este.
REFERENCIAS
[1] Bertrand Meyer, “object oriented software construction)
2nd ed. Pretice hall
[2] https://sophia.javeriana.edu.co/~cbustaca/docencia/POO-
2016-01/documentos/Object%20Oriented%20Software
%20Construction-Meyer.pdf
FIGURAS
(fig1.) Descomposición modular, pág. 40.
(fig2.) Descomposición modular, pág. 41.
(fig3.) Composición modular, pág. 42.
(fig4.) Comprensibilidad modular, pág. 43.
(fig5.) Continuidad modular, pág. 44.
(fig6.) Protección modular, pág. 45.
(fig7.) Pocas interfaces, pág. 47.
(fig8.) Pocas interfaces, pág. 47.
(fig9.) Pocas interfaces, pág. 47.
(fig10.) Pequeñas interfaces, pág. 47.
(fig11.) Interfaces explicitas, pág. 49.
(fig12.) Ocultamiento de información, pág. 50.
(fig13.) Acceso uniforme, pág. 54.
Autor
Juan David Hermosa Martin estudiante de cuarto semestre de
la universidad Distrital Francisco José de Caldas, Facultad de
Ingeniería, Proyecto curricular de Ingeniería de Sistemas,
Asignatura de Programación Avanzada.
4