Presentación dada en el marco del congreso internacional de software libre GULEV 2010

1. Modularización EfectivaDomando a la Hidra Agustín Ramos Certum

2. Agenda Motivación Modularización Beneficios Efectos negativos Conceptos y métricas útiles Características de un diseño modular efectivo Principios de diseño OO Patrones Prácticas ¿Qué viene?

3. Demandas en el desarrollocontemporáneo de software Software cada vez más complejo Mayor tamaño Cantidad de funcionalidad implementada Complejidad tecnológica Cantidad y diversidad de sistemas con los que debe interactuar Mayor número de contextos de uso “More isdifferent” - Philip Anderson

4. Demandas en el desarrollocontemporáneo de software Adaptabilidad Requerimientos y tecnología cambiantes … con un ritmo acelerado Tiempos muy cortos de desarrollo Para aprovechar oportunidades de mercado Desarrollo globalizado Múltiples equipos geográficamente dispersos

5. Una estrategia efectiva demodularización puede ayudara enfrentar estos retos…

6. Modularización ¿Qué es? Particionar un sistema de acuerdo a ciertas restricciones y principios de diseño, así como una estrategia de desarrollo, gobernando las partes resultantes

7. Beneficios de la modularización Ayuda a atacar problemas de gran tamaño Partiendo el problema y permitiendo resolverlo incrementalmente. Permite distribuir las tareas de desarrollo entre diferentes personas/equipos. Reuso Separación de dominios (Verticales y Horizontales) Al separar la implementación de la solución de cada dominio, es posible utilizar esta implementación en un contexto distinto.

8. Beneficios de la modularización Mantenibilidad El entendido común es que sistemas modulares, cuyos módulos presentan alta cohesión y bajo acoplamiento son más fáciles de modificar y extender

9. Modularización No es nada nuevo…. Divide y vencerás suena muy familiar. Contamos con un arsenal de tecnologías y métodos orientados a la modularización Orientación a objetos Modelos de componentes (CORBA, EJB, etc) Aspectos … ¿lo hemos conseguido?

10. Modularización La modularización efectiva no se logra mediante el simple uso de un lenguaje o una tecnología. Es necesaria la correcta aplicación de principios y técnicas de diseño, así como el diseño de una estrategia de desarrollo.

11. Efectosnegativos de la moduarización Infierno de la dependencia Demasiadas dependencias Dependencias cíclicas Cadenas muy largas de dependencia. Dependencias en conflicto. Paradoja del reuso.

12. Demasiadasdependencias Cuando una aplicación tiene demasiadas dependencias, se pueden presentar los siguientes problemas: Dificultad de instalar y/o configurar Gran tamaño (tal vez inecesario) Inestabilidad Fragilidad relativa al cambio en las dependencias. A C B D F E G

13. Dependenciascíclicas Se da cuando un componente A depende de otro componente B, el cual a su vez depende directa o indirectamente de A. Hace imposible usar A sin usar B y viceversa. Una modificación en A puede tener un efecto en B y viceversa. A A B B C

14. Cadenasmuy largas de dependencias Cuando una cadena de dependencias es muy larga, la labor de determinar todas las dependencias necesarias para usar un componente puede ser muy laboriosa. Escenario: Para agregar la capacidad X al sistema, encontré un módulo libX que provee dicha capacidad. Voy a agregarlo… libX libA libB !Ouch! libZ libαβ

15. Dependencias en conflicto Escenario: Para agregar la capacidad a al sistema agregaré el módulo A v1.0, y para agregar la capacidad b, agregaré el módulo B v3.5 En el mejor de los casos A v1.0 es compatible con C v2.1, y así descartamos C v1.0 Pero no suele ocurrir =( C v1.0 A v1.0 B v3.0 C v2.0

16. Paradoja del re-uso Maximizar el re-uso dificulta el uso.

17. La otracara de la modularización Implementar una buena modularización no es fácil ! Requiere conocimiento profundo de los problemas involucrados… .. Y de las distintas técnicas y alternativas para prevenirlos y solucionarlos

18. Modularización EfectivaParte IIConceptos, Métricas,Principios, Prácticas y Patrones

19. Conceptos y métricasútiles Cohesión Acoplamiento Inestabilidad Abstracción Distancia de la secuencia principal

20. Cohesión Es una medida de la interrelación que existe entre las partes que componen un componente. Para clases, se define la “Falta de cohesión de métodos” (LCOM) como el número de grupos independientes en el grafo de dependencias. Clase Método C Método B attributo X Método A attributo Y attributo Z

21. Cohesión Para módulos (compuestos de varias clases), se define la “Cohesión Relacional” (RC) como el promedio del número de relaciones que cada clase mantiene con otras clases del módulo RC = (R + 1) / N R = número total de relaciones entre clases N = número total de clases Se considera un rango aceptable [1.5, 4]

22. Acoplamiento Son las dependencias que existen entre módulos Hay de dos tipos: Acoplamientoseferentes Acoplamientosaferentes Ce Ca Componente

23. Inestabilidad Se define como I = Ce / (Ce + Ca) Su valor es de 0 a 1 Ejemplo de componente máximamente estable Ejemplo de componente máximamente inestable Ce=0 Componente Estable I=0 Ca=3 Ca=0 Ce=3 Componente Inestable I=1

24. Abstracción Es la razón del número de tipos abstractos dentro del módulo. A = NA / N NA = número de clases abstractas en el módulo N = número de clases en el módulo El rango es de [0, 1] 0 indica un módulo absolutamente concreto. 1 indica un módulo absolutamente abstracto.

25. Distancia de la secuencia principal Se puede crear un diagrama que relaciona la Abstracción y la Inestabilidad Módulos abstractos y estables 1 Módulos concretos e inestables Abstracción Módulos concretos y estables Módulos abstractos e inestables Inestabilidad 0 1

26. ¿Qué caracteriza a un diseñomodular efectivo?

27. Características de un diseño modular efectivo Cada módulo tiene un conjunto de responsabilidades muy pequeño y bien definido. Cada módulo tiene un nombre que permite identificar claramente sus responsabilidades. Cada módulo provee una inferface, que provee el contrato del mismo en términos de requerimientos y responsabilidades, y es el mecanismo a través del cual puede ser utilizado (encapsulamiento). B A

28. Características de un diseño modular efectivo Existen módulos abstractos, con pocas dependencias y altamente estables. Existen también módulos concretos, que presentan cierto grado de inestabilidad debido a que usan a otros módulos para llevar a cabo el trabajo real. Estos módulos presentan un nivel de cohesión alto. Existen pocas o ninguna dependencias entre módulos concretos.

29. Características de un diseño modular efectivo Los módulos de alto nivel (capas superiores) tienen dependencias hacia módulos abstractos y pocas o ninguna dependencias hacia módulos concretos. Capa 1 A (concreto) Capa 2 B (abstracto) C (concreto)

30. Características de un diseño modular efectivo No existen dependencias cíclicas entre los módulos. Las responsabilidades bien definidas de los módulos, así como los límites y fronteras entre los mismos, facilitan que los cambios se realicen de manera local, minimizando el impacto en todo el sistema. A B

31. Características de un diseño modular efectivo Los módulos aislan los cambios

32. Características de un diseño modular efectivo El nivel de granularidad de los módulos es tal que establece un buen balance entre potencial de reuso y facilidad de uso.

33. Principios de Diseño OO

34. Principios de diseño OO Principio de responsabilidad única Principio “Abierto-Cerrado” Principio de substitución de Liskov Principio de segregación de interfaces. Principio de inversión de dependencias

35. Principios de diseño OO Single responsibilityprinciple Open-Closedprinciple Liskovsubstitutionprinciple Interfacesegregationprinciple Dependencyinversionprinciple SOLID Principio de equivalencia “liberación/reuso” Robert C. Martin (Uncle Bob) http://bit.ly/ooprinciples

36. Principios de diseño OO Principio de responsabilidad única “Una clase debería tener una y sola una razón para sufrir cambios” Principio “abierto-cerrado” “Las clases deberían poder ser extendidas sin necesidad de ser modificadas” Principio de substitución de Liskov “Las clases derivadas deben poder usarse en aquellos lugares donde se espera a la clase base”

37. Principios de diseño OO Principio de inversión de dependencias “Los módulos de alto nivel no deberían depender en módulos de bajo nivel, ambos deberían depender de abstracciones” Principio de segregación de interfaces. “Crea interfaces de grano fino que son específicas para un cliente o escenario de uso” Principio de equivalencia liberación/reuso “La unidad de reuso es la unidad de liberación”

38. ¿Qué constituye una buena dependencia? Una “buena dependencia” es aquella dirigida a un elemento de poca volatilidad (estable). Entre menos volátil sea el blanco de la dependencia, mejor es la calidad de ésta. Una “mala dependencia” es aquella dirigida e un elemento muy volátil Componente Estable Componente Inestable

39. Patrones de Modularización

40. Patrones de Modularización Patrones Básicos Administra las relaciones Reuso de módulos Módulos cohesivos Reuso de clases. Patrones de Dependencias Dependencias acíclicas Conservación de las capas físicas Independencia del contenedor Despliegue independiente Excepciones co-localizadas

41. Patrones de Modularización Patrones de Usabilidad Interfaz publicada Configuración externa Fachada de módulos Patrones de Extensibilidad Módulos estables Módulos abstractos Fábrica de implementación Abstracciones separadas

42. Patrones de Modularización Patrones de Utilería Compilación nivelada Componente de pruebas Más detalles http://bit.ly/asqmsD

43. Prácticas

44. Prácticasparauna modularización efectiva Implementa un esquema de versionamiento a nivel módulos. Sin esto es imposible controlar el uso de módulos. Si no sabes como, comienza por 3 números: Mj.Mn.Bf ¡No le quites los números de versión a los binarios! Usa un repositorio de módulos. Dentro de tu organización o grupo de trabajo Debe ser administrado debidamente. Establece políticas para subir artefactos Incorpora un mecanismo de resolución de dependencias.

45. Prácticasparauna modularización efectiva Integra tu sistema de compilación con tu repositorio de módulos. Audita continuamente las métricas de tus módulos. Refactoriza continuamente para evitar Código duplicado Clases o métodos muy complejos Violaciones de los principios de OO Métricas con valores fuera de rango permitido

46. ¿Qué viene? Sistemas de módulos que orienten a los desarrolladores a implementar una buena modularización, y se los facilite Tanto herramientas de desarrollo como entornos de ejecución En el mundo java, OSGi cobra cada vez más fuerza. Repositorios de dependencias que soportan La noción de ‘feature’ Rangos de versiones para sus dependencias. Modularización de servicios, en la nube.

47. ¿Preguntas?

48. Referencias Principios de diseño OO http://bit.ly/oopandp Métricas de diseño relacionadas con modularización http://bit.ly/oometrics Patrones de modularización http://bit.ly/asqms Libro: Modular Java http://bit.ly/cedNNA OSGi http://www.osgi.org

49. ¡Gracias! Agustín Ramos http://machinesareus.blogspot.com Twitter: @MachinesAreUs