 ¡Por fin una descripción de la arquitectura! ¡Por fin una descripción de la arquitectura!  La vista de la arquitectura del modelo de casos de uso La.

Slides:



Advertisements
Presentaciones similares
MODELOS ORIENTADOS A OBJETOS
Advertisements

U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
Plan de Implantación Sistemas de Información III
Lenguaje Unificado de Modelado
Etapa Análisis-Diseño Uso de UML en el Desarrollo de Proyectos
ANÁLISIS DE REQUERIMIENTOS
Noveno Semestre UNIDEC
DISEÑO ORIENTADO AL OBJETO
Tecnologías Cliente / Servidor Capitulo III Richard Jiménez V. clienteserver.wordpress.com.
Guia Diseño Robert Echeverria
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
DESCRIPCION DEL PROBLEMA
Aspectos Avanzados de la Tecnología de Objetos
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Profesor: Miguel Angel Vidal
Creación del modelo de diseño a partir del modelo de análisis
DSOO - María Eugenia Valencia
PLANEACION DE UNA ESTRUCTURA ORGANIZACIONAL
UML Diagramas. Diagramas de Interacción Muestran como los objetos de la aplicación cooperan e interactúan para cumplir con los requisitos. Suele construirse.
Análisis, diseño e implementación para realizar los casos de uso
Modelado Arquitectónico
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
POP3 UCLV Mapas Conceptuales para la enseñanza de Redes de Computadoras.
Ingeniería de Software
Ingeniería de Software Orientado a Objetos
UNIDAD 3: “Desarrollo Orientado a Objetos con UML”
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
1 Diseño Orientado a Objetos Agustín J. González ELO-329: Diseño y Programación Orientados a Objetos 1er. Sem
Unidad VI Documentación
Desarrollo de aplicaciones para ambientes distribuidos
 Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y.
UNIDAD 2. ALGORITMOS Y ESTRUCTURAS DE DATOS.
DIAGRAMA DE DESPLIEGUE INTEGRANTES: ALVARADO ALIAGA ALDO JAVIER
CASOS DE USO Ing. Sonia Godoy H..
UML 2.0 Integrantes: Diana Carolina Valencia M. Jhon Fernando Lopez T. Carlos Alberto Castillo.
Vista de interacción  Una vista de interacción muestra el flujo de control requerido que se establece entre los objetos.
Ingeniería de software
¿Por qué Casos de Uso?.
Diagrama de Clases ACI 570.
1 Diseño Orientado al Objeto Agustín J. González ELO-326: Seminario de Computadores II 2do. Sem
TEMA 10: DIAGRAMA DE: OBJETOS, SECUENCIA Y DESPLIEGUE EN UML
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
“condición que necesita el usuario para resolver un problema o conseguir un objetivo determinado”. Los requisitos de un sistema son los aspectos que el.
DEFINICIÓN DE OBJETO Un objeto es aquello que puede ser observado, estudiado y aprendido CARACTERÍSTICAS nos permiten conocerlos mediante la observación,
Ingeniería de software
Diagramas de Interacción.
Programación Orientada a Objeto
 La arquitectura se desarrolla en iteraciones de la fase de elaboración La arquitectura se desarrolla en iteraciones de la fase de elaboración  Ejemplo.
Modelo de 3 capas.
D IRIGIDO POR C ASOS DE U SO. Í NDICE El Usuario Los Casos de Uso, su importancia El aspecto “dirigido-por-casos-de-uso” Todos los modelos se relacionan.
Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software UNIVERSIDAD PONTIFICIA DE SALAMANCA EN MADRID 1 Proceso.
INTRODUCCION AL ANALISIS Y DESARROLLO DE SISTEMAS DE SOFTWARE EQUIPO NUMERO CUATRO INTEGRADO POR: XAVIER REFUGIO GARY NERY HERNANDEZ OSCAR JUAREZ.
PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO
Prof. Joel Moreno Molina
Proceso de Diseño de Interfaces
Unified Modeling Language (Lenguaje de Modelamiento unificado)
UNIDAD 2: “Características del Modelado UML” CONTENDIDO Elaborado por: Ingeniero Harold Cabrera Meza Actualizado por: Ingeniero Nilson Albeiro Ferreira.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Proceso de desarrollo de Software
1 Tema 2: Introducción al proceso unificado de desarrollo de software.
DIAGRAMAS DE SECUENCIA. UML está compuesto por los siguientes diagramas:
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
Requerimientos del software
Lenguaje Unificado de Modelado (UML) Julio … Casos de Uso  Ejemplo:
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Entregables del Proyecto
Transcripción de la presentación:

 ¡Por fin una descripción de la arquitectura! ¡Por fin una descripción de la arquitectura!  La vista de la arquitectura del modelo de casos de uso La vista de la arquitectura del modelo de casos de uso  La vista de la arquitectura del modelo de diseño La vista de la arquitectura del modelo de diseño  La vista de la arquitectura del modelo de despliegue La vista de la arquitectura del modelo de despliegue  La vista de la arquitectura del modelo de implementación La vista de la arquitectura del modelo de implementación  ¿Qué es una arquitectura? ¿Qué es una arquitectura?  ¿Cómo se obtiene la Arquitectura ? ¿Cómo se obtiene la Arquitectura ?  ¿Cómo se describe la Arquitectura ? ¿Cómo se describe la Arquitectura ?

Hemos estado hablando bastante tiempo sobre lo que es la arquitectura sin ofrecer un ejemplo significativo. Presentamos ahora un ejemplo concreto de la apariencia de una descripción de arquitectura. Sin embargo, antes tenemos que explicar por qué no es fácil hacerlo. Recuérdese que la descripción de la arquitectura es sencillamente un extracto adecuado de los modelos del sistema (es decir, no añade nada nuevo). La primera versión de la descripción de la arquitectura es un extracto de la versión de los modelos que tenemos al término de la fase de elaboración en el primer ciclo de vida. Dado que no intentarnos hacer una reescritura más legible de esos extractos, la descripción de la arquitectura se parece mucho a los modelos normales del sistema. Esta apariencia significa que la vista de la arquitectura del modelo de casos de uso es muy parecida a un modelo de casos de uso normal.

La única diferencia reside en que la vista de la arquitectura sólo contiene los casos de uso significativos para la arquitectura (Sección ), mientras que el modelo de casos de uso final contiene todos los casos de uso. Lo mismo ocurre con la vista de la arquitectura del modelo de diseño. Es igual que un modelo de diseño, pero sólo representa los casos de uso que.son interesantes para la arquitectura. Otra razón por la cual es difícil ofrecer un ejemplo es que sólo es interesante hablar de la arquitectura en sistemas reales, y cuando queremos hablar aquí sobre un sistema en detalle, debe ser por necesidad un sistema pequeño. Sin embargo, vamos a emplear el ejemplo del CA del Capítulo 3 para ilustrar lo que podrían llevar las vistas de la arquitectura. Lo haremos comparando lo que debería estar en las vistas y lo que debería estar en los modelos completos del sistema.

La descripción de la arquitectura tiene cinco secciones, una para cada modelo. tiene una vista del modelo de casos de uso una vista del modelo de análisis (que no siempre se mantiene), una vista del modelo de diseño, una vista del modelo de despliegue, y una vista del modelo de implementación. No incluye una vista del modelo de prueba porque no desempeña ningún papel en la descripción de la arquitectura, y sólo se utiliza para verificar la línea base de la arquitectura. Regresar

 La vista de la arquitectura del modelo de casos de uso presenta los actores y casos de uso más importantes (o escenarios de esos casos de uso). Sección 3.3.  “La captura de casos de uso”, en lo relativo al modelo de casos de uso del sistema de CA.

En el ejemplo del CA, el caso de uso más importante es Sacar Dinero. Sin él, no existiría un verdadero sistema de CA. Los casos de uso Ingresar Dinero y Transferencia entre Cuentas se consideran menos importantes para un cliente de banco normal. Para definir la arquitectura, el arquitecto sugiere por tanto que el caso de uso Sacar Dinero se implemente en su totalidad durante la fase de elaboración, pero ningún otro caso de uso (o parte de caso de uso) se considera interesante para la arquitectura. (En la práctica, esta decisión podría ser un poco precipitada, pero la utilizamos para los propósitos de esta explicación.) La vista de la arquitectura del modelo de casos de uso debería por tanto, mostrar la descripción completa del caso de uso Sacar Dinero. Regresar

La vista de la arquitectura del modelo de diseño presenta los clasificadores más importantes para la arquitectura pertenecientes al modelo de diseño: Los subsistemas e interfaces más importantes, así como algunas pocas clases muy importantes, fundamentalmente las clases activas. También presenta cómo se realizan los casos de uso en términos de esos clasificadores, por medio de realizaciones de casos de uso. Las clases activas también las trataremos en la Sección cuando hablemos del modelo de despliegue (en el cual las clases activas se asignan a nodos).

En la Sección 3.4.3, identificamos tres clases activas: Gestor de Clientes, Gestor de Transacciones, y Gestor de Cuentas (Figura 4.7). Estas clases activas se incluyen en la vista de la arquitectura del modelo de diseño. Además, en la Sección 3.4.4, se describieron los tres subsistemas: Interfaz del CA, Gestión de Transacciones, y Gestión de Cuentas: Figura 4.8. Estos subsistemas son necesarios para la realización del caso de uso Sacar Dinero, por lo cual son subsistemas significativos para la arquitectura. El modelo de diseño incluye muchos otros subsistemas, pero no los consideramos.

El subsistema Interfaz del CA se encarga de todas las entradas y salidas del cliente del banco, tales como la impresión de los recibos y la recepción de los comandos del cliente. El subsistema de Gestión de Cuentas mantiene toda la información persistente sobre las cuentas, y se utiliza en todas las transacciones relativas a ellas. El subsistema de Gestión de Transacciones contiene las clases para el comportamiento específico de los casos de uso, como el comportamiento especifico del caso de uso Sacar Dinero. En el ejemplo de la Sección 3.4.4, dijimos que las clases específicas de los casos de uso acaban a menudo en distintos subsistemas de servicio, como los subsistemas de servicio para cada una de las clases Retirada de Efectivo, Transferencia e Ingreso dentro del subsistema de Gestión de Transacciones (no se muestran en la Figura 4.8). En realidad, cada uno de esos subsistemas de servicio contiene normalmente varias clases, pero nuestro ejemplo es muy sencillo.

Los subsistemas de la Figura 4.8 proporcionan comportamiento unos a otros mediante interfaces, como la interfaz Transferencias que proporciona la Gestión de Transacciones. Las interfaces Transferencias, Retirada, y Entrega se describen en la Sección También tenemos interfaces Transferir, Depósitos, e Historia, pero no se ven implicadas en el caso de uso que tratamos en este ejemplo, por lo que no las hemos explicado. No basta con la estructura estática. También tenemos que mostrar cómo se llevan a cabo, por parte de los subsistemas del modelo de diseño, los casos de uso significativos para la arquitectura. Por tanto, describiremos una vez más el caso de uso Sacar Dinero, esta vez en términos de subsistemas y actores que interactúan utilizando un diagrama de colaboración, como se muestra en la Figura 4.9.

Los objetos de las clases que poseen los subsistemas interactúan unos con otros para ejecutar una instancia de un caso de uso. Los objetos se envían mensajes; el diagrama muestra estos intercambios. Los mensajes llevan nombres que especifican operaciones contenidas en las interfaces de los subsistemas. Esto se indica mediante la notación :: (por ejemplo, Retirada::realizar(cantidad, cuenta), donde Retirada es una interfaz proporcionada por una clase dentro del subsistema de Gestión de Transacciones).

La siguiente lista explica brevemente el flujo de la ejecución del caso de uso. El texto es casi el mismo que el de la Sección (la descripción de la ejecución del caso de uso), pero aquí lo presentamos en términos de subsistemas en lugar de clases. Precondición: El cliente del banco tiene una cuenta bancaria válida para el CA. El actor Cliente de Banco selecciona sacar dinero y se identifica en la Interfaz del CA, quizás a través de una tarjeta de banda magnética, mediante un número y una contraseña. El Cliente de Banco también indica la cantidad a retirar y de qué cuenta hacerlo. Suponemos que el subsistema Interfaz de CA es capaz de verificar la identidad. La Interfaz de CA solicita al subsistema de Gestión de Transacciones que retire el dinero. Este subsistema es responsable de llevar a cabo la secuencia entera de retirada a modo de transacción atómica, de manera que el dinero se deduce de la cuenta y también se entrega al Cliente de Banco.

Gestión de Transacciones solicita al subsistema Gestión de Cuentas que retire el dinero. El subsistema Gestión de Cuentas decide si puede retirarse el dinero y, si es así, deduce la suma de la cuenta y devuelve una respuesta que indica que es posible ejecutar la retirada. Gestión de Transacciones autoriza al Interfaz de CA a entregar el dinero. Interfaz de CA entrega el dinero al Cliente de Banco. Regresar

El modelo de despliegue define la arquitectura física del sistema por medio de nodos interconectados. Estos nodos son elementos hardware sobre los cuales pueden ejecutarse los elementos software. Con frecuencia conocemos cómo será la arquitectura física del sistema antes de comenzar su desarrollo. Por tanto, podemos modelar los nodos y las conexiones del modelo de despliegue tan pronto como comience el flujo de trabajo de los requisitos. Durante el diseño, decidiremos qué clases son activas, es decir, son hilos o procesos.

Determinaremos lo que debería hacer cada clase activa, cómo debería ser el ciclo de vida de cada una de ellas, y cómo deberían comunicarse, sincronizarse, y compartir información. Los objetos activos se asignan a los nodos del modelo de despliegue. Al hacer esta asignación, debemos considerar la capacidad de los nodos, como su capacidad de proceso y tamaño de memoria, y las características de las conexiones, como el ancho de banda y la disponibilidad. Los nodos y conexiones del modelo de despliegue y la asignación de los objetos activos a los nodos pueden mostrarse en diagramas de despliegue. Estos diagramas también pueden mostrar cómo se asignan los componentes ejecutables a los nodos. El sistema de CA de nuestro ejemplo se distribuye en tres nodos distintos.

El Cliente de Banco accede al sistema a través del nodo Cliente CA, que accede al Servidor cié Aplicaciones CA para realizar las transacciones (Figura 4.10). El Servidor de Aplicaciones CA utiliza, a su vez, al Servidor de Datos CA para ejecutar transacciones concretas sobre cuentas, por ejemplo. Esto es así no sólo para el caso de uso Sacar Dinero, que hemos clasificado como significativo para la arquitectura, sino también para los demás casos de uso, como Ingresar Dinero y Transferir entre Cuentas. En la Sección 3.4.3, describimos qué clases habíamos seleccionado para llevar a cabo el caso de uso Sacar Dinero. Cuando se han definido los nodos, podemos distribuir la funcionalidad sobre ellos. Por sencillez, lo haremos distribuyendo cada subsistema (véase la Figura 4,8) como un todo a un único nodo. El subsistema Interfaz de CA se implanta sobre el nodo Cliente CA, el subsistema Gestión de Transacciones sobre el Servidor de Aplicaciones CA, y el subsistema de Gestión de Cuentas sobre el Servidor de Datos CA.

En consecuencia, cada clase activa dentro de estos subsistemas (véase la Sección y la Figura 3,10) se implanta en su correspondiente nodo —mediante un proceso ejecutándose sobre el mismo—. Cada uno de estos procesos gestiona, y mantiene en su espacio de direcciones, objetos del resto de las clases dentro del subsistema (clases ordinarias, no activas). La Figura 4.11 muestra la distribución de los objetos activos. Éste es un ejemplo simplista de distribución de un sistema. En un sistema real, la distri­bución es por supuesto más compleja. Una solución alternativa al problema de la distribución habría sido el uso de alguna capa intermedia para la distribución de objetos como un object request broker (ORE).

Regresar

El modelo de implementación es una correspondencia directa de los modelos de diseño y de despliegue. Cada subsistema de servicio del diseño normalmente acaba siendo un componente por cada tipo de nodo en el que deba instalarse —pero no siempre es así—. A veces el mismo componente (por ejemplo, el componente de gestión de buffers) puede instanciarse y ejecutarse sobre varios nodos. Hay lenguajes que proporcionan construcciones para el empaquetado de los componentes, como es el caso de los JavaBeans. En otros casos, las clases se organizan en ficheros con el código que representa los diferentes componentes.

En la Sección 3.4.5, indicarnos que el subsistema de servicio Gestión de Retiradas posiblemente podría implementarse mediante dos componentes, “Retirada en Servidor”, y “Retirada en Cuente”. El componente “Retirada en Servidor’ podría implementar la clase Retirada de Efectivo, y “Retirada en Cliente” podría implementar una clase Proxy de Retirada. En nuestro ejemplo sencillo, estos componentes sólo imple mentarían una clase cada uno. En un sistema real, habría varias clases más en cada subsistema de servicio, de forma que un componente podría implementar varias clases. Regresar

Es lo que especifica el arquitecto en la descripción de la arquitectura. La descripción de la arquitectura permite al arquitecto controlar el desarrollo del sistema desde la perspectiva técnica. La arquitectura software se centra tanto en los elementos estructurales significativos del sistema, como subsistemas, clases, componentes y nodos, como en las colaboraciones que tienen lugar entre estos elementos a través de las interfaces. Los casos de uso dirigen la arquitectura para hacer que el sistema proporcione la funcionalidad y uso deseados, alcanzando a la vez, objetivos de rendimiento razonables. Una arquitectura debe ser completa, pero también debe ser suficientemente flexible como para incorporar nuevas funciones, y debe soportar la reutilización del software existente. Regresar

La arquitectura se desarrolla de forma iterativa durante la fase de elaboración pasando por los requisitos, el análisis, el diseño, la implementación y las pruebas. Utilizamos los casos de uso significativos para la arquitectura y un conjunto de otras entradas para implementar la línea base de la arquitectura, o “esqueleto” del sistema. Ese conjunto de entradas incluye requisitos del software del sistema, middleware, qué sistemas heredados deben utilizarse, requisitos no funcionales, y demás. Regresar

La descripción de la arquitectura es una vista de los modelos del sistema, de los modelos de casos de uso, análisis, diseño, implementación y despliegue. La descripción de la arquitectura describe las partes del sistema que es importante que comprendan todos los desabolladores y otros interesados. Regresar