Aoo05
Upcoming SlideShare
Loading in...5
×
 

Aoo05

on

  • 95 views

 

Statistics

Views

Total Views
95
Views on SlideShare
95
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

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

Aoo05 Aoo05 Presentation Transcript

  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 1 Análisis y Diseño
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 2 El análisis se centra en la investigación del problema, no en la manera de definir la solución. Ej. Si se necesita un sistema de biblioteca Cuales son los procesos de la organización que se relacionan con su uso? Qué es análisis?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 3 El diseño pone en relieve una solución lógica: como el sistema cumple con los requerimientos. Ej. De qué manera el sistema capturará y registrará los préstamos de libros? La esencia de estas actividades consiste en situar el dominio del problema y la solución lógica dentro de la perspectiva de los objetos. Qué es diseño?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 4 Durante el análisis se procura identificar y describir objetos – o conceptos – dentro del dominio del problema. Durante el diseño se procura definir objetos lógicos del software Análisis y diseño
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 5 Análisis y diseño
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 6 Análisis y diseño Para entender los requerimientos se necesita conocer los procesos de dominio y el ambiente externo , o sea los factores externos que participan en el proceso. Dichos procesos se pueden expresar en forma de casos de uso, los cuales son una descripción narrativa del proceso de dominio en un formato estructurado de prosa,
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 7 Análisis y diseño; Ejemplo El juego de dados: Caso de uso: juega un juego Participantes: jugador Descripción: Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. Si los puntos suman 7 gana y si suman cualquier otro número, pierde.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 8 Análisis y diseño El modelo conceptual o modelo de análisis es una representación de conceptos u objetos en el dominio del problema, como libro, biblioteca. Debe limitarse el esfuerzo aplicado a la creación de un modelo conceptual preliminar en la fase de planificación y elaboración, por la complejidad que pueden tener. Puede ser elaborado una vez definidos los requerimientos o antes de los ciclos de desarrollo.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 9 Análisis y diseño; Ejemplo
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 10 Análisis y diseño; Ejemplo El modelo conceptual muestra los conceptos jugador, dados, juego de dados, sus asociaciones atributos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 11 Análisis y diseño; Ejemplo El modelo conceptual muestra los conceptos jugador, dados, juego de dados, sus asociaciones atributos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 12 Análisis y diseño; Ejemplo El Diagrama de colaboración presenta el flujo de mensajes entre instancias y la invocación a los métodos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 13 Análisis y diseño; Ejemplo Para definir una clase en preciso contestar varias preguntas: Cómo se conectan unos objetos con otros? Cuales son los métodos de una clase? El jugador requiere de un método jugar y el dado requiere de un método lanzar.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 14 Análisis y diseño; Ejemplo El modelo de diseño o diagrama de diseño de clases describe componentes de software.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 15 Análisis y diseño; Ejemplo El modelo de diseño o diagrama de diseño de clases describe componentes de software.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 16 Comparación AD OO y estructurado
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 17 Construcción de un modelo conceptual El modelo conceptual explica los conceptos significativos en el dominio del problema, es el artefacto más importante a crear durante el análisis orientado a objetos. (Los casos de uso son importantes pero no son realmente orientados a objetos) La cualidad esencial que debe ofrecer un modelo conceptual es que representa cosas del mundo real, no componentes del software.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 18 Construcción de un modelo conceptual El modelo conceptual es un diagrama de estructura estática, es decir, no define ninguna operación. ELEMENTOS: 1. Conceptos 2. Asociaciones 3. Atributos de los conceptos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 19 Construcción de un modelo conceptual 1. Conceptos Un concepto es una idea, evento u objeto. Formalmente se lo define a partir de: Símbolo: palabras o imágenes que representan un concepto. Intensión: la definición de un concepto Extensión: el conjunto de ejemplos a que se aplica el concepto.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 20 Construcción de un modelo conceptual Ejemplo: Transacción venta. Símbolo: Lo denominamos VENTA Intensión: Representa la transacción de venta, tienen hora y fecha Extensión: conjunto de todas las ventas
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 21 Construcción de un modelo conceptual Identificación de conceptos 1. Lista des categorías comunes Objetos físicos o tangibles Especificaciones de diseño o descripciones de cosas Lugares Transacciones Línea de transacciones Papel(rol-cargo) de personas Contenedores de otras cosas Etc, etc, etc
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 22 Construcción de un modelo conceptual Identificación de conceptos 2. Identificación de frases nominales Consiste en identificar las frases nominales (sustantivos) en las descripciones textuales del dominio del problema y considerarlas conceptos o atributos. Esta técnica es muy útil cuando se empieza a entender el enfoque de orientación a objetos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 23 Construcción de un modelo conceptual Se recomienda combinar esta técnica con la lista de categorías
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 24 Construcción de un modelo conceptual Ejemplo: punto de venta Conceptos: • TPDV, producto, tienda, venta, pago • Catalogo de productos , especificación del producto • Venta línea de productos • Cajero, cliente, gerente
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 25 Construcción de un modelo conceptual Asociaciones Es una relación entre dos conceptos que indica alguna conexión significativa entre ellos En lenguaje UML se denominan relaciones estructurales entre objetos de diversos tipos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 26 Construcción de un modelo conceptual Asociaciones Comience por agregar las asociaciones utilizando la lista de asociaciones comunes:
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 27 Construcción de un modelo conceptual Asociaciones - Multiplicidad La multiplicidad define cuantas instancias de tipo A pueden asociarse a una instancia del tipo B en determinado momento.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 28 Construcción de un modelo conceptual Asociaciones – Múltiples entre conceptos Dos conceptos pueden tener varias asociaciones entre ellos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 29 Construcción de un modelo conceptual Asociaciones – ejemplo
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 30 Construcción de un modelo conceptual Modelo conceptual – punto de venta
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 31 Construcción de un modelo conceptual Modelo conceptual – atributos Un atributo es un valor lógico de un dato u objeto Pertenece a un concepto Tiene un tipo que define los posibles valores
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 32 Construcción de un modelo conceptual Modelo conceptual – atributos – tipos Tipos más comunes (valores puros de datos) Los atributos deberían ser simples o valores puros de datos Si es un valor complejo es mejor expresarlo como asociación.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 33 Construcción de un modelo conceptual Ejemplo Modelo conceptual – atributos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 34 Descripción del comportamiento Durante el análisis, se incluye modelos orientados a describir el comportamiento del sistema. Uno de ellos es el diagrama de secuencia del sistema. Antes de iniciar el diseño lógico de cómo funcionará la aplicación de SW es necesario investigar y definir el comportamiento del sistema como una “caja negra” EL comportamiento del sistema es una descripción de que es lo que hace, sin explicar como lo hace.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 35 Descripción del comportamiento El diagrama de secuencia del sistema muestra en un escenario, los eventos generados por eventos externos, su orden y los eventos externos del sistema Ej. Caso comprar productos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 36 Descripción del comportamiento EVENTOS Y OPERACIONES Evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. Una operación de un sistema es una acción que este ejecuta en respuesta a un evento del sistema Ej, un cajero genera un evento “introducir producto”, causa la ejecución de la operación “introducir producto” Los nombres del evento y la operación generalmente son iguales, La diferencia es que el evento es el estímulo y la operación es la respuesta. (igual que los mensajes y los métodos en las clases y objetos)
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 37 Descripción del comportamiento OPERACIONES Para determinar las operaciones del sistema se identifican los eventos. Ej, EfectuarPago(CUP, Cantidad) TerminarVenta() EfectuarPago(monto)
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 38 Descripción del comportamiento Diagramas de secuencia del sistema. 1.- determinar actores 2.- Los eventos (y sus operaciones asociadas) deben expresarse en el nivel de propósito. El nombre comúnmente empieza con un verbo (agregar, introducir, terminar, efectuar) ya que recalca que los eventos están orientados a comandos. Seleccionar el nivel mas alto u objetivo para dar el nombre a operaciones: ej: respecto a la operación que captura el pago: IntroducirImporteOfrecido(Monto) deficiente IntroducirPago(monto) mejor EfectuarPago() mejor aún
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 39 Modelo de análisis El modelo de análisis está compuesto de: Modelo de casos de uso de análisis (dinámico) Casos de uso de alto nivel o esenciales Diagramas de casos de uso Modelo conceptual (estático) Modelo de comportamiento (dinámico) Diagramas de secuencia del sistema Contratos para las operaciones del sistema Modelo de estado del análisis (dinámico) Diagramas de estado para conceptos y casos de uso
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 40 Modelo de análisis El modelo de análisis está compuesto de:
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 41 Modelo de análisis Contratos Los contratos contribuyen a definir el comportamiento del sistema El contrato es un documento que describe lo que una operación se propone lograr Se redacta en estilo declarativo, enfatizando lo que se conseguirá y no como se conseguirá Suelen expresarse a partir de los cambios de las precondiciones y post-condiciones. EL contrato de operación del sistema describe cambios de estado del sistema total cuando se llama una de sus operaciones.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 42 Modelo de análisis Elementos de un contrato
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 43 Modelo de análisis Ejemplo Contratos de la operación “IntroducirProducto”
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 44 Modelo de análisis Ejemplo Contratos de la operación “IntroducirProducto”
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 45 Modelo de análisis Diagramas de estado Muestran como los objetos cambian de estado en respuesta a los eventos. Los diagramas de secuencia se utilizan para modelar el comportamiento combinado de un grupo de objetos, pero también son útiles para resumir el comportamiento de un solo objeto como respuesta a los diversos mensajes que puede procesar. Para esto se utiliza un diagrama de estado.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 46 Modelo de análisis Ejemplo Diagramas de estado transmission done calibrate () test ()star tup () shutdown () calibration OK test complete weather summary complete clock collection done Operation repor tWeather () Shutdown Waiting Testing Transmitting Collecting Summarising Calibrating
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 47 Diseño Orientado a Objetos DOO comprende el desarrollo de un modelo orientado a objetos de un sistema SW para implementar los requerimientos identificados. Los objetos en un DOO están relacionados con la solución del problema a resolver.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 48 Actividades del proceso DOO Las actividades principales en el proceso de DOO incluyen: Contexto: Define el contexto y modos de uso del sistema; Arquitectura: Diseña la arquitectura del sistema; Objetos: Identifica los objetos principales del sistema; Modelos: Desarrolla los modelos de diseño; Interfaces: Especifique interfaces del objeto.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 49 Modelo de diseño Resumen del diseño
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 50 Architecture Una vez que las interacciones entre el sistema y su ambiente se han entendido, se usa esta información por diseñar la arquitectura del sistema. Debe haber normalmente no más de 7 entidades en un modelo arquitectónico.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 51 Weather station architecture Weather station Manages all external communications Collects and summarises weather data Package of instruments for raw data collections « subsystem» Data collection « subsystem» Instruments « subsystem» Interface Una arquitectura por capas es apropiado para la estación de tiempo Capa de la interface por manejar comunicaciones; Capa de colección de datos para los instrumentos gerente; Capa de los instrumentos para los datos colectivos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 52 Diseño de la Arquitectura Una etapa inicial del proceso de diseño del sistema. Representa el vínculo entre el pliego de condiciones y procesos de diseño. A menudo llevan a cabo paralelamente con algunas actividades de especificación de requerimientos Comprende la identificación de los principales componentes del sistema y sus comunicaciones.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 53 Ventajas de una arquitectura explícita Aporta en: Comunicación con stakeholders La arquitectura puede ser utilizado como un centro de la discusión por las partes interesadas del sistema. Análisis del sistema Significa que el análisis de si el sistema puede cumplir con sus requisitos no funcionales es posible. Reutilización a gran escala La arquitectura puede ser reutilizable en una serie de sistemas.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 54 Architecture and system characteristics La arquitectura del sistema afecta al rendimiento, solidez, grado de distribución y mantenibilidad de un sistema. Rendimiento Identificar las operaciones críticas y minimizar las comunicaciones. Utiliza grandes componentes. Protección Usar una arquitectura en capas, con los elementos críticos en las capas internas para protegerlos. Seguridad Localizar Operaciones críticas para la seguridad en un pequeño número de sub-sistemas o en un subsistema único. Disponibilidad Incluir componentes redundantes y mecanismos de tolerancia a fallos. Mantenibilidad Usar componentes reemplazables.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 55 Estructura del sistema Descomposición del sistema en subsistemas que interactúan. El diseño arquitectónico se expresa en un diagrama de bloques de presentar una visión general de la estructura del sistema. Los modelos más específicos muestran la como los sub-sistemas comparten datos, se distribuyen e interacción con los demás y también pueden ser desarrollados.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 56 Sistema robótico de control de empaquetado Vision system Object identifica tion system Arm contr oller Gripper contr oller Packaging selection system Packing system Conveyor contr oller
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 57 Architectural design decisions 1. ¿Hay una arquitectura de la aplicación genérica que puede usarse? 2. ¿Cómo se distribuirá el sistema entre varios procesadores? 3. ¿Qué estilos arquitectónicos son apropiados para el sistema? 4. ¿Qué aproximación se usará para estructurar el sistema? 5. ¿Cómo se descompondrá en los módulos las unidades estructurales del sistema? 6. ¿Qué estrategia debe usarse para controlar el funcionamiento de las unidades del sistema? 7. ¿Cómo se evaluará el diseño arquitectónico? 8. Cómo debería documentarse la arquitectura del sistema?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 58 Estilos de arquitectura El modelo arquitectónico de un sistema puede conformar a modelo arquitectónico genérico o estilo. Un conocimiento de estos estilos puede simplificar el problema de definir arquitecturas del sistema. Sin embargo, mayoría de los sistemas grandes es heterogéneo y no sigue un solo estilo arquitectónico.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 59 Modelo de Arquitectura Documenta un diseño arquitectónico y pueden tener las siguientes perspectivas: 1. Como un Modelo estructural estático que muestra los principales componentes del sistema. 2. Como Modelo del procesos dinámicos que muestra la estructura de los procesos del sistema. 3. Como Modelo de interfaz que define interfaces de los sub-sistema. 4. Las relaciones diseñan como un modelo de flujo de datos entre subsistemas. 5. Modelo de la distribución que muestra cómo los sub-sistemas son distribuídos entre las computadoras.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 60 Diseño de subsistemas En el diseño de Sistemas OO se particiona el modelo de análisis, para definir colecciones congruentes de clases, relaciones y comportamiento. Estos elementos de diseño se definen como subsistema. En general todos los elementos de un subsistema comparten alguna propiedad en común. Y se integran para completar la misma función. Los subsistemas se identifican por los servicios que proveen.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 61 Criterios de Diseño de subsistemas Interfaz definida y reducida con el resto del sistema. Las clases dentro del subsistema deben colaborar solo con otras clases dentro del subsistema (a excepción de las clases de comm) El número debe ser bajo Un subsistema puede ser particionado para reducir complejidad.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 62 Estratificación por capas Cada capa contiene uno o más subsistemas. Cada capa representa un nivel de abtracción diferente para completar la función del sistema El enlace puede ser cliente-servidor o peer- to-peer
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 63 Arquitectura de 3 capas Capa de presentación.- interfaz de usuario, ventanas, reportes, etc. Capa de aplicación.- tareas y reglas que rigen el proceso. Capa de base de datos.- mecanismo de almacenamiento.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 64 Arquitectura de 3 capas
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 65 Arquitectura Multicapas La capa de aplicaciones se divide: objetos de dominio y servicios. Capa de presentación.- interfaz de usuario Capa de dominio.- servicios de alto nivel (pago, venta) Capa de Servicios.- incluye servicios de bajo nivel. Interfaz de la DB, Generador de reportes, comunicaciones. Capa de base de datos.- procesamiento de datos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 66 Arquitectura Multicapas
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 67 Paquetes UML Un paquete es un conjunto de cualquier tipo de elemento de un modelo: clases, casos de uso, diagramas de colaboración u otros paquetes. El paquete de más alto nivel es el sistema.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 68 Paquetes UML Las capas conforman los paquetes UML de menor nivel. Conformando un diagrama de paquetes de la arquitectura,
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 69 Ejemplo arquitectura
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 70 Ejemplo arquitectura
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 71 Ejemplo arquitectura
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 72 Modelo de diseño Continuación del diseño
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 73 Modelo de diseño El modelo de diseño muestra los objetos y clases de objetos y las relaciones entre estas entidades. Para esto se incluyen dos tipos de diagramas: estáticos y dinámicos Los modelos estáticos describen la estructura estática del sistema en términos de clases del objeto y relaciones: modelo de arquitectura, modelo de clases, esquema de bases de datos. Los modelos dinámicos describen las interacciones dinámicas entre los objetos: casos de uso reales, contratos, diagramas de interacción y colaboración, diagramas de estado.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 74 Diagramas de interacción y contratos para métodos y operaciones En la práctica, los diseñadores se percatan de que la preparación de los diagramas de interacción es uno de los pasos más lentos. La asignación de responsabilidades y la elaboración de los diagramas de interacción representan uno de los pasos más importantes en la fase de diseño.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 75 Diagramas de interacción y contratos para métodos y operaciones Los diagramas de interacción describen gráficamente la solución –a partir de los objetos en interacción- que satisfacen estas responsabilidades y poscondiciones. En los contratos se incluye una conjetura inicial sobre las responsabilidades y las poscondiciones de las operaciones inicio, introducirProducto, terminarVenta y efectuarPago.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 76 Diagramas de interacción y contratos para métodos y operaciones La calidad de diseño de la interacción de los objetos y la asignación de responsabilidades presentan gran variación. • Las decisiones poco acertadas dan origen a sistemas y componentes frágiles y difíciles de mantener, entender, reutilizar o extender. • Una implementación hábil se funda en los principios cardinales que rigen un buen diseño orientado a objetos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 77 Diagramas de interacción y contratos para métodos y operaciones • Los diagramas de interacción son algunos de los artefactos más importantes que se preparan en el análisis y diseño orientados a objetos. • Es muy importante asignar acertadamente las responsabilidades al momento de elaborar los diagramas de interacción. • El tiempo y el esfuerzo que se dedican a su elaboración, así como un examen riguroso de la asignación de responsabilidades, deberían absorber parte considerable de la fase de diseño de un proyecto. • UML define algunos patrones, principios y expresiones especializadas codificados que sirven para mejorar la calidad del diseño, llamados PATRONES GRASP
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 78 Diagramas de interacción y contratos para métodos y operaciones Los patrones GRASP son parejas de problema solución con un nombre, que codifican buenos principios y sugerencias relacionados frecuentemente con la asignación de responsabilidades. Pregunta: ¿Qué son los patrones GRASP? Respuesta: Los patrones GRASP describen los principios fundamentales de la asignación de responsabilidades a objetos, expresados en forma de patrones. GRASP es un acrónimo que significa General Responsibility Asignment Software Patterns (patrones generales de software para asignar responsabilidades).
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 79 Diagramas de interacción y contratos para métodos y operaciones Patrones GRASP • Experto • Creador • Bajo Acoplamiento • Alta Cohesión • Controlador.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 80 Diagramas de interacción y contratos para métodos y operaciones
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 81 Diagramas de interacción y contratos para métodos y operaciones
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 82 Diagramas de clases Una vez terminados los diagramas de interacción podemos identificar la especificación de las clases de software (y las interfaces) que participan en la solución de software y complementarlas con detalles de diseño, por ejemplo los métodos. Su preparación exige crear antes: • Modelo conceptual: a partir de éste el diseñador agrega detalles a la definición de las clases. • Diagramas de interacción: a partir de ellos el diseñador identifica las clases de software que intervienen en la solución, así como los métodos de las clases.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 83 Diagramas de clases El diagrama de clases de diseño describe gráficamente las especificaciones de las clases de software y de las interfaces en una aplicación. Normalmente contiene la siguiente información: • clases, asociaciones y atributos • interfaces, con sus operaciones y constantes • Métodos • información sobre los tipos de los atributos • Navegabilidad (visibilidad de los atributos) • dependencias.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 84 Diagramas de clases 1. Identifique todas las clases que participan en la solución del software. Para ello analice los diagramas de interacción. 2. Dibújelas en un diagrama de clases. 3. Duplique los atributos provenientes de los conceptos asociados del modelo conceptual. 4. Agregue los nombres de los métodos analizando los diagramas de interacción. 5. Incorpore la información sobre los tipos a los atributos y a los métodos. 6. Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos. 7. Agregue flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de los atributos. 8. Agregue las líneas de relaciones de dependencia para indicar la visibilidad no relacionada con los atributos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 85 Diagramas de clases