Granularity

Diego Varela Flores | 2013017965

Pablo Mora Calderón | 2013113280

Diseño de software | Granularity

Parte 1

1. Defina el término “package”. (Según el autor del artículo).

Es un contenedor, en el que se agrupan componentes lógicamente relacionados y que puede ser implementado por otros componentes.

1. Liste ejemplos de “copia de código” y las implicaciones de esta práctica.

Ejemplos:

1. “Arrancar” un montón de código de un programa e insertar textualmente en otro.
2. Si robo un módulo de otra persona y lo enlazo en mis propias bibliotecas.

Implicaciones:

1. Si no funciona en tu ambiente, tienes que cambiarlo tú mismo.
2. Si existen bugs en el código, tienes que repararlos tú mismo.
3. Si el autor original encuentra algunos bugs en el código y los arregla, usted tiene que enterarse a como pueda de cuales son y tiene que encontrar la manera de hacer los cambios en su propia copia.

1. Defina ¿Qué es reusabilidad? (según el autor del artículo).

Cosiste en implementar en nuestro código librerías dinámicas o estáticas de terceros o propias sin la necesidad de acceder al código fuente de estas para entender su funcionamiento y acceder a sus funcionalidades. Cuando estas reciben mejoras por parte de su autor yo tengo acceso a la misma para poder realizar su implementación nuevamente en mi código.

1. Explique con sus palabras el principio Reuse/Release Equivalence Principle (REP).

El rehusar es como obtener un producto el cual sabemos va a tener manteniendo y también un acceso completo a todas sus versiones. Se tienen notificaciones cada vez que el autor realiza un cambio en el producto. Hay que usar un producto en su totalidad si la necesidad de abrirlo para reutilizar alguna de sus partes.

1. Explique con sus palabras el principio Common Reuse Principle (CRP).

Se debe hacer una abstracción en un paquete de todas aquellas clases reusables que colaboran entre sí.

1. De un ejemplo del cumplimiento del CRP.

Un ejemplo simple podría ser un contenedor de clases y sus iteradores asociados. Estas clases son reusadas juntas porque están fuertemente acopladas entre sí, por lo que deberían de estar en el mismo paquete.

1. Explique con sus palabras el principio Common Closure Principle (CCP).

Cuando hacemos un cambio a un requerimiento de un proyecto, o agregamos un requerimiento siempre deseamos que donde haya que cambiar código sea simple y cuando se dice simple es no tener que andar por varias partes del código para que cambiar las partes necesarias, sino que si se pudiera que solo hubiese que cambiar código de un paquete así fuera, esto es lo que quiere el CCP que las clases en un paquete estén tan relacionadas que tengan las mismas razones de cambio, esto logrará a la hora de un cambio disminuir la cantidad de lugares diferentes donde debemos cambiar el código.

1. Explique el principio Acyclic Dependencies Principle (ADP).

La  estructura de dependencia de un paquete no pude ser una estructura de dependencia cíclica. Esto es que varios ingenieros trabajan al mismo tiempo en el mismo paquete (asíncronamente) provocando “choques” de programación. La solución es dividir el paquete –general- en varios entregables que son asignados a un único ingeniero o grupo de ingenieros, cuando los entregables están listos se integra en el paquete original.

1. ¿Cuáles podrían ser los efectos de una dependencia cíclica de paquetes?

1. Dificultad para liberar paquete debido a la inter-compatibilidad.
2. Los ingenieros van a experimentar “the morning after syndrome”.
3. Si queremos hacer pruebas unitarias a un paquete, nos veremos obligados a hacer un “complete build”.
4. Se vuelve muy difícil aislar los módulos.
5. El tiempo de compilación crece exponencialmente con respecto a la cantidad de módulos.

1. ¿Cómo podría romperse la dependencia cíclica de paquetes?

Existen dos mecanismos:

1. Aplicar el Dependency Inversion Principle (DIP).
2. La estructura de dependencia siempre tiene que ser monitoreada en caso de ciclos. Esto podría significar la creación de nuevos paquetes, haciendo que la estructura de dependencia crezca.

1. Top down ó bottom up. ¿Cómo debería abordarse el diseño de paquetes?

La restructura del paquete no puede ser diseñada de arriba hacia abajo (de afuera hacia adentro) sino que más bien deber ser diseñada de abajo hacia arriba (de adentro hacia afuera).

...