modularización efectiva - domando a la hidra
Post on 26-Jan-2015
132 Views
Preview:
DESCRIPTION
TRANSCRIPT
Modularización EfectivaDomando a la Hidra
Agustín RamosCertum
AgendaMotivaciónModularizaciónBeneficiosEfectos negativosConceptos y métricas útilesCaracterísticas de un diseño modular efectivoPrincipios de diseño OOPatronesPrácticas¿Qué viene?
Demandas en el desarrollo contemporáneo de software
Software cada vez más complejoMayor tamañoCantidad de funcionalidad implementadaComplejidad tecnológicaCantidad y diversidad de sistemas con los que debe interactuarMayor número de contextos de uso
“More is different” - Philip Anderson
Demandas en el desarrollo contemporáneo de software
AdaptabilidadRequerimientos y tecnología cambiantes… con un ritmo acelerado
Tiempos muy cortos de desarrolloPara aprovechar oportunidades de mercado
Desarrollo globalizadoMúltiples equipos geográficamente dispersos
Una estrategia efectiva demodularización puede ayudar
a enfrentar estos retos…
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
Beneficios de la modularizaciónAyuda a atacar problemas de gran tamaño
Partiendo el problema y permitiendo resolverlo incrementalmente. Permite distribuir las tareas de desarrollo entre diferentes personas/equipos.
ReusoSeparació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.
Beneficios de la modularizaciónMantenibilidad
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
ModularizaciónNo 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 objetosModelos de componentes (CORBA, EJB, etc)Aspectos
… ¿lo hemos conseguido?
ModularizaciónLa 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.
Efectos negativos de la moduarización
Infierno de la dependenciaDemasiadas dependenciasDependencias cíclicasCadenas muy largas de dependencia.Dependencias en conflicto.
Paradoja del reuso.
Demasiadas dependenciasCuando una aplicación tiene demasiadas dependencias, se pueden presentar los siguientes problemas:
Dificultad de instalar y/o configurarGran tamaño (tal vez inecesario)InestabilidadFragilidad relativa al cambio en las dependencias.
CB D FE G
A
Dependencias cíclicasSe 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
B
A
BC
Cadenas muy largas de dependenciasCuando 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
libZlibαβ!
Ouch!
Dependencias en conflictoEscenario: 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.0Pero no suele ocurrir =(
C v1.0
B v3.0
A v1.0
C v2.0
Paradoja del re-usoMaximizar el re-uso dificulta el uso.
La otra cara 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
Modularización Efectiva
Parte IIConceptos, Métricas,
Principios, Prácticas y Patrones
Conceptos y métricas útiles
CohesiónAcoplamientoInestabilidadAbstracciónDistancia de la secuencia principal
CohesiónEs 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 A
Método B Método C
attributo Y
attributo X
attributo Z
CohesiónPara 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 clasesN = número total de clases
Se considera un rango aceptable [1.5, 4]
AcoplamientoSon las dependencias que existen entre módulosHay de dos tipos:
Acoplamientos eferentesAcoplamientos aferentes
CeCa Componente
InestabilidadSe define como I = Ce / (Ce + Ca)Su valor es de 0 a 1Ejemplo de componente máximamente estable
Ejemplo de componente máximamente inestable
Ce=0Ca=3 ComponenteEstable I=0
Ce=3Ca=0 ComponenteInestable I=1
AbstracciónEs 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óduloN = 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.
Distancia de la secuencia principalSe puede crear un diagrama que relaciona la Abstracción y la Inestabilidad
Abst
racc
ión
Inestabilidad0
1
1
Módulos abstractos y establesMódulos concretos e inestablesMódulos concretos y establesMódulos abstractos e inestables
¿Qué caracteriza a un diseñomodular efectivo?
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).
BA
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.
Capa 2
Capa 1
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.
A(concreto)
B(abstracto)
C(concreto)
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.
Características de un diseño modular efectivo
A
B
Características de un diseño modular efectivo
Los módulos aislan los cambios
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.
Principios de Diseño OO
Principios de diseño OOPrincipio de responsabilidad únicaPrincipio “Abierto-Cerrado”Principio de substitución de LiskovPrincipio de segregación de interfaces.Principio de inversión de dependencias
Principios de diseño OOSingle responsibility principleOpen-Closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
SOLIDPrincipio de equivalencia “liberación/reuso”
Robert C. Martin (Uncle Bob)http://bit.ly/ooprinciples
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”
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”
¿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
ComponenteEstable
ComponenteInestable
Patrones de Modularización
Patrones de ModularizaciónPatrones Básicos
Administra las relacionesReuso de módulosMódulos cohesivosReuso de clases.
Patrones de DependenciasDependencias acíclicasConservación de las capas físicasIndependencia del contenedorDespliegue independienteExcepciones co-localizadas
Patrones de ModularizaciónPatrones de Usabilidad
Interfaz publicadaConfiguración externaFachada de módulos
Patrones de ExtensibilidadMódulos establesMódulos abstractosFábrica de implementaciónAbstracciones separadas
Patrones de Modularización
Patrones de UtileríaCompilación niveladaComponente de pruebas
Más detalleshttp://bit.ly/asqmsD
Prácticas
Prácticas para una 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 trabajoDebe ser administrado debidamente.Establece políticas para subir artefactosIncorpora un mecanismo de resolución de dependencias.
Prácticas para una 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 evitarCódigo duplicadoClases o métodos muy complejosViolaciones de los principios de OOMétricas con valores fuera de rango permitido
¿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ónEn el mundo java, OSGi cobra cada vez más fuerza.
Repositorios de dependencias que soportanLa noción de ‘feature’Rangos de versiones para sus dependencias.
Modularización de servicios, en la nube.
¿Preguntas?
Referencias
Principios de diseño OO http://bit.ly/oopandp
Métricas de diseño relacionadas con modularizaciónhttp://bit.ly/oometrics
Patrones de modularizaciónhttp://bit.ly/asqms
Libro: Modular Javahttp://bit.ly/cedNNA
OSGi http://www.osgi.org
¡Gracias!
Agustín Ramoshttp://machinesareus.blogspot.com
Twitter: @MachinesAreUs
top related