Modularización efectiva - domando a la hidra
Upcoming SlideShare
Loading in...5
×
 

Modularización efectiva - domando a la hidra

on

  • 5,570 views

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

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

Statistics

Views

Total Views
5,570
Views on SlideShare
4,721
Embed Views
849

Actions

Likes
1
Downloads
24
Comments
0

17 Embeds 849

http://www.springhispano.org 441
http://machinesareus.blogspot.com 197
http://springhispano.org 90
http://machinesareus.blogspot.mx 86
http://www.slideshare.net 15
http://machinesareus.blogspot.com.es 5
http://machinesareus.blogspot.de 3
http://www.linkedin.com 2
http://machinesareus.blogspot.co.il 2
http://machinesareus.blogspot.fi 1
https://www.linkedin.com 1
http://machinesareus.blogspot.ch 1
http://machinesareus.blogspot.be 1
http://machinesareus.blogspot.ca 1
http://web.archive.org 1
http://machinesareus.blogspot.com.au 1
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Modularización efectiva - domando a la hidra Modularización efectiva - domando a la hidra Presentation Transcript

  • Modularización EfectivaDomando a la Hidra
    Agustín Ramos
    Certum
  • 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?
  • 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
  • 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
  • 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ó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.
  • 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
  • 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?
  • 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.
  • 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.
  • 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
  • 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
  • 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αβ
  • 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
  • Paradoja del re-uso
    Maximizar el re-uso dificulta el uso.
  • 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
  • Modularización EfectivaParte IIConceptos, Métricas,Principios, Prácticas y Patrones
  • Conceptos y métricasútiles
    Cohesión
    Acoplamiento
    Inestabilidad
    Abstracción
    Distancia de la secuencia principal
  • 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
  • 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]
  • Acoplamiento
    Son las dependencias que existen entre módulos
    Hay de dos tipos:
    Acoplamientoseferentes
    Acoplamientosaferentes
    Ce
    Ca
    Componente
  • 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
  • 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.
  • 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
  • ¿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).
    B
    A
  • 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.
  • 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)
  • 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
  • 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 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
  • 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
  • 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
    Componente
    Estable
    Componente
    Inestable
  • Patrones de Modularización
  • 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
  • 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
  • Patrones de Modularización
    Patrones de Utilería
    Compilación nivelada
    Componente de pruebas
    Más detalles
    http://bit.ly/asqmsD
  • Prácticas
  • 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.
  • 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
  • ¿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.
  • ¿Preguntas?
  • 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
  • ¡Gracias!
    Agustín Ramos
    http://machinesareus.blogspot.com
    Twitter: @MachinesAreUs