En esta entrada hablaremos sobre la modularidad, un concepto que mucha gente proclama conocer, pero en los hechos reales podemos apreciar que confunden seriamente el concepto en la mayoría de los casos.
Al igual que el concepto de calidad el concepto de modularidad no admite definiciones simples. Tanto uno como el otro requieren ser enfocados desde múltiples perspectivas con el fin de determinar con la mayor claridad posible que significa para un producto ser de calidad y para un método de construcción ser modular en el sentido de promover que los diseñadores construyan elementos autónomos conectados por medio de una estructura simple y coherente.
En general los paradigmas para el desarrollo de software incluyen un criterio de calidad llamado modularidad, que establecido de manera simple propone que las piezas resultantes de aplicar el criterio de partición propuesto por el paradigma, sean entendibles individualmente, para lo cual deberían ser cohesivas y estar bajamente acopladas.
Si estas abstracciones son independientes, tanto estas como los sistemas de las que forman parte pueden evolucionar sin riesgo. Por tanto si asumimos que un sistema puede evolucionar al evolucionar sus partes, el valor real del paradigma esta en la facilidad con la cual podemos crear islas de cambio.
Hemos enfatizado la necesidad de arquitecturas descentralizadas y flexibles para lograr productos de software extensibles, reusables y compatibles. Una palabra surge en tal discusión, deberíamos hacer nuestros productos más modulares.
Como "estructurado" o "amigables", modular es una de las palabras favoritas en la ingeniería de software, para la cual es difícil encontrar una definición precisa. La programación de pequeñas piezas, usualmente procedimientos o subrutinas. Sin embargo esta técnica no aporta ningún beneficio real al problema de la extensibilidad y reusabilidad a menos que las piezas resultantes, los módulos, sean autónomos, coherentes y organizados en torno a una arquitectura robusta. Cualquier definición de modularidad debe direccionar a estos tópicos.
Una definición simple sería insuficiente. Como en el caso de calidad, debemos pensar el concepto de modularidad desde múltiples perspectivas. El propósito de esta discusión es determinar que significa para un método de construcción de software ser modular, en el sentido de asistir a los diseñadores a producir sistemas de software construidos a partir de elementos autónomos conectados por una estructura coherente y simple. Las consecuencias más importantes de la modularidad son percibidas a nivel de diseño, por lo tanto no solo estamos interesados en módulos a nivel programas sino a nivel de módulos de diseño.
La forma de los módulos no esta definida en este estado. Nuestro interés es establecer una base para decidir acerca de la forma de los módulos. La forma más simple es el equivalente de una subrutina (o procedimiento), representando un paso de la tarea a ser ejecutada por el software.
Pronto surgirá que la subrutina es menos que satisfactoria para los propósitos de modularidad y se requerirán formas de módulos más avanzadas.
Los cinco criterios que permiten evaluar un método de diseño con relación a la modularidad son denominados:
- Descomposición modular
- Composición modular
- Entendibilidad modular
- Continuidad modular
- Protección modular
En entradas futuras estaremos hablando respecto a estos distintos criterios.
Saludos!
0 comentarios:
Publicar un comentario