Sistemas de Información II. Diseño de Sistemas Orientado a Objetos

Diseño de Sistemas Orientado a Objetos

Análisis de Sistemas Orientado a Objeto El Proceso Unificado Concepción Elaboración Construcción Transición Modelado del Negocio Requerimientos Análisis y Diseño Implementación Prueba Implantación Admón. del Proyecto Iteraciones IT #1 IT # 2 IT # 3 IT # 4 IT # 5 IT # 6 IT # 7 IT # 8

Objetivos Introducción Contenido Flujo de Trabajo de Diseño Modelo de Diseño en RUP El Diseño en el Proceso Unificado RUP

Objetivos Sistemas de Información II Introducir la descripción general del modelado estático (estructura) y dinámico (comportamiento) internos de un sistema entrando en detalles estructurales (clases, atributos y relaciones entre clases) y de comportamiento (operaciones, estados y actividades). Continuar con el estudio del Proceso Unificado en el flujo de trabajo de análisis y diseño. Presentar el modelo de diseño del Proceso Unificado.

Introducción En el flujo de requisitos se construye un modelo que representa el comportamiento observable o externo del sistema que se quiere obtener En los flujos de análisis, diseño e implementación, se representa la estructura y el comportamiento internos del sistema a realizar En los tres flujos se trabaja a diferentes niveles de abstracción, desde el más elevado en el análisis, hasta el más bajo en la implementación

Flujo de Trabajo de Diseño

Flujo de Trabajo de Diseño La técnica de modelado consiste en identificar, a través de las especificaciones de las clases de análisis las clases de diseño correspondientes Para cada clase de análisis se puede derivar una o más clases de diseño: Clase de control clase activa (>= 1) Clase de entidad clase de entidad (>= 1) Clase de interfaz clase de interfaz (>= 1)

Flujo de Trabajo de Diseño Clase de control: Se deriva al menos una clase activa, que representa un proceso o un hilo de proceso (thread) <<trace>> Gestor de cuentas Gestor de cuentas <<trace>> Gestor clientes Gestor clientes

Flujo de Trabajo de Diseño Clase de entidad: Se deriva al menos una clase de entidad, que guarda la información de una entidad u objeto del sistema, y se puede ligar a una clase activa para su gestión <<trace>> Facturas Facturas <<trace>> itemsfactura <<trace>> Clientes Clientes

Flujo de Trabajo de Diseño Clase de interfaz: Se deriva al menos una clase de interfaz y se puede ligar a una clase activa para su gestión y conexión con otros tipos de clases interfazdatos Cliente <<t race>> <<trace>> interfazproductos InterfazFacturar <<trac e>> int erfazpago

Flujo de Trabajo de Diseño El proceso de conversión del Modelo de Análisis (MA) al Modelo de Diseño (MD), la estrategia adoptada es mixta: Top-Down Level-to-Level Estrategia Top-Down: Se parte del Diagrama de Clases de Análisis de Contexto (DCAX, MA nivel 0) Inicialmente, cada uno de los paquetes / subsistemas en el DCAX puede corresponder a un subsistema en el Diagrama de Clases de Diseño de Contexto (DCDX, MD nivel 0) Sistemas de Información II

Flujo de Trabajo de Diseño: Estrategia Top-Down

Flujo de Trabajo de Diseño Estrategia Level-to-Level: Se trabaja con los diagramas de clases de Análisis de niveles inferiores (nivel 1, 2,...) Inicialmente, cada uno de los paquetes/subsistemas en el DCAX puede corresponder a un subsistema en el Diagrama de Clases de Diseño de Contexto (DCDX, MD nivel 0) Se puede tomar como guía la estructura de los DCA de niveles 1, 2,...y se aplican las transformaciones consiguientes, con las debidas precauciones.

Flujo de Trabajo de Diseño: Estrategia Level-to-Level

Flujo de Trabajo de Diseño El Modelo de Diseño consta igualmente de dos vistas: Vista de Diseño Estática: Descripción de la estructura del sistema a modelar con decisiones de implementación. Compuesta fundamentalmente por clases que se pueden agrupar en: Agrupaciones lógicas de clases o subsistemas, y que se pueden representar por los elementos de UML denominados paquetes Diagramas de clases de diseño (DCD) con la estructura de niveles ya conocida. Sistemas de Información II

Flujo de Trabajo de Diseño Vista de Diseño Dinámica: Descripción del comportamiento del sistema a modelar con decisiones de implementación. Compuesta fundamentalmente por diagramas UML: Diagrama de Interacción/ Secuencia de sucesos Diagrama de Interacción/ Colaboración Diagrama de Estados Diagrama de Actividades

Flujo de Trabajo de Diseño

EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura

EL Diseño en el proceso Unificado: Visión General

EL Diseño en el proceso Unificado: Visión General Abordar requisitos no funcionales y restricciones en relación a: Lenguajes de programación, reutilización de componentes, sistemas operativos, tecnologías de: distribución, concurrencia, bases de datos, interfaces de usuario, gestión de transacciones, etc. Descomponer el modelo de análisis en subsistemas que puedan desarrollarse en paralelo. Definir la interfaz de cada subsistema. Derivar una representación arquitectónica del sistema

EL Diseño en el proceso Unificado: Visión General Acercar el modelo de análisis al modelo de implementación Los milagros más comunes de la ingeniería del software son las transiciones desde el análisis hasta el diseño y desde el diseño al código (Richard Due).

EL Diseño en el proceso Unificado: Visión General Modelado de Análisis Modelo conceptual Pueden obtenerse varios diseños Menos formal Menos caro de desarrollar Puede eliminarse Modelado de Diseño Modelo físico Específico a una implementación Mas formal Más caro (5 veces más) Debe mantenerse todo el cv

EL Diseño en el proceso Unificado: Visión General

Artefactos: Modelo de Diseño Casos de uso en el dominio de la solución Cómo soportar requisitos funcionales/no funcionales y otras restricciones en el entorno de implementación Entrada fundamental para actividades de implementación

Artefactos: Clases de Diseño Una clase de diseño es una abstracción de una clase de implementación Las operaciones atributos, tipos, visibilidad (public, protected, private...), se pueden especificar con la sintaxis del lenguaje elegido Las relaciones entre clases de diseño se traducen de manera directa al lenguaje: generalización: herencia asociaciones, agregaciones: atributos Se pueden postergar algunos requisitos a implementación (por ejemplo: manera de nombrar los CAL/Notación atributos, Modelo del Negocio operaciones,...)

Artefactos: Clases de Diseño Realizan interfaces. Una clase de diseño puede ser activa (los objetos de la clase tienen su propio flujo de control y se ejecutan concurrentemente con otros objetos activos). Depende de la tecnología de concurrencia utilizada por el lenguaje de implementación.

Artefactos: Realización en diseño de los casos de uso Es una colaboración que describe cómo se realiza en diseño un caso de uso en términos de clases de diseño y sus interacciones

Artefactos: Realización en diseño de los casos de uso La realización en diseño de un caso de uso, incluye: Diagramas de clases de Diseño: clases participantes Diagramas de interacción: escenarios del caso de uso Descripción textual del flujo de eventos

Artefactos: Realización en diseño de los casos de uso Modelo de Análisis factura Vendedor (from Use Case View) interfacefacura gestorfactura producto

Artefactos: Realización en diseño de los casos de uso Modelo de Diseño cliente interfacepago 1 +posee 0..n +pertenece Vendedor (f rom Use Case Vie w) int erfacefactura gestorfactura fact ura 0..n +contiene interfaceproducto 1..n +esta contenida itemsfactura +produce 1 inventario producto +se asocia 1

Artefactos: Subsistemas de Diseño Para organizar los artefactos de diseño: clases de diseño, realización de casos de uso, interfaces y otros subsistemas. Fuertemente cohesionados y débilmente acoplados

Artefactos: Interfaz Los interfaces se utilizan para especificar las operaciones de las clases y los subsistemas de diseño Especifica una colección de operaciones públicas, tipos y parámetros necesarios para acceder y usar las capacidades de una clase de diseño o un subsistema Las clases de diseño soportan las operaciones de su interfaz mediante métodos. Los subsistemas de diseño soportan las operaciones de su interfaz mediante las clases de diseño (o subsistemas) que contiene

Artefactos: Interfaz La mayoría de las interfaces entre subsistemas se consideran relevantes para la arquitectura debido a que definen las interacciones permitidas entre los subsistemas

Actividades: Diseño de la Arquitectura

Artefactos: 3.1.6 Artefactos. Modelo Modelo de Despliegue de Despliegue Es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo Correspondencia entre la arquitectura software y la arquitectura del sistema Cada nodo representa un recurso de cómputo, normalmente un procesador o un dispositivo hardware similar Los nodos poseen relaciones que representan medios de comunicación que hay entre ellos, tales como una Intranet o Internet. El modelo de despliegue puede describir diferentes configuraciones de red

Artefactos: Modelo de Despliegue La funcionalidad de un nodo viene representada por los componentes que se ejecutan en él. El modelo de despliegue representa un mapeo claro entre la arquitectura software y la hardware. Un diagrama de distribución muestra la ubicación de los componentes en nodos, de tal forma que se obtenga una vista de distribución del sistema Los procesadores y dispositivos son estereotipos comunes de Nodo. Los nodos se conectan en el diagrama a través de una línea, que refleje la ruta de comunicación entre ellos Los elementos esenciales de un diagrama de distribución son los nodos y las conexiones 10 Modelo Físico = Modelo de Diseño + Modelo de Despliegue

Artefactos: Descripción de la Arquitectura (Vista Modelo de Diseño) Contiene una vista de la arquitectura del modelo de diseño que muestra sus artefactos relevantes para la arquitectura. Suele considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseño: La descomposición del modelo de diseño en subsistemas, sus interfaces y las dependencias entre ellos. Esta descomposición es muy significativa, debido a que los subsistemas y sus interfaces constituyen la estructura fundamental del sistemas. Clases de diseño fundamentales con una traza a las clases de análisis significativas y clases activas

Artefactos: Descripción de la Arquitectura (Vista Modelo de Diseño) Realizaciones de caso de uso diseño que describan una funcionalidad importante y crítica y que deban desarrollarse pronto en el ciclo de vida Artefactos: Descripción de la Arquitectura (Vista Modelo de Despliegue) Contiene una vista de la arquitectura del modelo de despliegue que muestra los artefactos relevantes para la arquitectura

Artefactos: Descripción de la Arquitectura Contiene una vista de la arquitectura del modelo de despliegue que muestra los artefactos relevantes para la arquitectura

Artefactos: Descripción de la Arquitectura Dimensiones de la arquitectura del software: Perspectivas diferentes para inversionistas diferentes: Usuario final, cliente, administrador de proyecto Ingeniero de sistema, desarrollador, arquitecto, evaluador Las perspectivas múltiples requieren múltiples vistas: Los diagramas de clases no muestran el mapeo del sistema al hardware Los diagramas de bloques de hardware no describen que partes del sistema son obtenidas de software comercial

Artefactos: Descripción de la Arquitectura Para describir completamente una arquitectura, se necesitan cuatro vistas: Una Vista Lógica que proporciona una imagen estática de las principales clases y sus relaciones Una Vista de Componentes que muestra como está el código organizado en paquetes y librerías, así como el software comercial Una Vista de Procesos que muestra procesos y tareas Una Vista de Distribución que muestra los procesadores, dispositivos y ligas en el ambiente operacional Finalmente, una Vista de Casos de Uso que explica como trabajan juntas las otras cuatro vistas

Artefactos: Descripción de la Arquitectura El Modelo 4+1 Vistas Vista Logica Vista de Componentes Funcionalidad Administración, reuso y portabilidad del Software Usuarios finales Vista de Casos de Uso Ingenieros de software Entendimiento de Utilidad Vista de Procesos Desempeño, Disponibilidad, Tolerancia de fallas Vista de Distribución Desempeño, Disponibilidad Tolerancia a fallas, Escalabilidad Entrega e Instalación Integradores de Sistema Ingenieros de Sistema

Artefactos: Descripción de la Arquitectura Las 4+1 Vistas del Modelo UML Vista Lógica Diagramas de Clases, Diagramas de Secuencias Vista de Componente Diagramas de Componentes Vista de Caso de Uso Diagramas de Casos de Uso, Diagramas de Secuencias Vista de proceso Vista de Despliegue Diagramas de Procesos Diagramas de Distribución

Actividades: Diseño de Casos de Uso Identificar las clases de diseño y/o subsistemas necesarios para la realización del caso de uso. Distribuir el comportamiento del caso de uso entre las clases y/o subsistemas de diseño

Actividades: Diseño de Casos de Uso Identificar las clases de diseño Derivar las clases de diseño de las correspondientes clases de análisis que participan en el caso de uso. Estudiar los requisitos especiales del caso de uso: realizarlos con los mecanismos genéricos de diseño o con clases de diseño. Asignar responsabilidades a las clases identificadas. Realizar un diagrama de clases que muestre las clases de diseño que intervienen en la realización del caso de uso y las relaciones entre ellas.

Actividades: Diseño de Casos de Uso Describir interacciones entre objetos de diseño Utilizar diagramas de secuencia objetos, instancias de actores, enlaces Crear un diagramas de secuencia Comenzar estudiando la realización en análisis del casos de uso Sobre los diagramas de secuencia: el caso de uso comienza cuando una instancia de un actor envía un mensaje a un objeto interfaz. cada clase de diseño identificada debería tener al menos un objeto participando en el diagrama de secuencia.

Actividades: Diseño de Casos de Uso Describir interacciones entre objetos de diseño En este flujo de trabajo gestionar excepciones y errores (entradas incorrectas, situaciones anormales, etc.)

Actividades: Diseño de Clases Identificar las responsabilidades de las clases de diseño (papeles en los casos de uso) Identificar: operaciones atributos relaciones en las que participa estados (diagramas de estados) métodos que soportan sus operaciones Requisitos nuevos

Actividades: Diseño de Clases Identificar operaciones En el lenguaje de implementación Mirar responsabilidades que tiene en los casos de uso Identificar atributos Describirlos en el lenguaje de programación Considerar los atributos de las clases de análisis de las que se derivan

Actividades: Diseño de Clases Identificar asociaciones y agregaciones Las interacciones en los diagramas de secuencia precisan de asociaciones entre las clases que interactúan. Minimizar el número de relaciones entre clases (disminuir el acoplamiento). Refinar multiplicidad, papeles, etc. Refinar la navegabilidad (dirección) de las asociaciones en base a los diagramas de secuencia. Identificar generalizaciones-especializaciones.

Actividades: Diseño de Clases Describir métodos Algoritmos para implementar alguna operación (lenguaje natural). Esqueletos de métodos generado por la herramienta. En general, esto se suele hacer en implementación. Describir estados Algunos objetos reaccionan en función de su estado actual. Utilizar diagramas de transición de estados.

Diagrama de clase de Diseño

Actividades: Diseño de los Subsistemas Intentar que los subsistemas de diseño estén débilmente acoplados. Intentar que las clases dentro de los subsistemas tengan una alta cohesión. Describir las dependencias entre los subsistemas. Determinar qué clases de unos subsistemas interactúan con qué otras clases de otros subsistemas.

Actividades: Diseño de los Subsistemas Asegurarse que el subsistema soporta sus interfaces. Objetivos: Subsistemas independientes Garantizar corrección de interfaces Garantizar la realización de dichas interfaces

Actividades: Diseño de la Arquitectura El objetivo es esbozar los modelos de diseño y despliegue y su arquitectura mediante la identificación de los siguientes elementos: Los nodos y sus configuraciones de red Los subsistemas y sus interfaces Las clases de diseño significativas para la arquitectura Los mecanismos de diseño genéricos que tratan requisitos comunes

Actividades: Diseño de la Arquitectura Identificación de Nodos y Configuraciones de Red Las configuraciones de red suelen tener una gran influencia sobre la arquitectura del software, incluyendo las clases activas que se necesitan y la distribución de la funcionalidad entre los nodos de red Las configuraciones de red habituales utilizan un patrón de tres capas: Capa de los clientes (interacción con el usuario) Capa de lógica de negocio o de aplicación Capa de funcionalidad de base de datos (acceso a datos) El patrón cliente / servidor simple es un caso especial del patrón de las tres capas, en el cual la capa de CAL/Notación aplicación Modelo del Negociose ubica en una de las otras capas

Actividades: 3.2.4 Actividades. Diseño de Diseño la Arquitectura de la Arquitectura Aspectos a destacar [Jacobson et al., 1999] Qué nodos se necesitan y cuál debe ser su capacidad en términos de potencia de procesamiento y tamaño de memoria? Qué tipo de conexiones debe haber entre los nodos y qué protocolos de comunicaciones deben utilizarse? Qué características deben tener las conexiones y los protocolos de comunicaciones, en aspectos tales como ancho de banda, disponibilidad y calidad? Es necesario tener alguna capacidad de proceso redundante, modos de fallo, migración de procesos, mantenimiento de copias de seguridad de los datos, CAL/Notación o Modelo aspectos del Negocio similares?

3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Ejemplo: Configuración de red para el Sistema Interbank Cliente del Comprador <<intranet (TCP/IP)>> Servidor del Comprador <<internet (TCP/IP)>> Servidor del Vendedor <<internet (TCP/IP)>> Cliente del Vendedor <<internet (TCP/IP)>> <<internet (TCP/IP)>> Servidor del Banco

Actividades: 3.2.4 Actividades. Diseño de Diseño la Arquitectura de la Arquitectura Identificación de Subsistema y sus Interfaces 3.2.4.2. Identificación de Subsistema y sus Interfaces Los subsistemas son un medio para organizar el modelo de diseño en piezas manejables. No todos los subsistemas se desarrollan internamente en el proyecto en curso Los subsistemas se organizan siguiendo un patrón de capas [Buchmann et al., 1996; Shaw y Garlan, 1996] Este patrón facilita la organización jerárquica de los subsistemas en capas Sigue la máxima de que los subsistemas de una capa sólo pueden referenciar subsistemas de un nivel igual o inferior La comunicación entre los subsistemas de diferentes capas se lleva a cabo mediante un conjunto de interfaces bien definidas

3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Identificación de subsistemas de aplicación Se identifican los subsistemas de las capas de la aplicación (dos capas superiores) Si se hizo una división adecuada en paquetes durante el análisis, se pueden utilizar éstos tanto como sea posible, e identificar los correspondientes subsistemas dentro del modelo de diseño. Se pueden refinar estos subsistemas para tratar temas relativos al diseño. La descomposición inicial de los subsistemas del análisis se refina cuando [Jacobson et al., 1999] Una parte de un paquete del análisis se corresponde con un subsistema por sí mismo. Esa parte puede ser compartida y utilizada por otros subsistemas

3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Algunas partes de un paquete de análisis se realizan mediante productos software reutilizados. Estas funcionalidades pueden asignarse a capas intermedias o subsistemas de software del sistema Los paquetes del análisis no representan una división adecuada del trabajo. Los paquetes del análisis no representan la incorporación de un sistema heredado. Se puede encapsular un sistema heredado, o parte de él, mediante un subsistema de diseño independiente. Los paquetes del análisis no están preparados para una distribución directa sobre los nodos

3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Patrón de capas propuesto en [Jacobson et al., 1999]

Actividades: Diseño de la Arquitectura Ejemplo: Identificación de subsistemas de diseño a partir de paquetes de análisis Modelo de Análisis <<Paquete de Analisis>> Gestion de Facturas del Comprador <<Paquete de Analisis>> Gestion de Cuentas Modelo de Diseño <<subsystem>> Gestion de facturas del comprador <<subsystem>> Gestion de cuentas

Actividades: Diseño de la Arquitectura Identificación de los subsistemas de servicios a partir de paquetes de servicios existentes <<Paquete de Analisis>> Ges tion de Cuentas <<Paquete de Servicio>> Cuentas <<Paquete de Servicio>> Riesgos <<subsystem>> Gestion de cuentas <<subsistemz de Servicio>> cuentas <<Subsistema de servicio>> riesgos

Actividades: Diseño de la Arquitectura Durante el diseño se puede identificar subsistemas de diseño de servicios para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso <<subsystem>> Gestion de facturas del comprador Capa especifica de la aplicación <<subsistema de servicio>> Gestion de Planificacion de pagos <<subsys tem >> Gestion de cuentas Capa general de la aplicación

Actividades: Diseño de la Arquitectura Identificación de subsistemas intermedios y de software del sistema Estos subsistemas constituyen los cimientos de un sistema. Toda la funcionalidad descansa sobre software como sistemas operativos, sistemas de gestión de bases de datos, software de comunicaciones, tecnologías de distribución de objetos, bibliotecas de componentes para el diseño de interfaces gráficas de usuario y tecnologías de gestión transacciones [Jacobson et al., 1997] La selección e integración de productos software que se compran o se construyen son dos de los objetivos fundamentales durante las fases de inicio y CAL/Notación elaboración Modelo del Negocio

Actividades: Diseño de la Arquitectura Definición de las dependencias Deberían definirse dependencias entre subsistemas si sus contenidos tienen relación entre sí La dirección de la dependencia debería ser la misma que la dirección de la navegabilidad de la relación. Si se utilizan interfaces entre subsistemas, las dependencias deberían ir hacia las interfaces, no hacia los subsistemas

Actividades: Diseño de la Arquitectura Dependencias y Capas

Actividades: Diseño de la Arquitectura Identificación de Interfaces entre Subsistemas Las interfaces proporcionadas por un subsistema definen operaciones que son accesibles desde afuera del subsistema. Estas interfaces las proporcionan o bien clases de diseño u otros subsistemas dentro del subsistema. Para definir inicialmente las interfaces, antes de conocer los contenidos de los subsistemas, debemos considerar hacia donde apunta las dependencias entre subsistemas. Cuando un subsistemas tiene una dependencia que apunta hacia el, es probable que CAL/Notación deba Modelo proporcionar del Negocio una interface.

Actividades: Diseño de la Arquitectura Interfaces en las dos capas superiores <<subsystem>> Gestion de facturas del comprador Recepcion Factura Capa especifica de la aplicación SolicitudPago <<subsistema de servicio>> Gestion de Planificacion de pagos Transferencia <<subsystem>> Gestion de cuentas Capa general de la aplicación

Actividades: Diseño de la Arquitectura

Actividades: Diseño de la Arquitectura Ejemplo: Diagrama de Distribución para el Sistema de Inscripción Este diagrama muestra dos nodos y los dispositivos con los que se comunica el Sistema de Inscripción Sistema de Inscripción Base de Datos Dormitorios <<device>> Edificio Principal <<device>> Biblioteca <<device>>