dise o de software l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dise ño de Software PowerPoint Presentation
Download Presentation
Dise ño de Software

Loading in 2 Seconds...

play fullscreen
1 / 113

Dise ño de Software - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Dise ño de Software. Ejemplo Diseño de Software. Ejemplo Diseño de Software. Ejemplo Diseño de Software. Ejemplo Diseño de Software. Ejemplo Diseño de Software. Diseño de Software. Puente entre mundos Fronteras difusas a diferencia de otras disciplinas…. Requerimientos.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dise ño de Software' - yagil


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
dise o de software7
Diseño de Software
  • Puente entre mundos
  • Fronteras difusas a diferencia de otras disciplinas…

Requerimientos

Arquitectura/Diseño de Software

Implementaciones

frenado del airbus a320
Frenado del Airbus A320

alt

Sensor

Sistema de Frenado Airbus A320

giro

pulsos

Ruedas

Sensor

Sensor

peso

señal de habilitado y deshabilitado de aceleración de reversa

prendido y apagado de motor

Motor de Reversa

Controlador de Aceleración de Reversa

señales de prendido y apagado de motor

Piloto

frenado del airbus a3209
Frenado del Airbus A320

Sistema de Frenado Airbus A320

giro

pulsos

Ruedas

Sensor

señal de habilitado y deshabilitado de aceleración de reversa

prendido y apagado de motor

Motor de Reversa

Controlador de Aceleración de Reversa

señales de prendido y apagado de motor

Piloto

recordatorio la relaci n entre el problema y soluci n
Recordatorio: La relación entre el problema y solución

Independiente

Dependencia de la implementación

Dependiente

Menos Info

Camino de Exploración

Nivel de Completitud

Enunciado delProblema

Enunciado de laImplementación

Mas Info

requerimientos y dise o una visi n top down
Requerimientos y Diseño: Una Visión Top-Down

Ojo: Tomar decisiones de bajo nivel es compatible con esta visión...

Requerimientos

Sistema

Design

Requerimientos

Subsistema

Design

Requerimientos

Componente

Design

dise o de software12
Diseño de Software

Los Sistemas de Software Intensivo son entes complejos

millones de líneas de código, variables, posibles estados, etc...

¿Cómo lidiamos con la complejidad?

Estructura y Abstracción...

...sí, pero cómo? qué abstracciones? qué relaciones?...

Diseñar involucra estructurar la solución utilizando abstracciones y relaciones entre las abstracciones apropiadas para poder:

Documentar y Comprender la propuesta de solución

Razonar sobre su grado de adecuación c.r.a los requerimientos

Comunicarla

Implementarla

Verificar/Validar el producto final

Modificar/Adaptar la solución en la medida que cambien los requerimientos

dise o de software13
Diseño de Software
  • Guía en la concepción de productos de software (requerimientos complejos, integración de componentes existentes, tecnología, familias de productos, etc.)
  • Drivers: atributos de calidad/requerimientos no funcionales y restricciones de proyecto y tecnología
    • Usualmente en tensión
  • A diferencia del mundo de los requerimientos:
    • Denota conceptos del mundo de la solución (pero incluye fenómenos de la interfase mundo máquina)
    • En general se describen propiedades localizadas (unidad, componente, módulo) y son de naturaleza operacional
objetivos de la etapa de dise o
Objetivos de la Etapa de Diseño

Descomponer el sistema en entidades de diseño “más chicas”

ej qué paquetes, clases, módulos, componentes...

Determinar la relación entre entidades.

ej. identificar dependencias

Fijar mecanismos de interacción

ej. memoria compartida, RPC, llamadas a función

Especificar interfaces y funcionalidad de entidades

ej. operaciones y sus aridades, descripción formal/informal de comportamiento

Identificar oportunidades para el reuso

tanto top-down como bottom-up

Documentar todo lo anterior junto con la fundamentación de las elecciones

metodolog a de dise o visi n macro
Metodología de Diseño: Visión “Macro”

El foco en el proceso de Diseño pasa:

de los stakeholders externos (cliente, usuario, etc.) a los internos (desarrolladores, testers, etc.)

de Qué y Porqué a Qué y Cómo

Pasos Macro

Diseño Arquitectónico (o Arquitectura)

Diseño Detallado (o Diseño)

Proceso iterativo

Decisiones clave primero

ej. Requerimientos no-funcionales críticos

¿Qué va a cambiar?

el dise o detallado y la tecnolog a de construcci n de soluciones
El Diseño Detallado y la Tecnología de Construcción de Soluciones
  • Decisiones, patrones, notaciones, modelos y “blueprints” de diseño pueden estar fuertemente impactados por el paradigma de la tecnología que se usa en la solución, (especialmente si hablamos de un diseño detallado)
  • Dónde está el límite entre codificar y diseñar?…
  • Veremos el caso cuando hablemos de POO
vistas
Vistas

La descripción de un sistema complejo no es unidimensional

Es clave saber cuáles son las vistas relevantes y vincularlas

Relevancia: depende del propósito (e.g., enunciar la misión de implementación, análisis de atributos de calidad, generación automática de código, planificación, etc.)

vistas y stackeholders
Vistas y stackeholders

La metáfora de D.Garlan

I do bones, not hearts.

These views are needed by the cardiologist…

…but will these views work for the orthopedist?

D.Garlan

vistas21
Vistas

Las vistas exponen atributos de calidad en diferente grado:

Vista modular: portabilidad…

Vista de deployment: performace, confiabilidad…

Enfatizan aspectos e ignoran otros para que el problema sea abordable

Ninguna vista es “EL” diseño

vistas cl sicas
Vistas Clásicas

Vista Modular: ¿Cómo agrupamos el código?

métodos, procedimientos, clases, librería, DLLs, APIs, paquetes, módulos...

usa, subclase, contiene, depende-de,...

diagrama de clases y de paquetes

Vista “Run-time” o de Componentes y Conectores: ¿Cómo son las entidades run-time?

procesos, threads, objetos, protocolos, ciclos de vida

se-comunica-con, bloquea, contiene, crea, destruye,...

maquinas de estado, diagrama de secuencia y de colaboración, diagrama de objetos, diagrama de componentes

Vista de Deployment (de Despliegue): ¿Dónde residen las distintas partes?

Recursos y repositorios además de entidades dinámicas o estáticas

procesos ejecuta-sobre server, código de módulos almacenado en directorio, equipo de trabajo desarrolla paquete,...

diagrama de despliegue, ...

ejemplo m dulos vs componentes
Ejemplo: Módulos vs. Componentes

Módulos: entidad en tiempo de diseño. Enfatiza en encapsulamiento: “information hiding” e interfaces.

Componentes: tienen entidad en tiempo de ejecución y de despliegue

alternando caracteres module view
Alternando caracteres: Module View

Alternar mayúsculas con minúsculas a partir de un stream de caracteres

main

split

lower

upper

merge

config

input/output

Referencias

Modulo

Usos

“sofTWareArchitecture” =>“SoFtWaReArCiTeCtUrE”

Modularización en función del a relación de uso

alternando caracteres c c view
Alternando caracteres: C&C View

lower

split

merge

upper

Referencias

Filter

Pipe

Binding

Componentes y Conectores(Pipe & Filter)

vista modular diagrama de clases
Vista Modular (Diagrama de Clases)

Este ejemplo enfatiza la agrupación de métodos y datos en clases además de asociaciones (dependencias estructurales) y relaciones de herencia y contiene-a

vista modular 2
Vista Modular (2)

Otros niveles de abstracción...

vista run time estructura componentes conectores objetos y links
Vista Run-Time (Estructura: componentes & conectores…Objetos y links)
ejemplo de vista run time estructura
Ejemplo de Vista Run-Time (Estructura)

Poner ejemplo con multiples instancias de un tipo

m dulo
Módulo

Concepto proveniente de los 60’s y 70’s

Basado en la noción de unidad de software que provee servicios a través de una interfaz bien definida

La manera de modularización suele determinar características como modificabilidad, portabilidad y reuso

elementos
Elementos

Un módulo es una unidad de código que implementa un conjunto de responsabilidades

Una clase, una colección de clases, una capa o cualquier descomposición de la unidad de código

relaciones
Relaciones

Se distinguen tres tipos de relaciones

es parte de que define la relación entre un submódulo A y un módulo B

depende de que define la dependencia entre dos módulos A y B

es un que define una relación de generalización entre un modulo específico y otro más general

module viewtype utilidad
Module Viewtype: utilidad

Análisis

A partir de estas vistas, es posible realizar distinto tipos de análisis Por ejemplo:

Trazabilidad de Requerimientos

Analiza como los requerimientos funcionales son soportados por las responsabilidades de los distintos módulos

Análisis de Impacto

Permite predecir el efecto de las modificación del sistema

module viewtype utilidad42
Module Viewtype: utilidad

Comunicación

Estas vistas pueden ser utilizadas para explicar las funcionalidades del sistema a alguien no familiarizado con el mismo

Distintos niveles de granularidad, presentan una descripción top-down de las responsabilidades del sistema

module viewtype cuando no
Module Viewtype: cuando no

Es dificultoso utilizar este tipo de vistas para realizar inferencias sobre el comportamiento del sistema durante su ejecución

Dada su naturaleza, no es de mucha utilidad para la realización de análisis de performance, confiabilidad u otras características asociadas al tiempo de ejecución

Múltiples instancias de objetos

Relaciones existentes sólo en tiempo de ejecución

elementos45
Elementos
  • Son entidades con manifestación runtime que consumen recursos de ejecución y contribuyen al comportamiento en ejecución del sistema
  • La configuración del sistema es un grafo conformado por la asociación entre componentes y conectores
  • Las entidades runtime son instancias de tipos de conector o componente
utilidad
Utilidad

¿Cuales son los componentes ejecutables y como interactúan?

¿Cuáles son los repositorios y que componentes los acceden?

¿Qué partes del sistema son replicadas y cuantas veces?

¿Cómo progresan los datos a los largo del sistema a medida que éste se ejecuta?

utilidad47
Utilidad

¿Qué protocolos de interacción son usados por las entidades comunicantes?

¿Qué partes del sistema se ejecutan en paralelo?

¿Cómo la estructura del sistema puede cambiar a medida que se ejecuta?

propiedades
Propiedades
  • Confiabilidad
    • Podemos usarlo para determinar la funcionalidad del sistema en su conjunto
  • Performance
    • Tiempo de respuesta / carga
    • Tiempo de latencia y volumen de procesamiento
  • Recursos requeridos
    • Necesidades de almacenamiento
    • Necesidades de procesamiento
propiedades49
Propiedades
  • Funcionalidad
    • Funciones mapeadas sobre el componente
  • Protocolos
    • Patrones de eventos o acciones que pueden tener lugar en una interacciones representada por el elemento
  • Seguridad
    • Encripta
    • Audita
    • Autentica
para lo que no sirve
Para lo que NO sirve

Nose debe usar para modelar elementos de diseño que no tienen comportamiento runtime

Una clase no es un componente. Un componente no representa de ninguna manera una visión estática de diseño

resumen conectores
ResumenConectores

C&C viewtype define modelo consistente de elementos que tienen presencia runtime

C&C viewtype incluye información sobre los caminos de interacción entre los componentes

Los componentes tienen interfaces llamadas ports

Los conectores tienen interfaces llamadas roles

ejemplo ip 2000 siemens

Ejemplo: IP 2000 Siemens

Source: Applied Software Architecture (Nord, Hofmeister)(Escaneado)

caracter sticas del c c
Características del C&C

Los componentes y conectores representan entidades de tiempo de ejecución

Los ports son las interfaces de comunicación de los componentes agrupando señales de entrada y salida que siguen algún tipo de secuenciamiento (protocolo)

Los conectores tienen como función mediar en la interacción entre componentes

Los conectores pueden representar formas complejas de interacción más allá del simple call return sincrónico

El conector debería especificar el protocolo bajo el cual los componentes interactúan para cada uno de sus roles

c c y comportamiento
C&C y Comportamiento

Sebastian Uchitel

herramientas conceptuales principios
Herramientas Conceptuales: Principios
  • Decomposición
    • Divide & Conquer (piezas conocidas y tratables)
    • Separación por niveles de abstracción y/o máquinas virtuales
    • Separación por aspectos, etc.
  • Modularidad
    • Colección bien definida de partes e interacciones bien delimitadas
  • Ocultamiento de la información
    • Confinar el impacto del cambio (de un módulo)
    • El ciente de un módulo no debe conocer los detalles de diseño difíciles o que pueden cambiar
  • Encapsulamiento
    • Clara separación de interface e implementación
    • Mecanismos para no conocer ni usar más de lo que la interface promete
  • Abstracción
    • Foco en lo esencial
principios cont
Principios (Cont.)
  • Explotar el Polimorfismo
    • tratamiento uniforme de una entidad que puede tener múltiples formas
    • Sustitución Liskov/Wing
  • Inversión de dependencia/control
    • Depender en abstracciones e interfaces en lugar de clases concretas
    • Ser invocado en lugar de invocar para reuso de abstracciones de control
  • Segregación de interfaces
  • Una sola responsabilidad (cohesion)
  • Open-Close
  • Detección de puntos de variabilidad

Advertencia:Estos principios han nacido con la extensibilidad y la modificabilidad como atributos de calidad preponderantes

estrategias de descomposici n
Estrategias de Descomposición
  • Problemas que sabemos resolver
    • Ej. M. Jackson’s Problem Frames: Control, Visualizacion, Correspondencia, etc
  • Pasos de ejecución
    • Ej. Filtros de procesamiento de imagenes
  • Tempo de ejecución
    • Ej. Acumulación vs Utilización de Información
  • Funcional
    • Ej. Facturación, Compras y Sueldos
  • Modos de Operación
    • Normal vs Excepcional
  • Datos
    • Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...
advertencia
Advertencia
  • Divide and Conquer está muy bien...
  • ...pero despues de descomponer hay que integrar
  • “Divide to Conquer and reunite to rule” M. Jackson
  • Hay que poder razonar sobre la composición...
descomposici n de software
Descomposición de software
  • Módulos
    • Agrupa estructuras de datos y código (y posiblemente otros módulos)
    • Entidad estática
    • A veces, separa Interfaz de Implementación
      • Interfaz bien definida
    • A veces, es compilable de manera independiente
      • Es una unidad de trabajo para desarrollo
  • Componentes
    • Entidades run-time
    • Descomposición para cumplir con ciertos requerimientos no funcionales distintos a los módulos (performance, distribución, tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).
abstracci n
Abstracción
  • Suprimir detalles de implementación permite
    • Posponer ciertas decisiones de detalle que ocurren a distintos niveles de análisis
    • Simplificar el análisis, comprensión y justificación de la decisión de diseño
  • Tipos de Abstracción
    • Procedural
      • ej. Funciones, métodos, procedimientos
    • Datos
      • ej. TADs, modelos de componentes
    • Control
      • ej. loops, iteradores, frameworks y multitasking
acoplamiento
Acoplamiento
  • Grado de dependencia del módulo sobre otros módulos y en particular las decisiones de diseño que estos hacen
  • Generalmente correlaciona inversamente con cohesión
    • Bajo/Débil acoplamiento y Alta Cohesión
  • Alto acoplamiento generalmente conlleva
    • Propagación de cambios cuando se altera un módulo
    • Módulos son difíciles de entender aisladamente
    • Reuso y testeo de módulos es difícil ya que se requieren otros módulos
  • Acoplamiento se incrementa si
    • Un módulo usa un tipo de otro módulo
    • Si un módulo usa un servicio de otro módulo
    • Si un módulo es un submódulo de otro
  • Bajo acoplamiento puede significar peor performance
    • Tradeoff...
tipos de acoplamiento
Tipos de Acoplamiento

Ordenado de mayor a menor (segun E. Yourdon y L. Constantine...)

  • Contenido
    • Cuando un módulo modifica o confía en el lo interno de otro
    • ej. acceso a datos locales o privados
  • Común
    • Cuando comparten datos comunes
    • ej. una variable global
  • Externo
    • Cuando comparten aspectos impuestos externamente al diseño.
    • ej. formato de datos, protocolo de comunicación, interfaz de dispositivo.
  • Control
    • Cuando un módulo controla la lógica del otro
    • ej. pasándole un flag de comportamiento).
  • Estampillado (Stamp)
    • Cuando comparten una estructura de datos pero cada uno usa sólo una porción
    • Paso de todo un registro cuando el módulo sólo necesita una parte.
  • Datos
    • Módulos se comunican a través de datos en parámetros
    • ej. llamado de funciones de otro módulo
  • Mensajes
    • Módulos se comunican a través de mensajes. Posiblemente no se conocen explícitamente
information hiding encapsulamiento
Information Hiding / Encapsulamiento
  • Esconder las decisiones de diseño que pueden llegar a cambiar
  • Minimizar el impacto de cambios futuros
  • Minimizar la información en la interfaz
  • Información a abstraer/esconder
    • Representación de datos
    • Algoritmos
    • Formatos de entrada y salida
    • Interfaces de bajo nivel
    • Separación de políticas y mecanismos
    • Decisiones estructurales de más bajo nivel
    • Aspectos funcionales
programaci n basada en interfases
Programación basada en interfases

Como usuario de una abstracción, es fundamental no depender de los detalles de la implementación

Ejemplos

Estándares de jure vs. Implementaciones

Estándares de facto vs. variaciones

Especificación vs. Implementación

Interfases (OO) vs. Clases concretas

dependency inversion principle
Dependency Inversion Principle
  • “Depend upon Abstractions. Do not depend upon concretions.”
  • Objetivo: Hacer un diseño más flexible, enfocando el diseño a interfaces o clases abstractas, en lugar de a clases concretas.
interface segregation principle
Interface Segregation Principle
  • “Many client specific interfaces are better than one general purpose interface”.
  • Objetivo: Separar interfaces para minimizar dependencias.
liskov substitution principle
Liskov Substitution Principle
  • Un principio pensado para lenguajes de programación con herencia...
  • “Subclasses should be substitutable for their base classes”
  • Una subclase puede ser usada donde su clase base es usada.
cohesi n
Cohesión
  • Del diccionario
    • cohesión. (Del lat. cohaesum, supino de cohaerēre, estar unido).

1. f. Accióny efecto de reunirse o adherirse las cosas entre sí o la materia de que están formadas.

    • cohesion. the action or fact of forming a united whole
  • Grado de [foco | cuán bien trabajan juntos | coherencia | unión] que tienen los distintos elementos de un módulo
  • Alta cohesión tiende a proveer:
    • Robustez
    • Confiabilidad
    • Reusabilidad
    • Comprensibilidad
    • Testeabilidad
    • Mantenibilidad
tipos de cohesi n
Tipos de Cohesión

Ordenado de peor a mejor (según E. Yourdon y L. Constantine en los 70’s)

  • Coincidental
    • ej. mis funciones de uso frecuente, utils.lib
  • Lógico
    • Existe una categoría lógica que agrupa elementos aunque hagan cosas muy distintas
    • ej. todas las rutinas de I/O
  • Temporal
    • Agrupadas por el momento en que se ejecutaran
    • ej. Funciones que atajan un error de output, crean un error en un log y notifican al usuario
  • Procedural
    • Agrupadas por pertenecer a una misma sequencia de ejecución o política.
    • ej. funciones que chequean permisos y abren archivos
  • Comunicacional
    • Agrupadas por operar sobre los mismo datos.
    • ej. objetos, operaciones sobre clientes.
  • Secuencial
    • Agrupadas porque el output de uno es el input de otro
  • Funcional
    • Agrupadas porque contribuyen a una tarea bien definida del módulo

Ed dice

que estos

son

aceptables

single responsibility principle
Single Responsibility Principle
  • “A class should have only one reason to change.”
  • Objetivo: Obtener un alto grado de cohesión. Una clase debe tener una y solo una responsabilidad.
extensibilidad y open closed principle
Extensibilidad y Open/Closed Principle
  • Los requerimientos cambian. El diseño debe poder acomodar estos cambios.
  • Un diseño extensible debe poder ser extendido con facilidad para incorporar nueva funcionalidad
  • The open/closed principle
    • Software entities should be open for extension but closed for modification
    • La idea es que la funcionalidad existente no debe tocarse para no romper código existente, sólo agregar.
    • ej. Capacidad de lidiar con nuevos tipos de eventos
preguntas para la buena modularizaci n
Preguntas para la Buena Modularización
  • Hay una jerarquía de módulos donde módulos grandes están descompuestos en más pequeños?
  • Cada módulo es comprensible de manera independiente
  • Qué cambios de requerimientos podrían implicar un cambio en el módulo?
    • The Single Responsability Principle: A module should have only one reason to change
  • Qué impacto tiene un pequeño cambio en un módulo a otros?
  • Qué impacto tiene el mal funcionamiento de un módulo sobre otros?
  • Es excesivo el número de módulos con que un módulo se comunica (fan-out)?
  • Es excesivo el número de módulos que utilizan al módulo (fan-out)?
    • Interface Segregation Principle: Many specific interfaces are better than a general one.
  • La interfaz de un módulo revela demasiado? Podría abstraerse?
  • Es evidente del código cuando dos módulos se comunican?
  • ...
design patterns
Design Patterns
  • Gamma, Helm, Johnson & Vlissides, 1995 (Aka The gang of four)
  • Soluciones esquemáticas (buen diseño) a problemas recurrentes en el desarrollo de software OO
  • Catálogo de 23 patrones:
    • fenómeno de definición terminológica
  • Los Design Patterns se suponen que incorporan los principios de diseño que vimos
design patterns87
Design Patterns
  • La descripción de un patrón de diseño debe incluir:
    • Nombre: Debe ser significativo
    • Problema: una descripición del problema atacado por el patrón
    • Contexto: precondiciones bajo las que puede ocurrir
    • Fuerzas: restrciciones y cuestiones que la solución debe tratar
    • Solución: relación estáticas y dinámicas entre los componentes del patrón. La solución resuelve las fuerzas en el contexto dado
    • Más
      • Ejemplos de uso
      • Patrones relacionados
      • Otros nombres usados del patrón
      • Ejemplo en código
design patterns88
Design Patterns
  • Tipos de Patterns:
    • De Creación: soluciones flexibles para la creación de instancias (e.g., abstract factory, singleton, etc.)
    • Estructurales: soluciones de organización (herencia, composición, agregación, asociación) de clases e interfaces para la extensibilidad y cambio (ej., composite, bridge, facade, adapter, etc.)
    • De comportamiento: soluciones para la asignación de responsabilidades y diseño de algoritmos. Muestran relación estática y comunicación (ej., command, interpreter, mediator, observer, memento, etc. )
design pattern singleton
Design Pattern: Singleton
  • Nombre: Singleton
  • Problema: Cómo definir una clase que debe tener una sola instancia accesible desde toda la aplicación.
  • Contexto: En algunas aplicaciones es importante que la clase tenga exactamente una instancia. Una aplicación de procesamiento de ventas podría tratar con ventas de una sola compañía y necesitar datos de la misma almacenado en un objeto que sería el único de la clase.
  • Fuerzas: Usar una variable global no es un buen diseño. Otra opción es no crear instancias sino usar métodos y atributos estáticos pero no es es una buena solución para explotar el polimorfismo sobre sublases singleton y require un conocimiento global del tratamiento de la instancia como singleton.
design pattern singleton90
Design Pattern: Singleton
  • Solución:Crear un método estático GetInstance(). Cuando accede por primera vez crea la instancia y devuelve una referencia. Las otra veces que es accedido retorna esa referencia. El patrón ofrece las siguientes ventajas y desventajas….
design pattern singleton91
Design Pattern: Singleton

Solución de Will Pugh (Thread Safe y Laizy load)

public class Singleton

{ // Protected constructor is sufficient to suppress unauthorized calls to the constructor

protected Singleton() {}

/** * SingletonHolder is loaded on the first execution of Singleton.getInstance() or the first access to SingletonHolder.instance , not before. */

private static class SingletonHolder {

private final static Singleton instance = new Singleton(); }

public static Singleton getInstance() { return SingletonHolder.instance; } }

design patterns103
Design Patterns
  • Strategy
  • Relación con el “Open-Close principle”
cu ndo usar los design patterns
Cuándo usar los Design Patterns
  • Hay un pattern para el problema
  • Propone una solución mejor
  • No hay una solución más simple
  • El contexto del problema es consistente con el del pattern
  • Las consecuencias de usarlo son aceptables
evaluaci n de dise os
Evaluación de Diseños

3 grandes tipos de evaluación

Requerimientos

Requerimientos

Requerimientos

Diseño

Diseño

Diseño

Código

Código

Código

algunos errores comunes 1 2
Algunos Errores Comunes (1/2)
  • Diseño Depth First
    • Sólo satisface algunos requerimientos
  • Refinamiento directo de la especificación de requerimientos
    • Puede llevar a un diseño ineficiente
  • Olvidarse de cambios a futuro
    • Diseñar para extensión (y contracción!)
  • Diseñar demasiado en detalle
    • Introduce demasiadas restricciones a implementación
    • es muy caro, no vale la pena
  • Diseñar exclusivamente top-down
    • Primero los requerimientos críticos!
    • No todo lo vamos a construir. Selección de COTS influye en la descomposición
algunos errores comunes 2 2
Algunos Errores Comunes (2/2)
  • Diseño documentado ambiguamente
    • Interpretado incorrectamente en tiempo de implementación
  • Decisiones de diseño indocumentadas
    • Diseñadores son necesarios durante la implementación
  • Decisiones de diseño sin justificación documentada
    • Cambios mas adelante, aparentemente inofensivos, rompen el diseño
  • Diseño inconsistente
    • Módulos funcionan, pero no encajan
    • Divide to conquer, reunite to rule
ejes para cr ticas de dise o
Ejes para críticas de diseño
  • Coorrección: fallas sintácticas y semánticas
  • Completud: tareas relevantes de diseño incompletas
  • Consistencia: contradicciones internas del diseño
  • Optimización: mejores opciones para los parámetros de diseño
  • Pertinencia: decisiones soportadas por requerimientos
  • Alternativas: otras elecciones para una decisión de diseño
  • Evolución: asuntos que comprometen futuros cambios
  • Presentación: uso torpe de la notación
  • Herramientas: otras herramientas que podrían ser usadas en una decisión de diseño
  • Experiencia: recordar experiencias pasadas relevantes
  • Organizacional: interses de otros stakeholders
m tricas de software
Métricas de Software

1970s: Intentos para definir criterios cuantitativos simples de complejidad del sofwtare y otras calidades

Halstead Complexity Measures

  • Program Length = total operators + total operands
  • Program Vocabulary = total distinct operators + total distinct
  • operands
  • Volume = Program Length * (log2Program Vocabulary)
  • Difficulty = (total distinct operators/2) * (total operands/total
  • distinct operands)
  • Effort = Difficulty * Volume

McCabe Complexity Measure

  • Cyclomatic Complexity = edges in call graph — nodes in call graph + connected components

COCOMO modelo de costo para la estimación de costo, esfuerzo y calendario

cr tica a las m tricas weyuker et al
Crítica a las métricas: Weyuker et.al.

Weyuker y otros observaron que la mayoría de las métricas fallaban en cumplir algunas propiedades obvias y deseables

Weyuker definió 9 propiedades deseables

Propiedad 3: Detalles de Deseño son importantes

» Dos clases con la misma funcionalidad no deberían necesariamente tener el mismo valor para la métrica

Propiedad 4: Monotonía

» La métrica para una combinación de clases no puede dar menos que ninguna de las métricas de las componentes

Propiedad 6: La interacción de clases incrementa la complejidad

» El valor de la métrica de un par de clases que interactuan es mayor a la suma de los valores individuales

Shyam R. Chidamber, Chris F. Kemerer, ‘A Metrics Suite for Object Oriented Design’, IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476-493, Jun. 1994