1 / 138

Tutorial. UML y Proceso Unificado en Informática Biomédica

VII CONGRESO NACIONAL DE INFORMÁTICA DE LA SALUD Madrid, 24-26 de marzo de 2004. Tutorial. UML y Proceso Unificado en Informática Biomédica. Òscar Coltell , y Miguel Arregui. Grupo de Integración y Re-Ingeniería de Sistemas (IRIS) Departamento de Lenguajes y Sistemas Informáticos

karl
Download Presentation

Tutorial. UML y Proceso Unificado en Informática Biomédica

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. VII CONGRESO NACIONAL DE INFORMÁTICA DE LA SALUD Madrid, 24-26 de marzo de 2004 Tutorial.UML y Proceso Unificado en Informática Biomédica Òscar Coltell, y Miguel Arregui Grupo de Integración y Re-Ingeniería de Sistemas (IRIS) Departamento de Lenguajes y Sistemas Informáticos Universitat Jaume I

  2. CONTENIDOGENERAL Parte I: Introducción a UML. Parte II: Introducción al Proceso Unificado.

  3. Parte I:Introducción a UML Miguel Arregui

  4. PARTE I. CONTENIDO • Objetivos. • Introducción. • La Orientación a Objetos, OO. • El Lenguaje Unificado de Modelado. (Elementos, Relaciones, Diagramas). • Cómo utilizar UML. • Bibliografía.

  5. 1. Objetivos: • Introducir los conceptos que maneja UML • Ser una útil toma de contacto con UML para • Conocer sus posibilidades • Decidir si incluirlo en el arsenal de desarrollo • Ser breve, conciso y no entrar en excesivos detalles • Describir cómo emplear UML en un proyecto 1.1. Objetivos

  6. 2. Introducción: Problema: Actualmente, Software Grande y Complejo. Demanda de interfaces más completas, funcionalidades más elaboradas  Impacto en complejidad del producto. Requisitos: Los programas deben poder ser mantenidos y ampliados con garantías de éxito. Solución: Estructuración, modelado. 2.1. Introducción

  7. 2. Introducción: Ante problemas complejos  Divide y vence  Estructura Modela Modelar es diseñar y estructurar, antes de programar. Sirve para visualizar un diseño y especificar su estructura y comportamiento. Se abstraen los detalles del problema complejo simplificando su desarrollo. 2.2. Introducción

  8. 2. Introducción: UML es un lenguaje gráfico para: Modelar, diseñar, estructurar, visualizar, especificar y documentar Software. Proporciona vocabulario común a la cadena de producción. Es un estándar para crear planos completos y no ambiguos. Creado por el OMG y usado por NASA, ESA, EBI, W3C... 2.3. Introducción

  9. 3. La Orientación a Objetos, OO: UML está muy cerca de este paradigma. Objeto: Intuitivamente todo lo que tiene masa, aunque también hay objetos no tangibles. En informática, definen representaciones abstractas de entidades del mundo, tangibles o no, con la intención de emularlas. Objetos mudo real  Objetos informáticos 3.1. La Orientación a Objetos

  10. 3. La Orientación a Objetos, OO: Los objetos se caracterizan por su estado y comportamiento. Estado: Situación en que se encuentra un objeto, tal que cumple alguna condición/es particulares, realiza una actividad o espera que suceda un acontecimiento. Los objetos mantienen su estado en uno o mas atributos. Atributo: Dato identificado por un nombre. 3.2. La Orientación a Objetos

  11. 3. La Orientación a Objetos, OO: Los objetos exhiben su comportamiento a través de métodos. Método: Trozos de funcionalidad asociados al objeto. Objeto  Conjunto de Atributos y Métodos 3.3. La Orientación a Objetos

  12. 3. La Orientación a Objetos, OO: Los objetos revelan su utilidad en un contexto de comunicación con otros objetos, por medio del paso de mensajes, para componer un sistema con un comportamiento más complejo que el suyo propio. 3.4. La Orientación a Objetos

  13. 3. La Orientación a Objetos, OO: El envío de mensajes es la forma en que se invoca los comportamientos de un objeto (cada método define un comportamiento). La invocación de métodos permite a un objeto cambiar su estado o el de otro objeto. Los detalles internos del objeto quedan ocultos para los Demás objetos  Encapsulación. 3.5. La Orientación a Objetos

  14. 3. La Orientación a Objetos, OO: Clase: Son patrones que definen qué atributos y qué métodos son comunes a un conjunto de objetos, que pertenecen a dicha clase. Es más fácil de entenderlo si se toma tipo como equivalente. Todos los objetos del mismo tipo comparten el mismo juego de atributos y métodos y, por tanto, pertenecen a la misma clase. 3.6. La Orientación a Objetos

  15. 3. La Orientación a Objetos, OO: Cada objeto tiene sus atributos y sus métodos, empleando una clase como patrón. Una vez creado el objeto pasa a ser una instancia particular de la clase a la que pertenece. Dos objetos distintos de la misma clase pueden tener el mismo valor en todos sus atributos. Estos atributos que pueden variar de instancia a instancia se conocen como variables de instancia. 3.7. La Orientación a Objetos

  16. 3. La Orientación a Objetos, OO: Hay atributos que no varían de una instancia a otra. Todas las instancias de la clase tienen el mismo valor. Estos atributos que no varían de instancia a instancia se conocen como variables de clase. De manera análoga hay métodos de instancia y métodos de clase. 3.8. La Orientación a Objetos

  17. 3. La Orientación a Objetos, OO: Herencia: Los objetos se definen a partir de clases. Se puede saber mucho de un objeto sabiendo a qué clase pertenece. Las clases permiten su definición a partir de otras clases. Esto permite definir una jerarquía de especialización. Una Clase definida a partir de otra, hereda todos los atributos y métodos de su clase ancestro. Las clases herederas pueden sobrescribir los atributos y los métodos heredados y pueden añadir nuevos. 3.9. La Orientación a Objetos

  18. 3. La Orientación a Objetos, OO: La clase tomada como patrón se conoce como Superclase o clase padre, mientras que la heredera se llama clase hija. La jerarquía de herencia puede ser todo lo profunda que sea necesario. Una clase puede tener varias clases como patrón. 3.10. La Orientación a Objetos

  19. 3. La Orientación a Objetos, OO: Interfaces: Mecanismo que emplean dos objetos para interactuar. Definen un conjunto de métodos para establecer el protocolo en base al que interactúan dos objetos. Interfaces  Protocolos Las interfaces capturan similitudes entre clases no relacionadas. Son clases a su vez. 3.11. La Orientación a Objetos

  20. 4. El Lenguaje Unificado de Modelado 4.1. El UML

  21. 4. El Lenguaje Unificado de Modelado: UML es un lenguaje para modelar. Su vocabulario y sintaxis están ideados para la representación conceptual y física de un sistema. Sus modelos son precisos, no ambiguos y se pueden trasladar a una gran variedad de lenguajes de programación, como Java, C++, visual basic, pero también a tablas de bases de datos relacionales y orientadas a objetos. 4.2. El UML

  22. 4. El Lenguaje Unificado de Modelado: Ingeniería directa: Es posible generar código a partir de un modelo UML. Ingeniería inversa: Es posible generar un modelo UML a partir de la implementación. En ambos casos se requiere mayor o menor supervisión, en función de lo buenas que sean las herramientas usadas. 4.3. El UML

  23. 4. El Lenguaje Unificado de Modelado: UML tiene tres bloques básicos de construcción, elementos, relaciones y diagramas. Elementos: Unidades básicas de construcción, cuatro tipos: • Estructurales: Partes estáticas de los modelos, representan aspectos conceptuales o materiales. • De comportamiento: Partes dinámicas de los modelos, representan comportamientos en el tiempo y espacio. • De agrupación: Partes organizativas de los modelos. • De Notación: Partes explicativas de los modelos. 4.4. El UML

  24. 4. El Lenguaje Unificado de Modelado: Elementos estructurales: Describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces. Clase Se trata de una clase, en la que existe procesos o hilos de ejecución concurrentes con otros elementos. Las líneas del contorno son más gruesas que en la clase “normal”. Clase activa 4.5. El UML

  25. 4. El Lenguaje Unificado de Modelado: Elementos estructurales: Agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un círculo para representar las interfaces, aunque lo más normal es emplear la clase con el nombre en cursiva. Define una interacción entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos. 4.6. El UML

  26. 4. El Lenguaje Unificado de Modelado: Elementos estructurales: Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de interés. Se emplea para estructurar los aspectos de comportamiento de un modelo. Parte física y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos. Elemento físico que existe en tiempo de ejecución y representa un recurso computacional con capacidad de procesar. 4.7. El UML

  27. 4. El Lenguaje Unificado de Modelado: Elementos de comportamiento: Comprende un conjunto de mensajes que se intercambian entre un conjunto de objetos, para cumplir un objetivo especifico. Especifica la secuencia de estados por los que pasa un objeto o una interacción, en respuesta a eventos. 4.8. El UML

  28. 4. El Lenguaje Unificado de Modelado: Elementos de agrupación: Se emplea para organizar otros elementos en grupos. Elementos de notación: Partes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo. 4.9. El UML

  29. 4. El Lenguaje Unificado de Modelado: Relaciones: Abstracciones que actúan de unión entre los elementos. Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro. Dependencia Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos. Asociación Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento. Generalización Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces). Realización 4.10. El UML

  30. 4. El Lenguaje Unificado de Modelado: Diagramas: Disponen un conjunto de elementos, que representan el modelo desde distintas perspectivas. UMLtiene nueve diagramas fundamentales, clasificados en dos grupos, uno para modelar la estructura estática del sistema y otro para modelar el comportamiento dinámico. Diagramas estáticos:Clases, Objetos, componentes y despliegue. Diagramas dinámicos:Casos de Uso, secuencia, colaboración, estados y actividades. 4.11. El UML

  31. 4. El Lenguaje Unificado de Modelado: Diagrama de Clases: Muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Las clases abstractas tienen su nombre en itálica.Son interfaces. Las flechas navegables son asociaciones navegables que expresan el sentido en que se consultan los datos. El Resto son asociaciones bidireccionales. 4.12. El UML

  32. Multiplicidad Significado 1 Una única instancia N / * N instancias 0..N / 0..* Entre ninguna y N instancias 1..N / 1..* Entre una y N instancias 0..1 Ninguna o una instancia N..M Entre N y M instancias 4. El Lenguaje Unificado de Modelado: Diagrama de Clases: Las relaciones pueden traer asociada una multiplicidad, expresada “en el lado opuesto” de la relación. Resume el número de posibles instancias de una clase asociadas a una única instancia de la clase en el otro extremo. 4.13. El UML

  33. 4. El Lenguaje Unificado de Modelado: Diagrama de Clases: En las relaciones de dependencia un cambio en la clase dependida afectará la clase dependiente. Compartimentos de la clase: primero nombre segundo  atributos tercero  métodos Acceso de atributos y métodos: “+”  público “-”  privado (sólo los métodos), “#”  protegido (sólo clases hija). Argumentos: nombre:tipo [=val] (, nombre:tipo[=val])* Los atributos y métodos estáticos (de clase) se representan mediante un subrayado. Los métodos pueden emplear el estereotipo <<static>>. 4.14. El UML

  34. 4. El Lenguaje Unificado de Modelado: Diagrama de Clases: Relación de auto agregación. Un departamento puede estar compuesto por varios sub departamentos, o ninguno, con la restricción de que el mínimo número de personas en los sub departamentos debe ser dos. En UML las restricciones se expresan mediante llaves “{condicion a cumplir siempre}”. Diagrama de Objetos: Los diagramas de objetos son análogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar partes pequeñas del modelo en las que hay relaciones complejas 4.15. El UML

  35. 4. El Lenguaje Unificado de Modelado: Diagrama de Componentes: Un componente es un módulo de código, de modo que los diagramas de componentes son los análogos físicos a los diagramas de clases. Muestran la organización y dependencias de un conjunto de componentes. Cubren la vista de implementación estática de un sistema. 4.16. El UML

  36. 4. El Lenguaje Unificado de Modelado: Diagrama de Despliegue: Los diagramas de despliegue sirven para modelar la configuración hardware del sistema, mostrando qué nodos lo componen 4.17. El UML

  37. 4. El Lenguaje Unificado de Modelado: Diagrama de Casos de Uso: Describen lo que hace el sistema desde el punto de vista de un observador externo. Enfatizan el qué en lugar del cómo. Plantean escenarios, lo que pasa cuando alguien interactúa con el sistema. Proporcionan un resumen para una objetivo. Los Actores son papeles que determinadas personas u objetos desempeñan. Las líneas que unen los Actores con los Casos de Uso (óvalos) representan una asociación de comunicación. 4.18. El UML

  38. 4. El Lenguaje Unificado de Modelado: Diagrama de Casos de Uso: Los Casos de Uso pueden explosionarse para describir en mayor profundidad. “Carlos tuesta el pan en la tostadora, después lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojándolo en un café.” “Carlos calienta leche, añade café y azúcar al gusto y se lo bebe.” Los Casos de Uso pueden acompañarse de texto que enriquezca el lenguaje gráfico. 4.19. El UML

  39. 4. El Lenguaje Unificado de Modelado: Diagrama de Casos de Uso: frontera estereotipo generalización Paralelo, orden irrelevante 4.20. El UML

  40. 4. El Lenguaje Unificado de Modelado: Diagrama de Secuencia: Describen cómo los objetos del sistema colaboran. Detalla cómo las operaciones se llevan a cabo en términos de qué mensajes son enviados y cuando (en torno al tiempo). tiempo Los corchetes expresan condición [condición]. Si son precedidos por “*”  iteración mientras. Línea de vida obj. Su vida termina. Orden participación 4.21. El UML

  41. 4. El Lenguaje Unificado de Modelado: Diagrama de Secuencia: Los rectángulos verticales son barras de activación. Representan la duración de la ejecución del mensaje. Mensaje asíncronos: El emisor puede enviar otros mientras éste está siendo procesado. Es independiente a otros mensajes. Mensaje síncronos: El emisor debe esperar que termine el tiempo de proceso de éste para enviar nuevos mensajes. Mensaje simple puede ser síncrono o asíncrono Mensaje simple de vuelta (opt) Síncrono Asíncrono 4.22. El UML

  42. 4. El Lenguaje Unificado de Modelado: Diagrama de Colaboración: Son otro tipo de diagramas de interacción. Contienen la misma información que los diagramas de secuencia, pero se centran en la responsabilidad de cada objeto en lugar de en el tiempo en que los mensajes son enviados Cada mensaje tiene un número de secuencia. El primer nivel comienza en 1, los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 ... 1.i, tantos niveles como sea necesario. 4.23. El UML

  43. 4. El Lenguaje Unificado de Modelado: Diagrama de Estados: Muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición. Resultado de actividad Circunstancia o condición que provoca la transición inicio acción fin 4.24. El UML

  44. 4. El Lenguaje Unificado de Modelado: Diagrama de Estados: Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto. Puede ser necesario cuando una actividad involucra actividades concurrentes o asíncronas. 4.25. El UML

  45. 4. El Lenguaje Unificado de Modelado: Diagrama de Actividades: Son diagramas de flujo adornados, con mucha similitud a los diagramas de estados. Mientras los diagramas de estados centran su atención en el proceso que lleva a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. 4.26. El UML

  46. 5. Cómo utilizar UML: UML es simplemente un lenguaje. Define un conjunto de elementos y las relaciones entre ellos y esto se emplea para definir modelos. UML se usa típicamente como parte de un proceso de desarrollo, con ayuda de una herramienta CASE. UML es independiente de cualquier proceso particular, no Está ligado a ningún ciclo de vida de desarrollo de software concreto. 5.1. Cómo Utilizar UML

  47. 5. Cómo utilizar UML: UML proporciona mayores beneficios si se selecciona un proceso dirigido por Casos de Uso, centrado en la arquitectura y sea incremental. Dirigido por Casos de Uso: Los Casos de Uso son básicos Para establecer el comportamiento deseado del sistema, para verificarlo, para validar su arquitectura y para comunicarse Con todas las personas involucradas en el proyecto. 5.2. Cómo Utilizar UML

  48. 5. Cómo utilizar UML: Centrado en la arquitectura: La arquitectura de un sistema es el conjunto de decisiones significativas que se toma en torno a su organización, la selección de elementos estructurales, la definición de las interfaces entre estos elementos, su comportamiento, su división en subsistemas, qué elementos son estáticos y cuales dinámicos. La arquitectura también incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas, las temporales, los compromisos entre alternativas y los aspectos estéticos. 5.3. Cómo Utilizar UML

  49. 5. Cómo utilizar UML: Procesoincremental: aquél que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a partir de una línea básica. Cada incremento resuelve los problemas encontrados en la versión anterior minimizando progresivamente los riesgos más significativos para el éxito del proyecto. 5.4. Cómo Utilizar UML

  50. 5. Cómo utilizar UML: Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a seguir. El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas 5.5. Cómo Utilizar UML

More Related