Presentacion uml dian1_2003

5,612 views
5,455 views

Published on

sistemas, informacion

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,612
On SlideShare
0
From Embeds
0
Number of Embeds
148
Actions
Shares
0
Downloads
319
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Presentacion uml dian1_2003

  1. 1. Lenguaje Unificado de Modelado
  2. 2. <ul><li>Introducción </li></ul><ul><li>Diagramas UML </li></ul><ul><ul><li>Clasificación </li></ul></ul><ul><ul><ul><li>Diagramas de Estructura </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Comportamiento </li></ul></ul></ul><ul><ul><li>Vista y Diagramas </li></ul></ul><ul><ul><ul><li>Elementos Generales </li></ul></ul></ul><ul><ul><ul><li>Vista de Usuario </li></ul></ul></ul><ul><ul><ul><ul><li>Diagramas de casos de Uso </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Escenarios de los Casos de Uso </li></ul></ul></ul></ul>AGENDA <ul><li>Vista Estructural </li></ul><ul><ul><li>Representación de clases y Objetos </li></ul></ul><ul><ul><ul><li>Notación </li></ul></ul></ul><ul><ul><ul><li>Asociaciones y Enlaces </li></ul></ul></ul><ul><ul><ul><li>Asociaciones y Multiplicidad </li></ul></ul></ul><ul><ul><ul><li>Asociaciones Complejas </li></ul></ul></ul><ul><ul><ul><li>Relaciones Lógicas </li></ul></ul></ul><ul><ul><ul><ul><li>Herencia </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Polimorfismo </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Agregación </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Propagación y Delegación </li></ul></ul></ul></ul><ul><ul><ul><li>Clases Abstractas e interfaces </li></ul></ul></ul>
  3. 3. <ul><li>Vista de Comportamiento (Modelo dinámico) </li></ul><ul><ul><li>Diagramas de Secuencia </li></ul></ul><ul><ul><li>Diagramas de Colaboración </li></ul></ul><ul><ul><li>Diagramas de Estado </li></ul></ul><ul><ul><li>Diagramas de Actividad </li></ul></ul><ul><li>Vista de Implementación </li></ul><ul><ul><li>Diagramas de Componentes </li></ul></ul><ul><ul><li>Cohesion y Coupling </li></ul></ul><ul><li>Vista de Ambiente </li></ul><ul><ul><li>Diagramas de Despliegue </li></ul></ul>AGENDA
  4. 4. Introducción a UML Lenguaje Unificado de Modelado
  5. 5. Modelado <ul><li>En la gestión del proceso de software : </li></ul><ul><li>Construimos modelos para comunicar la arquitectura y el comportamiento deseado del sistema. </li></ul><ul><li>Construimos modelos para visualizar y controlar la arquitectura del sistema. </li></ul><ul><li>Construimos modelos para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificación y reutilización. </li></ul><ul><li>En general se puede decir que construimos modelos para minimizar el riesgo: </li></ul><ul><ul><li>Los modelos nos ayudan a visualizar como es que queremos que sea un sistema </li></ul></ul><ul><ul><li>Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. </li></ul></ul><ul><ul><li>Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema </li></ul></ul><ul><ul><li>Los modelos documentan la decisiones que hemos adoptado </li></ul></ul>
  6. 6. Modelado <ul><li>Un modelo es básicamente una abstracción que incluye lo esencial de un problema complejo o estructura, filtrando los detalles no esenciales, de forma que el problema se hace más compresible. </li></ul><ul><li>Los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos </li></ul><ul><li>La importancia de la realización de un modelado formal es que las bases del modelado son comunes lo que conlleva a una comunicación no ambigua entre los individuos que forman parte del proyecto e incluso con los usuarios. </li></ul><ul><li>Siendo un modelo una abstracción de la realidad, dicha simplificación no es única, muy al contrario todo sistema debería ser visto desde diferente perspectivas utilizando diferentes modelos. </li></ul><ul><li>UML nos permite la construcción de diferentes modelos del mismo sistema de software . </li></ul>
  7. 7. Triangulo de éxito de la ejecución de un proyecto de software ALCANCE PROCESO HERRAMIENTA EXITO NOTACION COSTO TIEMPO C
  8. 8. <ul><li>Lenguaje Unificado de Modelado </li></ul><ul><li>UML Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad </li></ul><ul><li>E s un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos un sistema de software. </li></ul><ul><li>UML ofrece un estándar para describir un &quot;plano&quot; del sistema (modelo). </li></ul><ul><li>UML incluye: </li></ul><ul><ul><li>Aspectos conceptuales tales como procesos de negocio y funciones del sistema </li></ul></ul><ul><ul><li>Aspectos concretos como expresiones de lenguajes de programación </li></ul></ul><ul><ul><li>Esquemas de bases de datos </li></ul></ul><ul><ul><li>Componentes reutilizables. </li></ul></ul>
  9. 9. <ul><li>Para comprender qué es el UML, basta con analizar cada una de las palabras que lo componen, por separado </li></ul><ul><ul><li>Lenguaje: E l UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación. </li></ul></ul><ul><ul><li>Modelado: E l UML es visual, mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste. </li></ul></ul><ul><ul><li>Unificado : Unifica varias técnicas de modelado en una única. Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto modelado orientado a objetos. </li></ul></ul>
  10. 10. <ul><li>Lenguaje Unificado de Modelado </li></ul><ul><li>Se puede aplicar en el desarrollo de software </li></ul><ul><li>Ofrece gran variedad de formas para dar soporte a una metodología de desarrollo de software (como el Proceso Unificado Racional o RUP ) </li></ul><ul><li>UML no es un lenguaje de programación </li></ul><ul><li>Es un conjunto de diagramas que pueden ser usados para especificar, construir, visualizar y documentar diseños de software. </li></ul><ul><li>UML no es un proceso de cómo hacer análisis y diseño, UML solo es un conjunto de herramientas que se usan en el proceso. </li></ul><ul><li>Fue creado con el objetivo de crear un nuevo estándar para el modelamiento de software. </li></ul>
  11. 11. <ul><li>Breve Reseña Histórica </li></ul><ul><li>Las raíces del UML provienen de tres metodologías de análisis y diseño OO distintas: </li></ul><ul><ul><li>El metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones. </li></ul></ul><ul><ul><li>La Técnica de Modelado Orientada a Objetos de James Rumbaugh (OTM Object-Modeling-Tecnique) </li></ul></ul><ul><ul><li>Aproximación “Objetory”, de Ivar Jacobson. (OOSE: Object Oriented Software Engineering) mediante la metodología de Casos de Uso. </li></ul></ul><ul><li>Booch, Rumbaugh y Jacobson dieron forma a la primera versión del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versión v1.1 del UML. </li></ul><ul><li>Desde entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la versión actual: UML 2.0. </li></ul><ul><li>La especificación de UML se puede encontrar en el web site de Object Management Group (OMG) http://www.omg.org/uml/. </li></ul>
  12. 12. <ul><li>Breve Reseña Histórica </li></ul><ul><li>¿Qué es la OMG? </li></ul><ul><li>La OMG (Object Management Group) </li></ul><ul><li>Es una asociación sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: </li></ul><ul><ul><li>IBM, </li></ul></ul><ul><ul><li>Apple Computer, </li></ul></ul><ul><ul><li>Sun Microsystems Inc. </li></ul></ul><ul><ul><li>Hewlett-Packard. </li></ul></ul><ul><li>Esta asociación se encarga de la definición y mantenimiento de estándares para aplicaciones de la industria de la computación. </li></ul><ul><li>Otro de los estándares definidos por la OMG, además del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio. </li></ul>
  13. 13. DIAGRAMAS UML
  14. 14. <ul><li>Los diagramas de estructura construyen y documentan el modelo estático del sistema </li></ul><ul><li>Los diagramas de comportamiento muestran la parte dinámica de un sistema, construyen y documentan el modelo dinámico del sistema </li></ul>Diagramas UML Diagramas de Estructura Diagramas de Comportamiento
  15. 15. <ul><li>Diagramas de Estructura </li></ul><ul><li>Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado </li></ul><ul><li>Dentro de los Diagrama de Estructura tenemos: </li></ul><ul><ul><li>Diagrama de Clases </li></ul></ul><ul><ul><li>Diagrama de Componentes </li></ul></ul><ul><ul><li>Diagrama de Objetos </li></ul></ul><ul><ul><li>Diagrama de Estructura Compuesta (UML 2.0) </li></ul></ul><ul><ul><li>Diagrama de Despliegue </li></ul></ul><ul><ul><li>Diagrama de Paquetes </li></ul></ul>
  16. 16. <ul><li>Diagramas de Comportamiento </li></ul><ul><li>Enfatizan en lo que debe suceder en el sistema modelado. </li></ul><ul><ul><li>Diagramas de Actividades </li></ul></ul><ul><ul><li>Diagramas de Casos de Uso </li></ul></ul><ul><ul><li>Diagramas de Transición de Estados </li></ul></ul><ul><li>Diagramas de Interacción </li></ul><ul><li>Son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado. </li></ul><ul><ul><li>Diagramas de Secuencia </li></ul></ul><ul><ul><li>Diagramas de comunicación (versión simplificada Diagrama de colaboración) </li></ul></ul><ul><ul><li>Diagramas de Tiempos </li></ul></ul><ul><ul><li>Diagrama Global de Interacciones o Diagrama de Vista de Interacción </li></ul></ul>
  17. 17. Categorización Jerárquica de los diagramas UML
  18. 18. <ul><li>UML define nueve tipos de diagramas básicos: </li></ul>Diagramas Básicos de UML <ul><li>Diagramas de casos de Uso </li></ul><ul><li>Diagramas Clases </li></ul><ul><li>Diagramas Objetos </li></ul><ul><li>Diagramas Actividad </li></ul><ul><li>Diagramas Colaboración </li></ul><ul><li>Diagramas Secuencia </li></ul><ul><li>Diagramas Estados </li></ul><ul><li>Diagramas Componentes </li></ul><ul><li>Diagramas Deployment </li></ul>
  19. 19. UML Vistas y Diagramas Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  20. 20. <ul><li>En general los diagramas UML representan conceptos como símbolos (nodos) y relaciones (links) que conectan estos símbolos. </li></ul><ul><li>Otros elementos UML importantes: </li></ul><ul><ul><li>Notación de paquetes </li></ul></ul><ul><ul><li>Estereotipos </li></ul></ul><ul><ul><li>Comentarios (notas) </li></ul></ul><ul><ul><li>Constraints (o restricciones) </li></ul></ul><ul><ul><li>Valores etiqueta (tagged values) </li></ul></ul>Elementos Generales
  21. 21. Package : Sistema de Reservaciones Agencia Agente Aerolínea Banco Package: No se muestra su contenido en el diagrama Package: Agencia muestra el contenido de sus clases Agente y Aerolínea Package: Sistema de Reservaciones, contiene los packages de Agencia y Banco Paquetes (packages) En UML, los paquetes permiten organizar el modelado los elementos del sistema en grupos, permiten una organización jerárquica del modelo de elementos del sistema. 11/02/12 F.E.R.D.
  22. 22. Compras compañía pantallas Elementos del modelo Subpackage Package name reportes dominio vehículo camioneta camión Propietario 0 ..* Package container Package dependency Paquetes (packages)
  23. 23. Estereotipos << interface>> Set Tag estereotipo Antación (Annotation) Vehiculo3 - carga : double - maximaCarga : double + getCarga () : double + getMaximaCarga() : double + addCaja(peso: double) : double peso en newtons peso en kilogramos Nota o comentario Los estereotipos aplican tanto a relaciones como a nodos
  24. 24. Restricciones (Constraints) Jugador Las restricciones proporcionan al modelo ciertas condiciones que aplican a un nodo o link. Equipo { persistente } { miembro } { Mínimo 3 Jugadores mujeres y mínimo 4 jugadores hombres } * * * * Constraint
  25. 25. Valores etiqueta (tagged values) Sever Los valores etiqueta permiten agregar nuevas propiedades a los nodos en un diagrama. { version= 1.3 } Valores etiqueta {procesadores= 4 } __________ __________ _____ __________ __________ _______ __________ documento.java
  26. 26. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>
  27. 27. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>
  28. 28. Diagrama de Casos de Uso <ul><li>Relaciones de Casos de Uso: </li></ul><ul><ul><li>Inclusión : Depencia de obiligatoriedad, esteriotipo <<include>> o <<use>> </li></ul></ul><ul><ul><li>Extensión : Opconal, esteriotipo <<extend>> </li></ul></ul><ul><ul><li>Generalización </li></ul></ul><ul><li>Muestra quién hace uso del sistema y que procesos ejecutara. </li></ul><ul><li>Los usuarios en un Diagrama de Casos uso son llamados “Actores” </li></ul><ul><li>Un Caso de Uso se muestra como una elipse. </li></ul><ul><li>Utilidad: </li></ul><ul><li>Los Diagramas de Casos de Uso son de importancia para la de obtención de requerimientos y modelado del negocio. </li></ul><ul><li>Durante todo el desarrollo del sistema para hacer seguimiento del trabajo relisado. </li></ul>
  29. 29. Creando un modelo de Casos de Uso <ul><li>Un Diagrama de Casos de Uso comprende de varios casos de uso </li></ul><ul><li>Sus componentes son: </li></ul><ul><ul><li>Actores </li></ul></ul><ul><ul><li>Casos de uso </li></ul></ul><ul><ul><li>El sistema </li></ul></ul><ul><ul><li>Relaciones de generalización y asociación </li></ul></ul><ul><li>Un modelo de casos de uso usa “Actores” para definir que existe fuera del sistema y “Casos de uso” para definir que debe ejecutarse por el sistema </li></ul>11/02/12 F.E.R.D.
  30. 30. Diagramas de Casos de Uso Los casos de uso representan la funcionalidad dada por el sistema a los usuarios externos. el cliente pregunta por el balance 11/02/12 F.E.R.D.
  31. 31. Diagramas de Casos de Uso <ul><ul><li>El estándar de UML define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. </li></ul></ul><ul><ul><li>El valor verdadero de un caso de uso reposa en dos áreas: </li></ul></ul><ul><ul><li>La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio . </li></ul></ul><ul><ul><li>La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamiento del sistema , un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo. </li></ul></ul>11/02/12 F.E.R.D.
  32. 32. Nueva Reservación Modificar Reservación Borrar Reservación Check in Huésped Check out Huésped Buscar Huésped por nombre SISTEMA HOTELERO Recepcionista Telefonista Registrador 11/02/12 F.E.R.D.
  33. 33. Nueva Reservación Modificar Reservación Borrar Reservación Check in Huésped Check out Huésped Buscar Huésped por nombre SISTEMA HOTELERO Recepcionista Telefonista Registrador Adicinar detalles Huésped Buscar Reservación Habilitar Teléfono Deshabilitar Teléfono <<extend>> <<include>> <<include>> <<include>> <<include>> <<include>> << actor>> Monitor Teléfonos 11/02/12 F.E.R.D.
  34. 34. Escenarios de los Casos de Uso <ul><li>Un Caso de Uso muestra una función desde la perspectiva de los usuasrios. </li></ul><ul><li>Un escenario se refiere a una instancia de un Caso de Uso. </li></ul><ul><li>Un escenrio es un camino lógico desde el comienso hasta el final. </li></ul><ul><li>Los escenarios no contienen condicionales porque describen uno o varios caminos posibles de un caso de uso. </li></ul><ul><li>Se deben documentar escenerios tanto existosos como no existosos. </li></ul><ul><li>Se deben documentar los principales escenarios. </li></ul>11/02/12 F.E.R.D.
  35. 35. Nombre Actor Estado Puntos de Extensión Extends Precondiciones/ Asunpciones Post-condiciones Flujo de Eventos Nueva Reservación Recepsionista, Resgistrador Esperando por revisión del PM Adicionar detalles Huésped Ninguna El usuario esta logeado y la pantalla de reservaciones ha sido seleccionada La lista de reservaciones es actualizada si la reservación es aceptada 1. Se muestra al usuario lista de tipos de cuarto 2. El usuario selecciona el tipo cuarto requerido 3. El usuario entra fechas inicial y final o duración 4. El usuario inicia búsqueda cuarto disponible 5. Si las fecha están mal especificadas [A1] 6. Si no encontró cuarto disponible [A2] 7. Si el cuarto esta disponible, se muestra precio 8. Si el cliente rechaza la oferta [A3] 9. (Adionar detalles Huésped) punto de extensión 10. ………………… 11/02/12 F.E.R.D.
  36. 36. Nombre Requerimientos no funcionales Performance Frecuencia Notas Escenarios (Caminos Alternativos) Nueva Reservación Respuesta interactiva es requerida Baja <ul><li>Este caso de uso se puede cancelar en cualquier momento </li></ul><ul><li>A1. La pantalla muestra mensaje “fechas invalidas” entonces vuelve al punto 1 </li></ul><ul><li>A2. La pantalla muestra mensaje “Por favor intente seleccionar otro tipo de cuarto” entonces vuelve al punto 1 </li></ul><ul><li>A3. El caso de uso es terminado, cambios no efectuados. </li></ul>11/02/12 F.E.R.D.
  37. 37. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  38. 38. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  39. 39. <ul><li>Representación de Objetos y Clases en UML </li></ul><ul><ul><li>Los aspectos lógico y físico de la vista estática se muestra en el Modelo de Objetos (Model Object) </li></ul></ul><ul><ul><li>El Model Object esta compuesto de dos diagramas: </li></ul></ul><ul><ul><ul><li>Diagrama de Clases </li></ul></ul></ul><ul><ul><ul><li>Diagrama de Objetos </li></ul></ul></ul>11/02/12 F.E.R.D. Vista Estructural
  40. 40. Notación UML de las clases NombreClase atributos metodos <ul><li>Estructura básica de una clase en un Diagrama de Clases </li></ul>nombreClase Un Diagrama de clases es dinámico en su naturaleza, este puede ser revisado y actualizado durante la fase de análisis. Se le asigna el nombre cuando se crea pero la lista de atributos y métodos variará en cada iteración a otras 11/02/12 F.E.R.D.
  41. 41. Notación UML de las clases Vehículo - carga : double = 0.0 Nodos clase: Compañia Es una clase concreta, en donde sus miembros no están modelados. InputStream <<interface>> Es una clase abstracta ( nombre en itálicas ) Es una interface Set - cargaMaxima : double + getCargaMaxima() : double + getCarga() : double + addionarCaja(peso : double) : boolean a) b) c) d) Es una clase concreta, en donde sus miembros están modelados. 11/02/12 F.E.R.D.
  42. 42. Vehículo - carga : double = 0.0 - cargaMaxima : double + setCargaMaxima(maximo : double) + getCargaMaxima() : double + calcularDistanciaRecorrida() : double - Destinos [1 . . *] : String <<constuctor>> + Vehiculo(cargaMaxima : double ) <<accesor>> + getcarga() : double <<mutator>> + adicionarCaja(peso : double) : boolean <<bussiness logic>> # calcularEficiencia() :double modos de acceso nombre clase tipo atributo multiplicidad atributo valor inicial atributo atributos métodos nombre método nombre parámetro tipo retorno tipo parámetro Notación UML de las clases nombre atributo 11/02/12 F.E.R.D.
  43. 43. Notación UML de los objetos Count - counter : int = 0 - instanciaNumbre : int Ejemplo de una clase con elementos estáticos, counter es un atributo estático y getTotalCounter() un método estático. UML define modos de acceso y sus símbolos: modo de acceso símbolo private - protected # Public + - getTotalCount() : int + getMyNumber : int Elementos estáticos 11/02/12 F.E.R.D.
  44. 44. Notación UML de los objetos objectName:NombreClase atributo1 = valor1 La notación de un objeto es diferente a la de una clase ya que un objeto es una instancia de una clase atributo2 = valor2 objectName:NombreClase :NombreClase Si se conoce que el objeto es requerido pero no se le a identificado un nombre Sintaxis: 11/02/12 F.E.R.D.
  45. 45. Asociaciones y Enlaces (links) Enlace (link ): Asociacción: Persona Carro Propietario La relación representada por una línea sobre un Diagrama de Clases es una Asociación , la Asociación debe tener un nombre indicando una descripción lógica del propósito de la relación. :Persona :Carro Propietario Una Asociación entre dos Clases Una relación entre dos objetos es llamada un Enlace (Link). Un Link entre dos Objetos 11/02/12 F.E.R.D.
  46. 46. Asociaciones y Multiplicidad Carro Motor movido por La Multiplicidad muestra cada posible combinación de cómo varios objetos de una clase pueden ser asociados con objetos de otra clase. Persona Carro Propietario Diagrama de Clases Carro, Motor, Persona 1 1 1 * :Persona :Carro Propietario 1 * :Motor movido por 1 1 11/02/12 F.E.R.D.
  47. 47. Asociaciones y Multiplicidad Instructor Clase Estudiante Ejemplo de Diagrama de Clases 1 .. * 3..12 Plan Cubierta 1 computador 1 1 Salón 1 1 .. * 0 .. * 1 1 0 .. * 3..12 11/02/12 F.E.R.D.
  48. 48. Asociaciones Complejas Persona Libro presta Una asociación Compleja es cuando la Multiplicidad marcada con “*” se encuentra en ambos lados de la asociación. * * <ul><li>Una Asociación Compleja no es fácil modelar por las reglas que aplican a cada clase y tampoco lo es su implementación en un lenguaje de programación. </li></ul><ul><li>Dos técnicas para resolver asociaciones complejas son: </li></ul><ul><li>Clase Asociada </li></ul><ul><li>Asociaciones Cualificadas </li></ul>11/02/12 F.E.R.D.
  49. 49. Asociaciones Complejas Persona Libro presta Clase Asociada (o derivada) : Una Clase asociación es codificada con atributos para resolver el conflicto. Esta técnica es usada en la fase de análisis para resolver relaciones muchos a muchos * * Presta fechaDesde fechaHasta Persona Libro * Presta fechaDesde * <ul><li>El nombre de la clase asociada debe ser el mismo de la asociación origen </li></ul>11/02/12 F.E.R.D.
  50. 50. Asociaciones Complejas Banco Cliente Bancos con Clase Cualificada : Cuando dos clases tienen una asociación lógica “muchos-a-muchos”, Se asigna un valor de atributo único que actúa como índice. * * Banco ideCliente Cliente Bancos con * Banco codBanco Cliente Bancos con * Asociación “muchos-a-muchos” Asociación Cualificada para Banco referenciado a un Cliente Asociación Cualificada para Cliente referenciado un Banco 11/02/12 F.E.R.D.
  51. 51. Relaciones Lógicas <ul><li>Las relaciones lógicas que se expondrán son las siguientes: </li></ul><ul><ul><li>Herencia </li></ul></ul><ul><ul><ul><li>Generalización </li></ul></ul></ul><ul><ul><ul><li>Especialización </li></ul></ul></ul><ul><ul><li>Polimorfismo </li></ul></ul><ul><ul><li>Asociación </li></ul></ul><ul><ul><ul><li>Agregación </li></ul></ul></ul><ul><ul><ul><li>Composición </li></ul></ul></ul><ul><ul><li>Propagación y Delegación </li></ul></ul>Relaciones lógicas en la fase de análisis 11/02/12 F.E.R.D.
  52. 52. Notación UML para Herencia Mamifero Perro Mamifero Perro Gato Mamifero Perro Gato Herencia: Muestra como atributos y funcionalidad pueden ser compartidos entre clases de similar naturaleza o propósito. 11/02/12 F.E.R.D.
  53. 53. Notación UML para Herencia Mamífero <ul><li>Existen dos maneras de adicionar la herencia a un modelo: </li></ul><ul><li>Generalización </li></ul><ul><li>Especialización </li></ul>numPatas Comer() Perro numPatas Comer() Gato numPatas Comer() Perro numPatas Gato numPatas maullar() Ladrar() ladrar() maullar() Generalización: El concepto de Generalización ocurre cuando varias clases que ya existen en el diagrama de clases exhiben común funcionalidad, estructura y propósito 11/02/12 F.E.R.D.
  54. 54. Notación UML para Herencia Mamífero numPatas Comer() Perro Gato maullar() ladrar() Especialización: El concepto de Especialización ocurre cuando se crea una nueva clase que tiene toda la funcionalidad, estructura y propósito de una clase ya existente, pero requiere de nuevos código o atributos Mamífero numPatas Comer() Perro oveja valar() maullar() Perro ladrar() 11/02/12 F.E.R.D.
  55. 55. Polimorfismo Mamífero Perro Gato <ul><li>Polimorfismo es un termino OO fuertemente asociado a la herencia, el nombre viene de una palabra griega que significa “varias_formas“ que es exactamente lo que significa en el paradigma OO. </li></ul><ul><li>En lenguajes OO, se pueden definir dos métodos con el mismo nombre pero que aceptan diferentes tipos de argumentos, esta técnica de escribir o definir métodos es llamada overloading (sobreescritura). </li></ul><ul><li>Un perro es un mamífero </li></ul><ul><li>Un gato es un mamífero </li></ul>11/02/12 F.E.R.D.
  56. 56. Notación UML para Clases Abstractas <ul><li>Clases Abstractas: </li></ul><ul><li>Son clases que definen funcionalidad sin proveer toda su implementación y por tanto no puede ser instanciadas. </li></ul><ul><li>Una clase que extiende de un abstracta hereda todos sus métodos incluyendo los abstractos. Esta clase es considerada también es abstracta a menos que todos sus métodos se hayan sobreescrito dentro de la subclase con toda su implementación. </li></ul>TituloValor calcularVlrPresente() {abstract} obtenerEmisor() TituloTasaFija calcularVlrPresente() TituloTasaVariable obtenerTasaVari) {abstracta} Los métodos abstractos de la clase también son escritos en itálica El nombre de una Clase Abstracta se escribe en itálica 11/02/12 F.E.R.D.
  57. 57. Roles Carro Consumidor <ul><li>Describen “Como” un objeto participa en una relación. </li></ul><ul><li>En UML, cada clase al final de la asociación puede tener un rol. </li></ul><ul><li>Cada clase involucrada en una transacción juega un rol. </li></ul><ul><li>En UML los roles para una asociación son opcionales pero no suprimibles. </li></ul><ul><li>Proveen claridad y ayudan a el entendimiento de la asociación. </li></ul>comprador producto compra Asociación con Nombres de Rol 11/02/12 F.E.R.D.
  58. 58. Asociación Reflexiva Persona <ul><li>En un Diagrama de Objetos puede haber un Relación entre dos instancias de la misma clase. </li></ul><ul><li>Como solo hay una clase en el Diagrama de Clases que representa ambos objetos, la asociación apunta a la misma clase. Este tipo de asociación es llamada Asociación Reflexiva . </li></ul>esposo casados esposa Asociación Reflexiva 11/02/12 F.E.R.D.
  59. 59. Tipos de Asociación <ul><li>Una Asociación representa un tipo de relación entre dos clases y describe el nivel de dependencia de la una con la otra. </li></ul><ul><li>Hay dos tipos de relaciones que exhiben fuerte dependencia entre las clases: </li></ul><ul><ul><li>Agregación </li></ul></ul><ul><ul><li>Composición </li></ul></ul><ul><li>Para identificar o validar las relaciones de Agregación y Composición se pueden usar frases estructuradas: </li></ul><ul><ul><li>Asociación : Un chef usa un cuchillo </li></ul></ul><ul><ul><li>Agregación : Un carro tiene un radio </li></ul></ul><ul><ul><li>Composición : Un carro siempre tiene un motor </li></ul></ul>11/02/12 F.E.R.D.
  60. 60. Agregación <ul><li>Es una forma de Asociación, con un fuerte énfasis de como dos objetos se relacionan dentro de un sistema. </li></ul><ul><li>Caracterizado por la relación “Tiene Un” o “Consiste De”. </li></ul>Radio Carro Tiene un Notación UML para una Composición Composición <ul><li>Caracterizado por la relación “Siempre contiene” . </li></ul>Motor Carro Movido por Notación UML para una Agregación 11/02/12 F.E.R.D.
  61. 61. Propagación <ul><li>Se refiere al principio que se puede aplicar a clases que están asociadas a otras a través Agregación y Composición. </li></ul><ul><li>También se refiere a la invocación de un método que invoca otro método de alguno objetos que han sido agregados o con uno de los objetos que lo componen. </li></ul>Diagrama de clases mostrando métodos que se propagan Motor Carro Movido por pisarAcelerador() acelerar() 11/02/12 F.E.R.D.
  62. 62. Delegación <ul><li>Otro principio principio que se puede aplicar a clases que están asociadas a otras a través Agregación y Composición. </li></ul><ul><li>Ocurre cuando una operación entera que el usuario o el sistema invoca sobre una clase que hace parte de una asociación de objetos. </li></ul>Diagrama de Clases mostrando un Método Delegado Radio Carro Movido por subirVolumen() subirVolumen() 11/02/12 F.E.R.D.
  63. 63. Interfaces <ul><li>En Java las interfaces son clases en el cual todo es abstracto. </li></ul><ul><li>No extienden pero se implementan. (usan la palabra implements ) </li></ul><ul><li>Abolen el problema de herencia múltiple. </li></ul><ul><li>Los listados en un interface deben ser abstractos. </li></ul><ul><li>Como en las clases abstractas estos métodos deben ser sobrescritos directamente en las clases que implementan la interface. </li></ul><ul><li>En UML se utiliza el termino “Realización” describe la relación entre una interface y las clases que implementan la interface. </li></ul><<interface>> NuevoMotor acelerar() Motor acelerar() 11/02/12 F.E.R.D.
  64. 64. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  65. 65. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  66. 66. <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Transición de Estados </li></ul><ul><li>Diagramas de Actividad </li></ul><ul><li>El Moldeamiento Dinámico toma lugar en las faces : </li></ul><ul><li>Durante la fase del análisis </li></ul><ul><li>Durante el Diseño Físico. </li></ul>UML provee cuatro diagramas básicos para modelar la dinámica del flujo de información dentro del sistema: 11/02/12 F.E.R.D. Modelo Dinámico
  67. 67. Diagramas de Secuencia <ul><li>El Moldeamiento Dinámico toma lugar : </li></ul><ul><li>Durante la fase del análisis </li></ul><ul><li>Durante el Diseño Físico. </li></ul><ul><li>El Diagrama de Secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema. </li></ul><ul><li>Un Diagrama de Secuencia representa el intercambio de mensajes entre varios objetos para ejecutar un operación particular en un periodo de tiempo. </li></ul><ul><li>En UML los Diagramas de Secuencia son usados para proveer una descripción diagramática de cada escenario dentro de un Caso de Uso </li></ul><ul><li>Los Diagramas de Secuencia modelan los objetos que toman parte en un escenario particular y muestran sus interacciones a través del tiempo. </li></ul>11/02/12 F.E.R.D.
  68. 68. Diagramas de Secuencia <ul><li>Cada Diagrama de Secuencia: </li></ul><ul><ul><li>Tiene una relación directa con un escenario dentro de un Caso de Uso. </li></ul></ul><ul><ul><li>Identifica los objetos involucrados en cada proceso. </li></ul></ul><ul><ul><li>Identifica los eventos y acciones que ocurren durante un escenario. </li></ul></ul><ul><ul><li>Identifica que información debe ser pasada durante cada proceso </li></ul></ul><ul><ul><li>Identifica que respuesta es requerida después de cada acción o evento. </li></ul></ul>Un D iagrama de Secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. 11/02/12 F.E.R.D.
  69. 69. Estructura Básica de un Diagrama de Secuencia Actor 1 Actor 2 Object2:Class2 Object1:Class1 Líneas de vida que representan actores del sistema Líneas de vida que representan objetos 11/02/12 F.E.R.D.
  70. 70. Diagrama de Secuencia Actor 1 Object2:Class2 Object1:Class1 Object3:Class3 tarea1 tarea2 X <<create>> tarea3 La destrucción de un objeto se representa como una X al final de la línea de ejecución del objeto. Si la vida de un objeto termina durante el Diagrama de Secuencia la línea de vida termina inmediatamente 11/02/12 F.E.R.D.
  71. 71. Diagramas de Secuencia <ul><li>Como pasa la información entre los objetos? </li></ul><ul><li>La información entre objetos se pasa a través de mensajes . </li></ul><ul><li>Cada objeto invoca algún método del otro y pasa la información dentro del método como parámetros. </li></ul><ul><li>La invocación de un método de un objeto por otro objeto se muestra como una flecha con un rotulo (label) eventualmente con el nombre del método invocado. </li></ul><ul><li>Tipos de mensajes </li></ul><ul><li>Existen dos tipos de mensajes: síncronos y asíncronos. </li></ul><ul><li>Los mensajes síncronos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. </li></ul><ul><li>Este tipo de mensajes se representan con flechas con la cabeza llena. </li></ul><ul><li>Los mensajes asíncronos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta. </li></ul><ul><li>También se representa la respuesta a un mensaje con una flecha discontinua. </li></ul>11/02/12 F.E.R.D.
  72. 72. Usuario Internet : LoginService : LoginServlet Return (with value) Anonymous class role :RDDMS user:User “ login” user:=login SELECT * FROM User WHERE user_name=? “ create” Lífeline Activation Box Named class role Message Object created Ejemplo de Diagrama de Secuencia en el cual un actor inicia una secuencia de login con una aplicación web 11/02/12 F.E.R.D.
  73. 73. 11/02/12 F.E.R.D. Ejemplo de Diagrama de Secuencia
  74. 74. Ejemplo de Diagrama de Secuencia 11/02/12 F.E.R.D.
  75. 75. Ejemplo de Diagrama de Secuencia Diagrama de Secuencia de la documentación escenario de caso de uso Firmar Acto Administrativo
  76. 76. Modelo Dinámico <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Transición de Estados </li></ul><ul><li>Diagramas de Actividad </li></ul><ul><li>El Moldeamiento Dinámico toma lugar en las faces : </li></ul><ul><li>Durante la fase del análisis </li></ul><ul><li>Durante el Diseño Físico. </li></ul>UML provee cuatro diagrama básicos para modelar la dinámica del flujo de información dentro del sistema: 11/02/12 F.E.R.D.
  77. 77. Diagramas de colaboración <ul><li>Alternativa la los Diagramas de Secuencia </li></ul><ul><li>Los objetos son conectados con flechas enumeradas mostrando el flujo de la información </li></ul><ul><li>Las flechas son dibujadas desde la fuente de la interacción. </li></ul><ul><li>El objeto el cual se apunta la flecha se conoce con el nombre objetivo ( target ). </li></ul><ul><li>Las flechas son numeradas para mostrar el orden en el cual los objetos son usados dentro del escenario. </li></ul><ul><li>Esta flechas también son marcadas con la descripción de la tarea requerida del objeto objetivo (a través de mensajes). </li></ul><ul><li>Un Diagrama de Colaboración representa un comportamiento particular compartido con varios objetos </li></ul>11/02/12 F.E.R.D.
  78. 78. Un Diagrama de Colaboración Actor 1 Object2:Class2 Object1:Class1 Object3:Class3 1: task1 1.1: task2 1.2: <<create>> 1.3: task3 Tanto los Diagramas de secuencia como los Diagramas de colaboración tienen sus ventajas y son incluidos dentro de un proyecto para clarificar completamente un escenario Un Diagrama de Colaboración es esencialmente una vista diferente de un Diagrama de Secuencia. 11/02/12 F.E.R.D.
  79. 79. Diagrama de Secuencia Actor 1 Object2:Class2 Object1:Class1 Object3:Class3 tarea1 tarea2 X <<create>> tarea3 Un Diagrama de Colaboración es esencialmente una vista diferente de un Diagrama de Secuencia. 11/02/12 F.E.R.D.
  80. 80. Ejemplo de un Diagrama de Colaboración client sessionBean txn: UserTransaction 3: createStatement() 5: createStatement() 1: <<create>> 2: begin() 7: rollback() 10:<<destroy>> costumerDB :Connection :Statement 3.1 <<create>> invertorDB :Connection :Statement 5.1: <<create>> << global >> 4: executeUpdate() 8: close() 6: executeUpdate() 9: close() << global >> <<local>> <<local>> {trasient} {trasient} <<local>> estereotipo object constraint {trasient} mensaje objeto link 11/02/12
  81. 81. <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Transición de Estados </li></ul><ul><li>Diagramas de Actividad </li></ul><ul><li>El Moldeamiento Dinámico toma lugar en las faces : </li></ul><ul><li>Durante la fase del análisis </li></ul><ul><li>Durante el Diseño Físico. </li></ul>UML provee cuatro diagrama básicos para modelar la dinámica del flujo de información dentro del sistema: 11/02/12 F.E.R.D.
  82. 82. Diagramas de Transición de Estados <ul><li>Muestran como un objeto cambia en el tiempo con la invocación de métodos. </li></ul><ul><li>Consiste de: </li></ul><ul><ul><li>Estados </li></ul></ul><ul><ul><li>Eventos </li></ul></ul><ul><li>Se utilizan flechas para mostrar los caminos entre diferentes estados de un objeto. </li></ul><ul><li>Cada flecha muestra la tarea ejecutada sobre el objeto para representar ese evento en particular. </li></ul><ul><li>Cuando un objeto adquiere un estado desde el cual este no puede adquirir otro estado este es llamado estado final y es marcado por un punto de terminación. </li></ul>11/02/12 F.E.R.D.
  83. 83. Diagramas de Transición de Estados Blockeb Runnable Running transition state node New initial state final state Dead start() run() Scheduler unbloked blocking event Un ejemplo de Diagrama de transición de Estados 11/02/12 F.E.R.D.
  84. 84. Diagramas de Transición de Estados Estado Todos los objetos tienen un estado . El estado actual de un objeto esta dado por los valores almacenados en sus atributos. Evento Un evento es un estimulo que ínsita a un objeto hacer una transición de un estado a otro. Los eventos toman la forma de una llamada a un método, El método es una tarea o una serie de tareas dentro de un objeto que alteran el estado del objeto. Transiciones Las transiciones llevan a un objeto de un estado a otro. Para que ocurra una transición, deben cumplirse unas condiciones . 11/02/12 F.E.R.D.
  85. 85. Diagramas de Transición de Estados <ul><li>Un objeto puede tener puede tener tantos estados como definamos, pero solamente podrá estar en uno de ellos a la vez. </li></ul><ul><li>En el ejemplo la bombilla puede estar encendida o apagada, pero no puede estar encendida y apagada a la vez. Es decir, los estados de la bombilla serán encendida y apagada. </li></ul>11/02/12 F.E.R.D.
  86. 86. Diagramas de Transición de Estados <ul><li>Estados globales </li></ul><ul><li>Pueden existir unos estados que sean capaces de interrumpir los demás y ejecutarse inmediatamente. Normalmente son estados que realizan una acción y luego vuelven al estado que se estaba ejecutando. </li></ul><ul><li>Ejemplo: Un empleado trabajando acaba de ganar un nuevo estado global: Ir al baño . Este estado tiene prioridad absoluta, cuando el empleado tenga ganas de ir al baño (es decir, cuando se cumpla la condición que lanza la transición a este estado, por ejemplo vejiga llena ) dejará lo que está haciendo e irá al baño de inmediato. Después, volverá a lo que estaba haciendo, como si nada hubiera pasado. </li></ul>11/02/12 F.E.R.D.
  87. 87. Diagramas de Transición de Estados <ul><li>Transiciones </li></ul><ul><li>Una transición tiene dos elementos: </li></ul><ul><li>Estado fuente – El estado afectado por la transacción </li></ul><ul><li>Evento disparador (trigger) - Evento originado en el estado fuente </li></ul>11/02/12 F.E.R.D. <ul><li>Para hacer esto posible, necesitaremos que el sistema recuerde el estado en el que se encontraba antes de entrar al estado global, para así volver a ese estado una vez que finalice la ejecución del estado global. </li></ul>
  88. 88. Diagramas de Transición de Estados Tabla de Transiciones Cuando tenemos varios estados, puede que desde un estado podamos pasar a varios estados distintos dependiendo de qué condiciones se cumplan. Para llevar un control sobre esto y no perdernos cuando tengamos más estados y varias transiciones posibles, se suele crear una tabla de transiciones : En esta tabla vemos lo siguiente: Si estamos en el estado A o B y se cumple la condición 1 pasamos al estado C Si estamos en el estado B y se cumple la condición 2 pasamos al estado A Si estamos en el estado C y se cumple la condición 3 pasamos al estado B 11/02/12 F.E.R.D. Condición Estado actual A B C 1 C C X 2 X A X 3 X X B
  89. 89. Diagramas de Transición de Estados Disponible En sobregiro Diagrama de Transición de Estados para una Cuenta Bancaria Pago en efectivo o cheque Deposito en efectivo [cuenta > sobregiro] Retiro en efectivo Retiro Retiro Pago en efectivo/cheque [cuenta < sobregiro] Cierre de la cuenta Cheque aprobado 11/02/12 F.E.R.D.
  90. 90. <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Transición de Estados </li></ul><ul><li>Diagramas de Actividad </li></ul><ul><li>El Moldeamiento Dinámico toma lugar en las faces : </li></ul><ul><li>Durante la fase del análisis </li></ul><ul><li>Durante el Diseño Físico. </li></ul>UML provee cuatro diagrama básicos para modelar la dinámica del flujo de información dentro del sistema: 11/02/12 F.E.R.D.
  91. 91. Diagramas de Actividad <ul><li>Representa los procesos de negocios de alto nivel, incluidos el flujo de datos. </li></ul><ul><li>También puede utilizarse para modelar lógica compleja y/o paralela dentro de un sistema. </li></ul><ul><li>Un Diagrama de Actividad corresponde aun caso de uso </li></ul><ul><li>Un Diagrama de Actividad representa las actividades o acciones de un proceso sin tener en cuenta los objetos que ejecutan estas actividades. </li></ul><ul><li>Cada actividad esta conectada con líneas de conexión a la siguiente actividad en un orden, las líneas de conexión son referenciadas como transiciones. </li></ul>Parse XML file Translate to HTML Render HTML in browser Start state Activity Transition Stop state 11/02/12 F.E.R.D.
  92. 92. Transición Actividad Fin Inicio Línea Separador Bifurcación Unión Bifurcación solo 2 de 3 necesitan ser completadas 2 [condición1] [condición 2] Ramificación Mezcla (merge) 11/02/12 F.E.R.D.
  93. 93. Diagrama de Actividad p=o.getNextProduct() o.putOnBackOrder(p) n=inventory.getCuont(p) Inventory.setCount(p,n-1) [o.hasMoreProducts()] else else [n>0] Branching and Loooping Conditión Ramificación (Branch) 11/02/12 F.E.R.D.
  94. 94. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  95. 95. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  96. 96. <ul><li>Un Diagrama de Componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. </li></ul><ul><li>Los Diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura del sistema. </li></ul>Diagramas de Componentes <ul><li>Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. </li></ul><ul><li>En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema. </li></ul><ul><li>Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre las diferentes partes de un sistema. </li></ul>11/02/12 F.E.R.D.
  97. 97. Un Diagrama de Componentes representa los componentes que componen una aplicación, sistema o empresa. Los componentes, sus relaciones, interacciones y sus interfaces públicas. Diagramas de Componentes Componente a) Icono genérico b) Icono que representa un archivo fuente c) Icono que representa un archivo ejecutable Applet.java Calculator.jar 11/02/12 F.E.R.D.
  98. 98. Diagramas de Componentes Calculator.jar CalcApplet.class CalcGUI.class CalcModel.class CalcApplet.java CalcGUI.java CalcModel.java Calculator.html {versión =2.1} {versión =1.3} {versión =1.0} En la figura se muestran las dependencias del empaquetamiento de una pagina HTML que contiene un applet. Un ejemplo de Diagrama de componentes 11/02/12 F.E.R.D.
  99. 99. <ul><li>Miden el grado por el cual las clases dentro de un sistema dependen una de otra. </li></ul><ul><li>Son una consideración importante en la etapa de diseño de un proyecto por que ayudan a separar las clases dentro de componentes. </li></ul><ul><li>Cohesion: </li></ul><ul><li>Mide cómo una clase o grupo de clases contribuyen a un mismo propósito dentro del sistema, es la medida de dependencias entre clases o componentes. </li></ul><ul><li>Coupling: </li></ul><ul><li>Mide como dos o mas clases, grupos de clases, paquetes de componentes lógicos o físicos están unos con otros. </li></ul>Cohesion y Coupling 11/02/12 F.E.R.D.
  100. 100. Driver Mechanic <ul><li>Un grupo de clases que completamente satisfacen un simple propósito dentro de un sistema ( high coehesion) </li></ul><ul><li>Multiples asociaciones dentro del grupo (high coupling). </li></ul><ul><li>Cuando dos o mas clases que no estan relacionadas con el mismo propocito tienen una (low cohesion). </li></ul><ul><li>Cuando no hay asociación en un Diagrama de Clases (Low coupling) . </li></ul>1..5* Team raceNo Meeting Car Diagrama de Clases que modela un sistema para Carreras de Automovilismo Spectator date Race RaceSchedule 0..* 1..* 1..* 1..* 2..* Cohesion y Coupling 11/02/12 F.E.R.D.
  101. 101. Driver Mechanic 1..5* Team raceNo Meeting Car Diagrama de Clases mostrando áreas de alta Cohesión Spectator date Race RaceSchedule 0..* 1..* 1..* 1..* 2..* Cohesion y Coupling Las líneas rojas no son notación UML 11/02/12 F.E.R.D.
  102. 102. <ul><li>Los componentes son grupos de clases que representan el sistema. </li></ul><ul><li>Como grupos los componentes son responsables de la diferentes operaciones dentro del sistema. </li></ul><ul><li>Los componentes se identifican usando las técnicas de Cohesion y Coupling. </li></ul><ul><li>Los grupos de clases que muestran alta Cohesión y alto Coupling conforman los componentes del sistema. </li></ul><ul><li>Cada tipo de componente debe tener un nombre en el diagrama. </li></ul>Componentes Componente instance:Component N otación UML para un Componente 11/02/12
  103. 103. Diagrama de Componentes :Team :Spectator RaceMeeting Diagrama de Componentes de sistema para Carreras de Automovilismo 11/02/12 F.E.R.D.
  104. 104. Diagrama de componentes :Team Diagrama de Componentes de sistema para Carreras de Automovilismo Driver Driver Mechanic Team Car :Spectator Spectator :RaceMeteeing Meeting RaceSchedule Race Diagrama de componentes más completo donde se muestran las clases componentes 11/02/12 F.E.R.D.
  105. 105. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  106. 106. <ul><li>UML Vistas y Diagramas </li></ul>Vista Estructural <ul><li>Diagramas de clases </li></ul><ul><li>Diagramas de Objetos </li></ul>Vista de la Implementación <ul><li>Diagramas de Componentes </li></ul>Vista de Comportamiento <ul><li>Diagramas de Secuencia </li></ul><ul><li>Diagramas de Colaboración </li></ul><ul><li>Diagramas de Estado </li></ul><ul><li>Diagramas de Actividad </li></ul>Vista Ambiente <ul><li>Diagramas de Despliegue </li></ul>Vista de Usuario <ul><li>Diagramas Casos de Uso </li></ul>11/02/12 F.E.R.D.
  107. 107. <ul><li>Un Diagrama de Despliegue representa : </li></ul><ul><li>La red de recursos de procesamiento y la configuración de los componentes de software en cada elemento físico. </li></ul><ul><li>Un Diagrama de Despliegue esta compuesto de: </li></ul><ul><ul><li>Nodos de hardware </li></ul></ul><ul><ul><li>Componentes de software </li></ul></ul><ul><ul><li>Dependencias de software </li></ul></ul><ul><ul><li>Relaciones de comunicación. </li></ul></ul><ul><li>Un Diagrama de Despliegue muestra: </li></ul><ul><li>Como las capa lógicas de la arquitectura de una aplicación están configuradas dentro de una red física. </li></ul>Diagramas de Despliegue (Deployment) 11/02/12 F.E.R.D.
  108. 108. <ul><li>Los Diagramas de Despliegue modelan soluciones de naturaliza distribuida. </li></ul><ul><li>Su Notación: </li></ul><ul><ul><li>Es una caja de tres dimensiones, una caja para cada plataforma </li></ul></ul><ul><ul><li>Las plataformas se unen con líneas que representan la red de comunicaciones que permiten a los componentes del sistema comunicarse. </li></ul></ul><ul><ul><li>Las línea pueden ser etiquetadas con el protocolo de red que será usado para la comunicación. </li></ul></ul><ul><ul><li>Las cajas pueden tener un nombre para mostrar que plataforma esta representando. </li></ul></ul>Diagramas de Despliegue (Deployment) 11/02/12 F.E.R.D.
  109. 109. Diagramas de Despliegue (Deployment) Client Server DataBase NetworkPrinter Diagrama de Despliegue para un sistema cliente/servidor TCP/IP * * <ul><li>Las misma marcas de multiplicidad que se usan en los Diagramas de Clases pueden usarse para como las maquinas de cada tipo son permitidas en el sistema </li></ul>11/02/12 F.E.R.D.
  110. 110. Diagramas de Despliegue (Deployment) Client:PC/Windows7 WebServer: SunEK33/Linux Ubunto Printer Ejemplo de Diagrama de Despliegue TCP/IP instance:Component nodo físico Nombre del nodo Tipo de nodo Relación de comunicaciones parallel port browser HTTPD HTML Form ISP Page Bean
  111. 111. Ejemplo de una documentación UML <ul><li>Patrón de diseño J2EE -Transfer Object </li></ul><ul><li>Problema: </li></ul><ul><li>Se desean transferir múltiples elementos de datos sobre una capa </li></ul><ul><li>Se obliga: </li></ul><ul><li>A que los clientes accedan componentes en otras capas para recuperar y actualizar datos </li></ul><ul><li>Reducir requerimientos remotos a través de la red </li></ul><ul><li>Se requiere abolir la degradación del performance de la red causada por aplicaciones que tienen un alto trafico de red </li></ul>
  112. 112. Solución: Usar el patrón de diseño Transfer Object para manejar múltiples elementos de datos a través de una capa. Diagrama de Clases
  113. 113. Diagrama de Secuencia
  114. 114. <ul><li>Estrategias: </li></ul><ul><li>Estrategia tener un Transfer Object (objeto de transporte) actualizable </li></ul><ul><li>Estrategia tener múltiples Transfer Objects </li></ul><ul><li>Estrategia tener una entidad que hereda un Transfer Object </li></ul><ul><li>Consecuencias: </li></ul><ul><li>Reduce el trafico de la red </li></ul><ul><li>Simplifica el objeto remoto y la interface remota </li></ul><ul><li>Transfiere más datos en pocas llamadas remotas </li></ul><ul><li>Reduce la duplicación de código </li></ul><ul><li>Introduce el uso de transfer objetos </li></ul><ul><li>Incrementa complejidad propia para sincronización y control de versiones </li></ul>
  115. 115. Herramientas UML <ul><li>Rational Rose ( www.rational.com ) de IBM </li></ul><ul><li>TogetherSoft Control Center, Borland ( http:// www.borland.com/together/index.html ) </li></ul><ul><li>ArgoUML (free software) (http://argouml.tigris.org/ ) OpenSource; escrito en java </li></ul><ul><li>BOUML (free software) ( http:// bouml.free.fr , http:// bouml.sourceforge.net ), software no comercial. OpenSource; </li></ul><ul><li>Otras ( http:// www.objectsbydesign.com/tools/umltools_byCompany.html ) </li></ul>
  116. 116. <ul><li>1. UML Distilled: A Brief Guide to the Standard Object Modeling Language Martin Fowler , Kendall Scott </li></ul><ul><li>2. Object Oriented Application Analysis and Desing for Java Technology (UML) </li></ul><ul><li>OO-26 de Sun Microsystems </li></ul><ul><li>3. Gravy Booch,James Rumbaugh, Ivar Jaconson, The Unified Modeling Language User Guide. Addison-Wealey Plublishing </li></ul><ul><li>4. Practical UML --- A Hands-On Introduction for Developers </li></ul><ul><li>http://www.togethersoft.com/services/practical_guides/umlonlinecourse/ </li></ul><ul><li>5. Software Engineering Principles and Practice. Second Edition; Hans van Vliet.5. http://www-inst.eecs.berkeley.edu/~cs169/ </li></ul>Recursos Adicionales
  117. 117. FINAL DE LA PRESENTACION Gracias por su asistencia

×