Modularización efectiva - domando a la hidra

Modularización EfectivaDomando a la HidraAgustí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 desarrollocontemporáneo de softwareSoftware 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 isdifferent” - Philip Anderson

Demandas en el desarrollocontemporáneo de softwareAdaptabilidadRequerimientos y tecnología cambiantes… con un ritmo aceleradoTiempos muy cortos de desarrolloPara aprovechar oportunidades de mercadoDesarrollo globalizadoMúltiples equipos geográficamente dispersos

Una estrategia efectiva demodularización puede ayudara 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ñoPartiendo 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ónMantenibilidadEl 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ónOrientació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.

Efectosnegativos de la moduarizaciónInfierno de la dependenciaDemasiadas dependenciasDependencias cíclicasCadenas muy largas de dependencia.Dependencias en conflicto.Paradoja del reuso.

DemasiadasdependenciasCuando 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.ACBDFEG

Dependenciascí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.AABBC

Cadenasmuy 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…libXlibAlibB!Ouch!libZlibαβ

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.0A v1.0B v3.0C v2.0

Paradoja del re-usoMaximizar el re-uso dificulta el uso.

La otracara de la modularizaciónImplementar 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 EfectivaParte IIConceptos, Métricas,Principios, Prácticas y Patrones

Conceptos y métricasútilesCohesió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.ClaseMétodo CMétodo Battributo XMétodo Aattributo Yattributo 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óduloRC = (R + 1) / NR = número total de relaciones entre clasesN = número total de clasesSe considera un rango aceptable [1.5, 4]

AcoplamientoSon las dependencias que existen entre módulosHay de dos tipos:AcoplamientoseferentesAcoplamientosaferentesCeCaComponente

InestabilidadSe define como I = Ce / (Ce + Ca)Su valor es de 0 a 1Ejemplo de componente máximamente estableEjemplo de componente máximamente inestableCe=0ComponenteEstableI=0Ca=3Ca=0Ce=3ComponenteInestableI=1

AbstracciónEs la razón del número de tipos abstractos dentro del módulo.A = NA / NNA = número de clases abstractas en el móduloN = número de clases en el móduloEl 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 InestabilidadMódulos abstractos y estables1Módulos concretos e inestablesAbstracciónMódulos concretos y establesMódulos abstractos e inestablesInestabilidad01

¿Qué caracteriza a un diseñomodular efectivo?

Características de un diseño modular efectivoCada 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 efectivoExisten 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.

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

Características de un diseño modular efectivoNo 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.AB

Características de un diseño modular efectivoLos módulos aislan los cambios

Características de un diseño modular efectivoEl 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 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 responsibilityprincipleOpen-ClosedprincipleLiskovsubstitutionprincipleInterfacesegregationprincipleDependencyinversionprincipleSOLIDPrincipio de equivalencia “liberación/reuso”Robert C. Martin (Uncle Bob)http://bit.ly/ooprinciples

Principios de diseño OOPrincipio 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 OOPrincipio 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átilComponenteEstableComponenteInestable

Patrones de ModularizaciónPatrones BásicosAdministra 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 UsabilidadInterfaz publicadaConfiguración externaFachada de módulosPatrones de ExtensibilidadMódulos establesMódulos abstractosFábrica de implementaciónAbstracciones separadas

Patrones de ModularizaciónPatrones de UtileríaCompilación niveladaComponente de pruebasMás detalleshttp://bit.ly/asqmsD

Prácticasparauna modularización efectivaImplementa 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ácticasparauna modularización efectivaIntegra 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 faciliteTanto 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.

ReferenciasPrincipios de diseño OOhttp://bit.ly/oopandpMétricas de diseño relacionadas con modularizaciónhttp://bit.ly/oometricsPatrones de modularizaciónhttp://bit.ly/asqmsLibro: Modular Java http://bit.ly/cedNNA OSGihttp://www.osgi.org

¡Gracias!Agustín Ramoshttp://machinesareus.blogspot.comTwitter: @MachinesAreUs

Modularización efectiva - domando a la hidra

Más contenido relacionado

Similar a Modularización efectiva - domando a la hidra (20)

Más de Agustin Ramos (11)

Último (20)

Modularización efectiva - domando a la hidra