Modularización efectiva - domando a la hidra

5,196 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,196
On SlideShare
0
From Embeds
0
Number of Embeds
903
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Modularización efectiva - domando a la hidra

  1. 1. Modularización EfectivaDomando a la Hidra<br />Agustín Ramos<br />Certum<br />
  2. 2. Agenda<br />Motivación<br />Modularización<br />Beneficios<br />Efectos negativos<br />Conceptos y métricas útiles<br />Características de un diseño modular efectivo<br />Principios de diseño OO<br />Patrones<br />Prácticas<br />¿Qué viene?<br />
  3. 3. Demandas en el desarrollocontemporáneo de software<br />Software cada vez más complejo<br />Mayor tamaño<br />Cantidad de funcionalidad implementada<br />Complejidad tecnológica<br />Cantidad y diversidad de sistemas con los que debe interactuar<br />Mayor número de contextos de uso<br />“More isdifferent” <br />- Philip Anderson<br />
  4. 4. Demandas en el desarrollocontemporáneo de software<br />Adaptabilidad<br />Requerimientos y tecnología cambiantes<br />… con un ritmo acelerado<br />Tiempos muy cortos de desarrollo<br />Para aprovechar oportunidades de mercado<br />Desarrollo globalizado<br />Múltiples equipos geográficamente dispersos<br />
  5. 5. Una estrategia efectiva demodularización puede ayudara enfrentar estos retos…<br />
  6. 6. Modularización<br />¿Qué es?<br />Particionar un sistema de acuerdo <br />a ciertas restricciones y principios de diseño, <br />así como una estrategia de desarrollo,<br />gobernando las partes resultantes<br />
  7. 7. Beneficios de la modularización<br />Ayuda a atacar problemas de gran tamaño<br />Partiendo el problema y permitiendo resolverlo incrementalmente. <br />Permite distribuir las tareas de desarrollo entre diferentes personas/equipos.<br />Reuso<br />Separación de dominios (Verticales y Horizontales)<br />Al separar la implementación de la solución de cada dominio, es posible utilizar esta implementación en un contexto distinto.<br />
  8. 8. Beneficios de la modularización<br />Mantenibilidad<br />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<br />
  9. 9. Modularización<br />No es nada nuevo….<br />Divide y vencerás suena muy familiar.<br />Contamos con un arsenal de tecnologías y métodos orientados a la modularización<br />Orientación a objetos<br />Modelos de componentes (CORBA, EJB, etc)<br />Aspectos<br />… ¿lo hemos conseguido?<br />
  10. 10. Modularización<br />La modularización efectiva no se logra mediante el simple uso de un lenguaje o una tecnología.<br />Es necesaria la correcta aplicación de principios y técnicas de diseño, así como el diseño de una estrategia de desarrollo.<br />
  11. 11. Efectosnegativos de la moduarización<br />Infierno de la dependencia<br />Demasiadas dependencias<br />Dependencias cíclicas<br />Cadenas muy largas de dependencia.<br />Dependencias en conflicto.<br />Paradoja del reuso.<br />
  12. 12. Demasiadasdependencias<br />Cuando una aplicación tiene demasiadas dependencias, se pueden presentar los siguientes problemas:<br />Dificultad de instalar y/o configurar<br />Gran tamaño (tal vez inecesario)<br />Inestabilidad<br />Fragilidad relativa al cambio en las dependencias.<br />A<br />C<br />B<br />D<br />F<br />E<br />G<br />
  13. 13. Dependenciascíclicas<br />Se da cuando un componente A depende de otro componente B, el cual a su vez depende directa o indirectamente de A.<br />Hace imposible usar A sin usar B y viceversa.<br />Una modificación en A puede tener un efecto en B y viceversa.<br />A<br />A<br />B<br />B<br />C<br />
  14. 14. Cadenasmuy largas de dependencias<br />Cuando una cadena de dependencias es muy larga, la labor de determinar todas las dependencias necesarias para usar un componente puede ser muy laboriosa.<br />Escenario: Para agregar la capacidad X al sistema, encontré un módulo libX que provee dicha capacidad. Voy a agregarlo…<br />libX<br />libA<br />libB<br />!Ouch!<br />libZ<br />libαβ<br />
  15. 15. Dependencias en conflicto<br />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 <br />En el mejor de los casos A v1.0 es compatible con C v2.1, y así descartamos C v1.0<br />Pero no suele ocurrir =(<br />C v1.0<br />A v1.0<br />B v3.0<br />C v2.0<br />
  16. 16. Paradoja del re-uso<br />Maximizar el re-uso dificulta el uso.<br />
  17. 17. La otracara de la modularización<br />Implementar una buena modularización no es fácil !<br />Requiere conocimiento profundo de los problemas involucrados…<br />.. Y de las distintas técnicas y alternativas para prevenirlos y solucionarlos<br />
  18. 18. Modularización EfectivaParte IIConceptos, Métricas,Principios, Prácticas y Patrones<br />
  19. 19. Conceptos y métricasútiles<br />Cohesión<br />Acoplamiento<br />Inestabilidad<br />Abstracción<br />Distancia de la secuencia principal<br />
  20. 20. Cohesión<br />Es una medida de la interrelación que existe entre las partes que componen un componente.<br />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.<br />Clase<br />Método C<br />Método B<br />attributo X<br />Método A<br />attributo Y<br />attributo Z<br />
  21. 21. Cohesión<br />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<br />RC = (R + 1) / N<br />R = número total de relaciones entre clases<br />N = número total de clases<br />Se considera un rango aceptable [1.5, 4]<br />
  22. 22. Acoplamiento<br />Son las dependencias que existen entre módulos<br />Hay de dos tipos:<br />Acoplamientoseferentes<br />Acoplamientosaferentes<br />Ce<br />Ca<br />Componente<br />
  23. 23. Inestabilidad<br />Se define como I = Ce / (Ce + Ca)<br />Su valor es de 0 a 1<br />Ejemplo de componente máximamente estable<br />Ejemplo de componente máximamente inestable<br />Ce=0<br />Componente<br />Estable<br />I=0<br />Ca=3<br />Ca=0<br />Ce=3<br />Componente<br />Inestable<br />I=1<br />
  24. 24. Abstracción<br />Es la razón del número de tipos abstractos dentro del módulo.<br />A = NA / N<br />NA = número de clases abstractas en el módulo<br />N = número de clases en el módulo<br />El rango es de [0, 1]<br />0 indica un módulo absolutamente concreto.<br />1 indica un módulo absolutamente abstracto.<br />
  25. 25. Distancia de la secuencia principal<br />Se puede crear un diagrama que relaciona la Abstracción y la Inestabilidad<br />Módulos abstractos y estables<br />1<br />Módulos concretos e inestables<br />Abstracción<br />Módulos concretos y estables<br />Módulos abstractos e inestables<br />Inestabilidad<br />0<br />1<br />
  26. 26. ¿Qué caracteriza a un diseñomodular efectivo?<br />
  27. 27. Características de un diseño modular efectivo<br />Cada módulo tiene un conjunto de responsabilidades muy pequeño y bien definido.<br />Cada módulo tiene un nombre que permite identificar claramente sus responsabilidades.<br />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).<br />B<br />A<br />
  28. 28. Características de un diseño modular efectivo<br />Existen módulos abstractos, con pocas dependencias y altamente estables.<br />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.<br />Existen pocas o ninguna dependencias entre módulos concretos.<br />
  29. 29. Características de un diseño modular efectivo<br />Los módulos de alto nivel (capas superiores) tienen dependencias hacia módulos abstractos y pocas o ninguna dependencias hacia módulos concretos. <br />Capa 1<br />A<br />(concreto)<br />Capa 2<br />B<br />(abstracto)<br />C<br />(concreto)<br />
  30. 30. Características de un diseño modular efectivo<br />No existen dependencias cíclicas entre los módulos. <br />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.<br />A<br />B<br />
  31. 31. Características de un diseño modular efectivo<br />Los módulos aislan los cambios<br />
  32. 32. Características de un diseño modular efectivo<br />El nivel de granularidad de los módulos es tal que establece un buen balance entre potencial de reuso y facilidad de uso.<br />
  33. 33. Principios de Diseño OO<br />
  34. 34. Principios de diseño OO<br />Principio de responsabilidad única<br />Principio “Abierto-Cerrado”<br />Principio de substitución de Liskov<br />Principio de segregación de interfaces.<br />Principio de inversión de dependencias<br />
  35. 35. Principios de diseño OO<br />Single responsibilityprinciple<br />Open-Closedprinciple<br />Liskovsubstitutionprinciple<br />Interfacesegregationprinciple<br />Dependencyinversionprinciple<br />SOLID<br />Principio de equivalencia “liberación/reuso”<br />Robert C. Martin (Uncle Bob)<br />http://bit.ly/ooprinciples<br />
  36. 36. Principios de diseño OO<br />Principio de responsabilidad única<br />“Una clase debería tener una y sola una razón para sufrir cambios”<br />Principio “abierto-cerrado”<br />“Las clases deberían poder ser extendidas sin necesidad de ser modificadas”<br />Principio de substitución de Liskov<br />“Las clases derivadas deben poder usarse en aquellos lugares donde se espera a la clase base”<br />
  37. 37. Principios de diseño OO<br />Principio de inversión de dependencias<br />“Los módulos de alto nivel no deberían depender en módulos de bajo nivel, ambos deberían depender de abstracciones”<br />Principio de segregación de interfaces.<br />“Crea interfaces de grano fino que son específicas para un cliente o escenario de uso”<br />Principio de equivalencia liberación/reuso<br />“La unidad de reuso es la unidad de liberación” <br />
  38. 38. ¿Qué constituye una buena dependencia?<br />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.<br />Una “mala dependencia” es aquella dirigida e un elemento muy volátil<br />Componente<br />Estable<br />Componente<br />Inestable<br />
  39. 39. Patrones de Modularización<br />
  40. 40. Patrones de Modularización<br />Patrones Básicos<br />Administra las relaciones<br />Reuso de módulos<br />Módulos cohesivos<br />Reuso de clases.<br />Patrones de Dependencias<br />Dependencias acíclicas<br />Conservación de las capas físicas<br />Independencia del contenedor<br />Despliegue independiente<br />Excepciones co-localizadas<br />
  41. 41. Patrones de Modularización<br />Patrones de Usabilidad<br />Interfaz publicada<br />Configuración externa<br />Fachada de módulos<br />Patrones de Extensibilidad<br />Módulos estables<br />Módulos abstractos<br />Fábrica de implementación<br />Abstracciones separadas<br />
  42. 42. Patrones de Modularización<br />Patrones de Utilería<br />Compilación nivelada<br />Componente de pruebas<br />Más detalles<br />http://bit.ly/asqmsD<br />
  43. 43. Prácticas<br />
  44. 44. Prácticasparauna modularización efectiva<br />Implementa un esquema de versionamiento a nivel módulos.<br />Sin esto es imposible controlar el uso de módulos.<br />Si no sabes como, comienza por 3 números: Mj.Mn.Bf<br />¡No le quites los números de versión a los binarios!<br />Usa un repositorio de módulos.<br />Dentro de tu organización o grupo de trabajo<br />Debe ser administrado debidamente.<br />Establece políticas para subir artefactos<br />Incorpora un mecanismo de resolución de dependencias.<br />
  45. 45. Prácticasparauna modularización efectiva<br />Integra tu sistema de compilación con tu repositorio de módulos.<br />Audita continuamente las métricas de tus módulos.<br />Refactoriza continuamente para evitar<br />Código duplicado<br />Clases o métodos muy complejos<br />Violaciones de los principios de OO<br />Métricas con valores fuera de rango permitido<br />
  46. 46. ¿Qué viene?<br />Sistemas de módulos que orienten a los desarrolladores a implementar una buena modularización, y se los facilite<br />Tanto herramientas de desarrollo como entornos de ejecución<br />En el mundo java, OSGi cobra cada vez más fuerza.<br />Repositorios de dependencias que soportan<br />La noción de ‘feature’<br />Rangos de versiones para sus dependencias.<br />Modularización de servicios, en la nube.<br />
  47. 47. ¿Preguntas?<br />
  48. 48. Referencias<br />Principios de diseño OO<br />http://bit.ly/oopandp<br />Métricas de diseño relacionadas con modularización<br />http://bit.ly/oometrics<br />Patrones de modularización<br />http://bit.ly/asqms<br />Libro: Modular Java<br /> http://bit.ly/cedNNA <br />OSGi<br />http://www.osgi.org<br />
  49. 49. ¡Gracias!<br />Agustín Ramos<br />http://machinesareus.blogspot.com<br />Twitter: @MachinesAreUs<br />

×