UML

32,804 views

Published on

UML

Published in: Technology
4 Comments
9 Likes
Statistics
Notes
  • Excelente presentacion
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • me ayudo muy bien
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Well done, I liked the presentation!
    http://www.furniture101.net/
    http://www.furniture101.net/category/furniture-refinishing/
    http://www.furniture101.net/category/interior-design/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • muy bueno las diaposistivas... felicitaciones
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
32,804
On SlideShare
0
From Embeds
0
Number of Embeds
338
Actions
Shares
0
Downloads
1,538
Comments
4
Likes
9
Embeds 0
No embeds

No notes for slide

UML

  1. 1. <ul><li>Análisis y Diseño de Sistemas de Información </li></ul><ul><li>Temario </li></ul><ul><ul><li>Estructuras de Objetos </li></ul></ul><ul><ul><li>Diagramas Estáticos </li></ul></ul><ul><ul><ul><li>Diagramas de Clases </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Casos de Uso </li></ul></ul></ul><ul><ul><li>Diagramas Dinámicos </li></ul></ul><ul><ul><ul><li>Diagramas de Estado </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Actividades </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Secuencias </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Colaboración </li></ul></ul></ul><ul><ul><li>Diagramas de Implementación </li></ul></ul><ul><ul><ul><li>Diagramas de Componentes </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Distribución </li></ul></ul></ul><ul><ul><li>Casos de estudio </li></ul></ul><ul><ul><li>Patrones de Diseño </li></ul></ul><ul><ul><li>Metodologías </li></ul></ul><ul><li>Instructor </li></ul><ul><ul><li>Ing. y M.A. Francisco Javier Mariscal Flores fmarisc@uach.mx </li></ul></ul>Tomado de http://comunidad.uach.mx/fmarisc/analisis/Analisis.ppt
  2. 2. Ingeniería de Software <ul><li>Proceso de desarrollo (cont.) </li></ul><ul><ul><li>Procesos donde utilizar UML. </li></ul></ul><ul><ul><ul><li>Los procesos iterativos deberán tener un plan de que serán las iteraciones y que será cubierto por cada una de ellas. </li></ul></ul></ul><ul><ul><ul><li>En la fase de construcción: </li></ul></ul></ul><ul><ul><ul><ul><li>El comienzo proporciona el compromiso del patrocinador del proyecto de seguir adelante se conoce el caso de negocios y su factibilidad y alcance básicos. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La elaboración da la arquitectura básica de el sistema, un plan para el acuerdo de construcción, identifica todos los riesgos significantes, entendimiento cabal de los mayores riesgos para no estar preocupados. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La construcción termina con una versión beta del sistema. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Transición es el proceso de introducir el sistema a sus usuarios. </li></ul></ul></ul></ul><ul><ul><ul><li>Otros procesos han adoptado UML como su lenguaje de modelación: Catalysis, Rational Unified Process, etc. </li></ul></ul></ul>
  3. 3. Diagramas Estáticos <ul><li>Casos de Uso </li></ul><ul><ul><li>Es una colección de situaciones que ocurren cuando un actor usa un sistema para completar un proceso. Normalmente un caso de uso es un proceso relativamente largo, no un paso individual o transacción. Cada caso de uso necesita representar una tarea, o una unidad coherente de funcionalidad, la cuál necesita ser soportada por el sistema. </li></ul></ul><ul><ul><li>Una vez identificado los casos de uso se pueden crear diagramas de casos de uso para colocar el caso de uso en contexto. Involucrando las fronteras del sistema para un conjunto de casos de uso y definiendo las líneas de comunicación entre un actor particular y el caso de uso. </li></ul></ul><ul><ul><li>En las etapas iniciales de desarrollo del proyecto, los diagramas de casos de uso describen las actividades del mundo real y las motivaciones. Se puede afinar los diagramas en etapas posteriores para reflejar las interfases de usuario y los detalles de diseño. </li></ul></ul><ul><ul><li>Cuando se tienen varios subsistemas es común dibujar la frontera del sistema, pero generalmente se omite. </li></ul></ul>Sist. de Información de Biblioteca Recursos para Prestamo Usuario Bibliotecario Agregar recursos Regresar Recursos
  4. 4. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Interacciones con sistemas externos: </li></ul></ul><ul><ul><ul><li>Las opiniones de incluir a los sistemas externos como casos de uso o no, varían: </li></ul></ul></ul><ul><ul><ul><ul><li>1.- Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama. Si requiere acceso a Reuters se debería indicar. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>2.- Algunas personas consideran que sólo se deben mostrar los casos de uso con una interacción externa, cuando quien inicia el contacto es otro sistema. Contabilidad solo se mostraría si dicho sistema invocara algún proceso que le dijera al sistema fuente que lo hiciera. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.- Algunas personas consideran que solo se deben mostrar los actores del sistema cuando ellos sean los que necesiten el caso de uso. Si se genera un archivo cada noche que después es recogido por el sistema de contabilidad, entonces éste es el actor que corresponde, por necesitar de dicho archivo. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>4.- Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor. </li></ul></ul></ul></ul>
  5. 5. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Un actor en un caso de uso representa un rol que alguien debe jugar, en vez de representar a alguien en individual. </li></ul></ul><ul><ul><li>Una relación de comunicación entre un actor y un caso de uso no significa que alguien en ése rol necesariamente tenga que estar involucrado en sacar la tarea adelante; solo significa que puede estarlo, dependiendo de las circunstancias. </li></ul></ul><ul><ul><li>El beneficiario de un caso de uso es un actor para el que el caso de uso tiene algún valor. Se puede diferenciar entre quienes necesitan el caso de uso y quienes están involucrados con él sin obtener ningún beneficio. </li></ul></ul><ul><ul><li>Actores no humanos , como otros a sistemas o en algunos casos se pueden identificar diferentes dispositivos externos al sistema. </li></ul></ul>
  6. 6. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Utilización de los casos de uso. </li></ul></ul><ul><ul><ul><li>Los casos de uso sirven a capturar los requerimientos al proporcionar una forma estructurada de: </li></ul></ul></ul><ul><ul><ul><ul><li>Identificar a los actores </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Para cada actor encontrar qué necesitan del sistema (qué casos de uso tienen valor para ellos) y encontrar cualquier otra interacción que esperen tener con el sistema. </li></ul></ul></ul></ul><ul><ul><li>Casos de uso a través del desarrollo . </li></ul></ul><ul><ul><ul><li>Planeación . Antes de que se haga un proceso de estimación y planeación para el proyecto completo, es necesario hacer una lista de los casos de uso del sistema, junto con: </li></ul></ul></ul><ul><ul><ul><ul><li>Una buena idea de lo que significa cada uno </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Entender quién quiere cada uno y qué tanto lo desea. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Conocer cuál caso de uso acarrea más riesgo </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Un plan de que tanto tomará implementar cada caso de uso. </li></ul></ul></ul></ul><ul><ul><ul><li>Aspectos políticos . Recuerde que el 25% de los sistemas nunca se terminan. Debemos poder demostrar que el sistema hace algo útil primeramente para la gente más influyente. </li></ul></ul></ul><ul><ul><ul><li>Aspectos técnicos . Debemos sacar adelante primero los casos de uso con mayor riesgo, para eliminar el riesgo más grande aún cuando tengamos contingencias para poderlas eliminar y no que quedemos atorados en un diseño que no nos permita manejar los casos de uso más riesgoso. </li></ul></ul></ul><ul><ul><ul><li>Validación del Sistema . Tomar cada caso de uso y verificar que el diseño permitirá completarlo, igualmente se deben diseñar pruebas para cada caso de uso. </li></ul></ul></ul>
  7. 7. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Posibles problemas con los casos de uso. </li></ul></ul><ul><ul><ul><li>Peligro de construir sistemas no orientados a objetos . Al enfocarnos en casos de uso, podemos perder de vista la arquitectura del sistema y la estructura de objetos estáticos, podemos terminar desarrollando sistemas top-down orientados a funciones, difíciles de mantener e inflexibles. Para evitarlo debemos administrar correctamente el inicio de cada etapa, si la etapa previa dejó alguna situación insatisfactoria deberá volverse a producir. </li></ul></ul></ul><ul><ul><ul><li>Peligro de equivocar el diseño de los requerimientos . Por ejemplo al equivocar el involucramiento de actores en casos de uso que no los benefician. Es importante que los desarrolladores distingan entre requerimientos de diseño y candidatos. </li></ul></ul></ul><ul><ul><ul><li>Perder requerimientos si se pone mucha confianza en el proceso sugerido de encontrar los actores y luego encontrar los casos de uso que necesita cada actor. Se puede minimizar el error al hacer paralelamente el análisis de casos de uso y el modelado conceptual de clases. </li></ul></ul></ul>
  8. 8. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Relaciones entre casos de uso. </li></ul></ul><ul><ul><ul><li>La inclusión permite volver a utilizar los pasos de un caso de uso dentro de otro </li></ul></ul></ul><ul><ul><ul><li>Al reusar los casos de uso se tienen las siguientes ventajas : </li></ul></ul></ul><ul><ul><ul><ul><li>Buena forma de registrar la conveniencia de se usara un componente o evitar duplicidades. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Al hacer en forma externa partes del caso de uso puede hacerlo más corto y fácil de entender </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Al identificar funcionalidad en común entre los casos de uso al principio puede ser una forma de descubrir la posibilidad de reusar un componente que implemente la funcionalidad compartida. </li></ul></ul></ul></ul><ul><ul><ul><li>Sin embargo se tienen las siguientes desventajas : </li></ul></ul></ul><ul><ul><ul><ul><li>Peligro de buscar funcionalidad y al hallarla fomentar la elaboración de un sistema basado en funciones, top-down con sistemas inflexibles. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Es difícil para alguien no adiestrado en UML entender la notación de «incluir» </li></ul></ul></ul></ul>Recolectar dinero Exhibir el interior Cubrir el interior «incluir» «incluir»
  9. 9. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Relaciones entre casos de uso.(cont.) </li></ul></ul><ul><ul><ul><li>La extensión , permite crear un caso mediante la adición de pasos a uno existente, Se dice que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base. </li></ul></ul></ul><ul><ul><ul><li>Generalización . Un caso de uso secundario hereda las acciones y significado del primario y además agrega sus propias acciones. </li></ul></ul></ul>Comprar gaseosa Comprar un vaso de gaseosa Reabastecer Punto de extensión llenar los compartimientos Exhibir el interior Cubrir el interior «incluir» «incluir» Reabastecer de Acuerdo a las ventas «extender» (llenar los Compartimientos)
  10. 10. Diagramas Estáticos <ul><li>Casos de Uso (cont.) </li></ul><ul><ul><li>Relaciones entre casos de uso.(cont.) </li></ul></ul><ul><ul><ul><li>Las reglas para aplicar « incluir » o « extender » son: </li></ul></ul></ul><ul><ul><ul><ul><li>Utilice extender cuando describa una variación de conducta normal. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Emplee incluir para repetir cuando se trate de uno o varios casos de uso y desee evitar repeticiones </li></ul></ul></ul></ul><ul><ul><ul><li>Algunas veces el termino escenario es usado como sinónimo de casos de uso, pero en el contexto de UML, la palabra escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso. </li></ul></ul></ul><ul><ul><ul><li>Cuando emplear los casos de uso </li></ul></ul></ul><ul><ul><ul><ul><li>Todo caso de uso es un requerimiento potencial y hasta que no haya sido capturado, no se podrá planear como manejarlo en el proyecto. La mayoría se generan durante la captura de requerimientos, pero se irán descubriendo otros conforme se avance en el proyecto, es necesario estar siempre pendiente de ellos. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El modelado conceptual junto con los usuarios ayuda a descubrir los casos de uso. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Se puede tener diferente grado de granularidad, por ejemplo para un proyecto de 10 personas-año se esperarían 20 casos de uso ó 100 casos dependiendo del nivel de detalle. </li></ul></ul></ul></ul>
  11. 11. Estructuras de Objetos <ul><li>¿Qué es un objeto? </li></ul><ul><ul><li>Conceptualmente, un objeto es una cosa con la que se puede interactuar: Se le pueden mandar varios mensajes y reaccionará. El como se comporte dependerá del estado interno actual del objeto. Un objeto tiene una identidad la cual lo distingue de todos los demás objetos. </li></ul></ul><ul><ul><li>El estado de un objeto se representa mediante los datos almacenados en el mismo, los cuales son llamados atributos . </li></ul></ul><ul><ul><li>El comportamiento de un objeto es lo que éste puede hacer y se encuentra contenido en métodos , los cuáles se invocan enviándoles mensajes. </li></ul></ul><ul><ul><li>Representación UML de un objeto (Diagrama de Clase): </li></ul></ul>Empleado - Nombre:String - Sexo:Boolean - Direccion:String - RFC:String + TomarNombre:String + TomarRFC:String + TomarDireccion:String
  12. 12. Estructuras de Objetos <ul><li>Problemas con la definición de objetos </li></ul><ul><ul><li>Se pueden crear objetos degenerados como: </li></ul></ul><ul><ul><ul><li>Un objeto sin datos. Que sería lo mismo que una biblioteca de funciones. </li></ul></ul></ul><ul><ul><ul><li>Un objeto sin métodos, con solo operaciones del tipo crear, recuperar, actualizar y borrar (Que se correspondería con las estructuras de datos tradicionales). </li></ul></ul></ul><ul><ul><li>Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos. </li></ul></ul><ul><ul><li>“Las aplicaciones de gestión están constituidas mayoritariamente por objetos degenerados” </li></ul></ul>
  13. 13. Estructuras de Objetos <ul><li>Clases </li></ul><ul><ul><li>Es un tipo (o plantilla) de objeto, el cual describe un conjunto de objetos que tienen un rol equivalente en un sistema. Para crear una instancia de un objeto se usa la clase como la base para determinar como formar el objeto. </li></ul></ul><ul><li>Atributos </li></ul><ul><ul><li>Son los datos que están encapsulados dentro del objeto y determinan su estado. Algunos pueden cambiar (p.ej: un empleado puede cambiar de dirección), otros son inmutables y deben conservar el mismo valor durante la vida del objeto (p.ej: el RFC de un empleado) </li></ul></ul><ul><li>Métodos </li></ul><ul><ul><li>Son una implementación del comportamiento requerido por una clase, cada instancia de objeto proveniente de la clase tendrá éstos métodos. Podrán ser llamados por otros objetos o internamente. </li></ul></ul><ul><li>Mensajes </li></ul><ul><ul><li>Los objetos responden o actúan en función a los mensajes que reciben y el estado actual de sus atributos. Cuando se manda un mensaje a un objeto se le esta ordenando que ejecute un método y generalmente se desconoce el código que ejecutará porque está encapsulado. </li></ul></ul><ul><li>Interfases </li></ul><ul><ul><li>Es el medio fundamental de comunicación entre los objetos. La interfase describe completamente cómo van a interactuar con la clase los usuarios de la clase. La interfase pública de un objeto define cuáles mensajes aceptará sin importar de donde provengan. </li></ul></ul>
  14. 14. Estructuras de Objetos <ul><li>Herencia </li></ul><ul><ul><li>Permite a una clase heredar los atributos y métodos de otra clase, facilitando de esta forma la reutilización del código y permitiendo crear nuevas clases mediante la abstracción de los atributos y métodos comunes. </li></ul></ul><ul><ul><li>Las clases Perro y Gato heredan de la clase Mamíferos, esto significa que la clase Perro tiene los siguientes atributos: </li></ul></ul><ul><ul><ul><li>colorOjos Heredada de la clase Mamíferos </li></ul></ul></ul><ul><ul><ul><li>frecuenciaLadrido Definida solo para la clase Perro </li></ul></ul></ul><ul><ul><li>y los siguientes métodos: </li></ul></ul><ul><ul><ul><li>tomarColorOjos Heredada de la clase Mamíferos </li></ul></ul></ul><ul><ul><ul><li>Ladrar Definida solo para la clase Perro </li></ul></ul></ul>Superclase Subclases Mamíferos - colorOjos: int + TomarColorOjos: int Perro -frecuenciaLadrido: int + Ladrar: int gato -frecuenciaMaullido:int + Maullar: int
  15. 15. Estructuras de Objetos <ul><li>Abstracción </li></ul><ul><ul><li>Quitar las propiedades y acciones de un objeto para dejar sólo aquellas que sean necesarias. </li></ul></ul><ul><li>Polimorfismo </li></ul><ul><ul><li>Significa tener muchas formas. En lenguajes de programación significa que una entidad puede tener uno de muchos tipos. En orientación a objetos una variable polimórfica puede referirse a diferentes objetos en diferentes tiempos. Las subclases pueden hacer caso omiso de los métodos o atributos de las superclases y definir los suyos propios. </li></ul></ul><ul><ul><li>La asignación dinámica permitirá que al mandar un mensaje a un objeto se asignará dinámicamente dependiendo del código del método que haya definido la instancia de dicho objeto que puede ser uno propio o heredado. </li></ul></ul><ul><li>Encapsulamiento </li></ul><ul><ul><li>Se oculta la funcionalidad de los objetos, evitando que otros objetos o el mundo exterior puedan ver sus operaciones internas. </li></ul></ul><ul><li>Asociaciones </li></ul><ul><ul><li>Un objeto puede estar relacionado con uno o más objetos </li></ul></ul><ul><li>Composiciones </li></ul><ul><ul><li>La agregación de objetos permite definir composiciones, en las que cada componente se considera como tal sólo como parte del objeto compuesto. </li></ul></ul>
  16. 16. Estructuras de Objetos <ul><li>Diagramas </li></ul><ul><ul><li>Para describir el diseño de un sistema, el lenguaje que usemos debe estar basado en diagramas, porque la experiencia nos ha mostrado que es así como pensamos en los sistemas. </li></ul></ul><ul><ul><li>No es el diseño, sino una representación de un modelo de el diseño, que captura un aspecto de el diseño de una forma que puede ser discutida. </li></ul></ul><ul><ul><li>Los modelos de diagramas a considerar son: </li></ul></ul><ul><ul><ul><li>El modelo de casos de uso que describe el sistema requerido desde el punto de vista de los usuarios. </li></ul></ul></ul><ul><ul><ul><li>El modelo estático que describe los elementos de el sistema y sus relaciones. </li></ul></ul></ul><ul><ul><ul><li>El modelo dinámico que describe el comportamiento del sistema a través del tiempo. </li></ul></ul></ul><ul><ul><li>podremos tomar una: </li></ul></ul><ul><ul><ul><li>Vista lógica nos permitirá alcanzar los requerimientos funcionales. Cuáles partes van juntas? Cuáles son las clases y sus relaciones? </li></ul></ul></ul><ul><ul><ul><li>Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el desempeño y la disponibilidad. Cuáles necesidades de control hay? Qué actividades pueden ser concurrentes? Qué sincronización debe haber? </li></ul></ul></ul><ul><ul><ul><li>Vista de desarrollo ayuda a administrar el proyecto. Cuál parte hará cada elemento del equipo de gente? Que partes pueden reusarse? </li></ul></ul></ul><ul><ul><ul><li>Vista física ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista más concreta que la de proceso.Cuales partes correrán en la misma computadora? </li></ul></ul></ul>
  17. 17. Estructuras de Objetos <ul><li>Diagramas UML </li></ul><ul><ul><li>La relación existente entre los diversos diagramas de UML se muestra a continuación: </li></ul></ul>Casos de Uso Diagrama de Secuencias Diagrama de Colaboración Diagrama de Clases Diagrama de Estados Diagrama de Actividad Diagrama de Distribución Diagrama de Componentes CODIGO
  18. 18. Diagramas Estáticos <ul><li>Objetos y Clases </li></ul><ul><ul><li>Identificar las clases que deben existir en nuestro sistema, es la parte mas grande del trabajo de diseñar sistemas orientados a objetos. </li></ul></ul><ul><ul><ul><li>Construir rápidamente y lo más barato posible el sistema que alcance nuestros requerimientos. </li></ul></ul></ul><ul><ul><ul><li>Construir un sistema que sea fácil de mantener y adaptar para los requerimientos futuros. </li></ul></ul></ul><ul><ul><li>Cada pieza de comportamiento requerida por el sistema deberá ser proporcionada de una manera sensible, por los objetos de las clases que elijamos. </li></ul></ul><ul><ul><li>Un buen modelo de clases consiste de clases de los objetos principales, los cuales no dependen de la funcionalidad particular requerida actualmente </li></ul></ul><ul><ul><li>Una técnica es la identificación de sustantivos . Descarte los candidatos que sean inapropiados por alguna razón, renombrando las clases restantes si es necesario </li></ul></ul><ul><ul><li>Pueden descartar candidatos por: redundancia, vaguedad, son un evento o una operación, son meta-lenguaje, están fuera del alcance del sistema, son un atributo. </li></ul></ul>
  19. 19. Diagramas Estáticos <ul><li>Objetos y Clases (cont.) </li></ul><ul><ul><li>Las cosas que pueden ser clases se refieren a: cosas tangibles (libro, copia, curso), roles (estudiante, maestro, bibliotecario), eventos (llegada, partida, solicitud), Interacciones (reunión, intersección) </li></ul></ul>
  20. 20. Diagramas Estáticos <ul><li>Objetos y Clases (cont.) </li></ul><ul><ul><li>Diagramas de clases </li></ul></ul><ul><ul><ul><li>Describe la vista estática de un sistema en términos de clases y relaciones entre las clases, la representación de una clase es con: </li></ul></ul></ul><ul><ul><ul><li>ejemplo: </li></ul></ul></ul><ul><ul><ul><li>Los atributos y las operaciones pueden tener diferente visibilidad . Es visible si puede ser referenciado desde otras clases diferentes a donde esta definido, se definen como públicos(+) ,privados(-) ó protegidos (#) </li></ul></ul></ul><ul><ul><ul><li>Una restricción es un texto que especifica una o varias reglas que sigue la clase, se indica mediante un texto libre encerrado entre llaves {}. Existe el OCL que define de manera formal las restricciones en UML. </li></ul></ul></ul><ul><ul><ul><li>Las propiedades se indican mediante llaves, dando propiedades a los elementos donde se haya n incluido estas. </li></ul></ul></ul>Nombre de la clase Atributos de la clase: son los datos contenidos en un objeto de la clase Operaciones de la clase: definen la forma en La cual los objetos pueden interactuar, Cuando un objeto manda un mensaje a otro, Le esta pidiendo que ejecute una operación Nombre Atributos ... Operaciones ... Automóvil + Placa:String -Datos:DatosAutomóvil + Velocidad:Integer + Dirección: Dirección +Manejar(vel:Integer, dir:Dirección) + tomarDatos(): DatosAutomóvil
  21. 21. Diagramas Estáticos <ul><li>Objetos y Clases (cont.) </li></ul><ul><ul><li>Diagramas de clases (cont.) </li></ul></ul><ul><ul><ul><li>Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual, solamente para describir estos conceptos. Una de las violaciones más comunes a esta regla consiste en agregar atributos como llaves foráneas. </li></ul></ul></ul><ul><ul><ul><li>Las operaciones son utilizadas para manipular los atributos o realizar otras acciones. Normalmente son llamadas funciones, pero están dentro de una clase y pueden aplicarse solo a objetos de esa clase. </li></ul></ul></ul><ul><ul><ul><li>Se conoce como la firma de la operación a el nombre de la operación su tipo de valor que regresa y los parámetros que utiliza. </li></ul></ul></ul><ul><ul><ul><li>Un objeto se especifica con una firma o con precondición, post-condición algoritmo y el efecto que tiene sobre un objeto. </li></ul></ul></ul><ul><ul><ul><ul><li>La precondición debe ser cierta antes de que la operación pueda ejecutarse. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La post-condición debe ser cierta después de que la operación sea ejecutada. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Estas especificaciones son como propiedades para una operación. Las propiedades usualmente no se muestran directamente en los diagramas de clases. </li></ul></ul></ul></ul><ul><ul><ul><li>Una clase persistente es aquella cuyos objetos existen aún después de que el programa que los creó ha salido. Se describe la persistencia poniendo la propiedad de “ persistent ” dentro del compartimiento del nombre. </li></ul></ul></ul><ul><ul><ul><li>Un constructor es una operación que comparte el mismo nombre que la clase y no tiene tipo definido de retorno, se utilizan generalmente para inicializar la memoria requerida por el objeto y para colocarlo en un estado inicial estable. Algunos lenguajes proveen un constructor default para las clases en caso de que no se proporcione. </li></ul></ul></ul>
  22. 22. Diagramas Estáticos <ul><li>Relaciones entre clases. </li></ul><ul><ul><ul><li>Asociación , es una conexión entre clases, lo que significa que también es una conexión entre los objetos de esas clases. En UML, una asociación es una relación que describe un conjunto de ligas, que están definidas como una conexión semántica entre un conjunto de objetos. </li></ul></ul></ul><ul><ul><ul><li>Corresponden a los verbos . Existen instancias de asociación. </li></ul></ul></ul><ul><ul><ul><li>Normalmente una asociación es bidireccional, lo que significa que si un objeto está asociado con otro objeto, ambos objetos se conocen uno al otro. </li></ul></ul></ul><ul><ul><ul><li>Asociación normal : </li></ul></ul></ul><ul><ul><ul><li>Las restricciones en las asociaciones, permiten que se siga cierta regla: </li></ul></ul></ul>Computadora Autor Usa Un autor usa una computadora Cliente Cajero Atiende Un cajero atiende a un cliente, pero cada cliente es atendido en el orden en que se encuentre en la formación {Ordenado}
  23. 23. Diagramas Estáticos <ul><li>Relaciones entre clases (cont.) </li></ul><ul><ul><ul><li>Hay asociaciones que establecen una relación en ambas direcciones </li></ul></ul></ul><ul><ul><ul><li>La multiplicidad es la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada: </li></ul></ul></ul><ul><ul><ul><li>La asociación recursiva es una asociación de una clase a sí misma, una conexión entre objetos de la misma clase </li></ul></ul></ul>Carro Persona Posee Un carro puede tener uno o mas dueños, una persona puede tener cero o más carros Poseído por 1..* 0..* Nodo * * conecta Un nodo se conecta a muchos nodos y estos a su vez se conectan con varios mas. (en una red de cómputo
  24. 24. Diagramas Estáticos <ul><li>Relaciones entre clases (cont.) </li></ul><ul><ul><ul><li>Los roles en una asociación especifican el papel que juega un objeto en una relación, se indica con un string colocado cerca de la terminal de la asociación siguiente a la clase a la cual se aplica. </li></ul></ul></ul>Contrato de Seguros Compañía Aseguradora tiene Asegurador Refiere a 1 0..* Póliza de Seguros 0..1 1 Refiere a Está expresado en un 0..* 1..* tiene Persona Asegurado casado con esposo esposa
  25. 25. Diagramas Estáticos <ul><li>Relaciones entre clases (cont.) </li></ul>
  26. 26. Diagramas Estáticos <ul><li>Tipos de asociaciones </li></ul><ul><ul><ul><li>Asociación calificada (Qualified association) . Representa la información de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno. </li></ul></ul></ul><ul><ul><ul><li>Asociación Or {or} . En algunos modelos no todas las combinaciones de asociación son válidas </li></ul></ul></ul><ul><ul><ul><li>Asociación Ordenada {ordered} . Cuando los enlaces entre objetos pueden tener un orden implícito {ordered} {ordenadas por incremento de tiempo}. </li></ul></ul></ul>Cuadro Tablero 1 1 renglón:{1,2,3} columna:{1,2,3} Académico Estudiante de Educación Media Superior Elige Comercial Elige {Or}
  27. 27. Diagramas Estáticos <ul><li>Tipos de asociaciones </li></ul><ul><ul><ul><li>Clase de Asociación . Una clase puede estar unida a una asociación. Se usa para agregar información extra sobre un enlace; por ejemplo, el tiempo en que el link fue creado. Cada enlace está asociado a un objeto de la clase de asociación. </li></ul></ul></ul><ul><ul><ul><li>Asociación ternaria (Ternary association). Más de dos clases pueden asociarse con otra, la asociación ternaria asocia tres clases. </li></ul></ul></ul>Contrato de Seguros Compañía Aseguradora Asegurador 1 0..* 0..* 1..* Persona Asegurado Póliza de Seguros 0..1 Equipo Jugador Participa en Contrato Director General Negociado por
  28. 28. <ul><li>Tipos de asociaciones (cont.) </li></ul><ul><ul><ul><li>Una agregación , es un caso especial de asociación, indica que la relación entre las clases es de alguna forma parte de un “todo”. Se describen diferentes niveles de abstracción. Se indica con rombo en blanco en el lado de la clase que agrupa a las demás. </li></ul></ul></ul><ul><ul><ul><li>Se puede tener una restricción en una agregación, como en la relación {O} que se indica con línea punteada </li></ul></ul></ul><ul><ul><ul><li>Una composición es una agregación donde cada componente puede pertenecer tan solo a un todo. Se representa con diamante sólido. </li></ul></ul></ul><ul><ul><ul><ul><li>En un juego del gato, los cuadros solo tienen sentido si están formando parte del tablero </li></ul></ul></ul></ul>Diagramas Estáticos Comida 1 Ensalada Comida PlatoFuerte Postre 1 1 1 1 {O} Tablero 1 Cuadros 9
  29. 29. Diagramas Estáticos <ul><li>Tipos de asociaciones (cont.) </li></ul><ul><ul><ul><li>La generalización es una relación entre un elemento más general y uno más específico. El elemento más específico puede tener solo información adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede heredar otra clase, pero un objeto no puede heredar otro objeto). </li></ul></ul></ul><ul><ul><ul><li>La clase específica o subclase , hereda todo de la clase general, llamada superclase . Los atributos, operaciones y todas las asociaciones son heredadas. Una clase puede ser superclase y subclase si esta en una jerarquía de clases. En gráficas de jerarquía, las clases están conectadas unas con otras, vía relaciones de generalización. </li></ul></ul></ul>Vehículo Carro Bote Camión
  30. 30. Diagramas Estáticos <ul><li>Interfaces y realizaciones </li></ul><ul><ul><li>Una interfaz es un conjunto de operaciones que especifica cierto aspecto de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras. Se usa el símbolo de clase pero sin atributos, solamente con las operaciones: </li></ul></ul><ul><ul><li>Adicionalmente la interfaz puede ser representada como un circulo conectado con una línea a la clase </li></ul></ul>Teclado marca cantidadDeteclas Ctrl() Alt() RePag() AvPag() ... «interfaz» MaquinaDeEscribir Teclazo() Teclado MaquinaDeEscribir
  31. 31. Diagramas Estáticos <ul><li>Diagrama de objetos </li></ul><ul><ul><ul><li>Un diagrama de objetos en UML usa la misma notación que los diagramas de clases, ya que los objetos solo son instancias de la misma clase. </li></ul></ul></ul>Clases: Objetos: Usa 0..* 1..* Autor nombre: String edad: Integer Computadora nombre: String memoria: Integer Juan: Autor nombre= “Juan P.” edad = 33 Bob1:Computadora nombre=“IBM 128” Memoria=128
  32. 32. Diagramas Estáticos <ul><li>Diagrama de Clases </li></ul><ul><ul><ul><li>Modelo Conceptual de Punto de Venta </li></ul></ul></ul>VentasLinea deProducto cantidad Venta Fecha Hora Pago Monto Cliente TPDV Tienda Dirección Nombre Catalogo deProducto Especificacion deProducto Descripcion Precio Codigode barras Producto Gerente Cajero Pagado-por Iniciado-por Contenidas-en Capturadas-en Capturas terminadas Registra-ventas-en Iniciado-por Almacena Usado-por Contiene Describe Descritas-por Registra-venta-de 0..1 1 1 1 1 1 1 1..* * 1 1 1 * 1 1..* Contiene 1 1 1 1 1..* * 1 1 * 1 1 *
  33. 33. Diagramas Dinámicos <ul><li>Diagramas de estados </li></ul><ul><ul><li>Presenta los estados en los que puede encontrarse un objeto junto con las transiciones entre los estados, y muestra los puntos inicial y final de una secuencia de cambios de estado. </li></ul></ul><ul><ul><li>Los símbolos UML en un diagrama de estados son: </li></ul></ul><ul><ul><li>Las actividades cuentan con sucesos y acciones de entrada (qué sucede cuando el sistema entra al estado), salida (Qué pasa cuando el sistema sale del estado) y de hacer (que sucede cuando el sistema está en el estado) </li></ul></ul>Nombre Variables de estado Actividades Inicio Transición Evento que dispara Estado Transición Fin
  34. 34. Diagramas Dinámicos <ul><li>Diagramas de estados (cont.) </li></ul><ul><ul><ul><li>Se puede agregar ciertos detalles a las líneas de transición, para indicar un suceso que provoca una transición (la que desencadena un suceso) y la actividad de cómputo que se ejecute y haga que suceda la modificación de estado. </li></ul></ul></ul><ul><ul><ul><li>Las condiciones de seguridad permiten establecer una relación entre estados que dependen de que se cumpla dicha condición. </li></ul></ul></ul>Inicialización Hacer/Arrancar Encender la PC Apagado Operación Apagar Inicialización Hacer/Arrancar Encender la PC Apagado Operación Apagar Protector De pantalla [lapso transcurrido] Teclazo o movimiento del ratón
  35. 35. Diagramas Dinámicos <ul><li>Diagramas de estados (cont.) </li></ul><ul><ul><li>Subestados . Cuando un estado se encuentra dentro de otro estado, se conocen como subestados. </li></ul></ul><ul><ul><ul><li>Se dice que pueden suceder en forma secuencial cuando suceden uno tras de otro y se representan dentro del cuadro de estado original, ligados secuencialmente. </li></ul></ul></ul><ul><ul><ul><li>También has subestados concurrentes cuando pueden ocurrir al mismo tiempo. Se representan dentro del estado original, separados por línea punteada. </li></ul></ul></ul>A la espera de acción del usuario Registro de una acción del usuario Representación de la acción del usuario Verificar el conómetro del sistema Actualizar despliegue [lapso transcurrido] Operación
  36. 36. Diagramas Dinámicos <ul><li>Diagramas de estados (cont.) </li></ul><ul><ul><li>Estados históricos. </li></ul></ul><ul><ul><ul><ul><li>Se dice de los estados compuestos que pueden recordar su subestado activo cuando el objeto trasciende fuera de tal estado compuesto. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Se representa con una H y en caso de subestados anidados se dice que es histórico profundo cuando alcanza a recordar varios niveles (H*) en caso contrario se dice que es superficial </li></ul></ul></ul></ul>A la espera de acción del usuario Registro de una acción del usuario Representación de la acción del usuario Verificar el conómetro del sistema Actualizar despliegue [lapso transcurrido] Operación H Teclazo o movimiento del ratón [lapso transcurrido]
  37. 37. Diagramas Dinámicos <ul><li>Diagramas de estados (cont.) </li></ul><ul><ul><li>Cuando utilizar los diagramas de estados: </li></ul></ul><ul><ul><ul><li>Se tendría que hacer uno por cada clase del sistema, pero se sugiere hacerlos solo para aquellos que presenten un estado interesante y cuando la construcción de tales diagramas ayude a aclarar lo que sucede. </li></ul></ul></ul><ul><ul><ul><li>Algunos sugieren usarlos en los objetos de interfaz de usuario y de control, debido a que tienen el tipo de comportamiento que es útil describir mediante diagramas de estado. </li></ul></ul></ul><ul><ul><ul><li>En caso de que se desee representar las secuencias general de acciones de vario objetos y casos de uso, es mejor utilizar el diagrama de actividades. </li></ul></ul></ul>
  38. 38. Diagramas Dinámicos <ul><li>Diagramas de actividades </li></ul><ul><ul><li>Describen como se coordinan las actividades, muestran como puede ser implementada una operación que debe realizar muchas tareas diferentes y se desea mostrar cuales son las dependencias esenciales entre ellas. </li></ul></ul><ul><ul><li>Elementos de un diagrama de actividades: </li></ul></ul><ul><ul><ul><li>La actividad se muestra como una caja con nombre con las esquinas muy redondeadas, representa cuando la actividad ha terminado </li></ul></ul></ul><ul><ul><ul><li>La transición se muestra como una flecha, normalmente no se les pone etiqueta, a menos que se tenga una condición. </li></ul></ul></ul>Actividad Actividad 1 Actividad 2
  39. 39. Diagramas Dinámicos <ul><li>Diagramas de actividades (cont.) </li></ul><ul><ul><ul><li>Barras de sincronización , indica coordinación de actividades y no se puede pasar de la barra hasta que todas las actividades previas a la barra han sido terminadas. Se utilizan para la ejecución de actividades en paralelo. </li></ul></ul></ul>Fin de la jornada Baño Descanso
  40. 40. Diagramas Dinámicos <ul><li>Diagramas de actividades (cont.) </li></ul><ul><ul><li>Las indicaciones , permiten que se ejecuten otras actividades, usando un pentágono convexo para el envío del un evento y uno cóncavo para la recepción del evento. </li></ul></ul>Oprimir numero de canal Cambiar(canal) Fin de la jornada Televisión Remoto.Tecleo (canal) Oprimir numero de canal Cambiar(canal)
  41. 41. Diagramas Dinámicos <ul><li>Diagramas de actividades (cont.) </li></ul><ul><ul><ul><li>Diamantes de decisión se usan para mostrar decisiones como una alternativa a las condiciones, para separar transiciones dejando el mismo estado. </li></ul></ul></ul><ul><ul><ul><li>Marcas de inicio y fin se usan para indicar donde empieza el diagrama y donde termina. </li></ul></ul></ul><ul><ul><ul><li>Particiones y líneas de responsabilidad , Al poner muchas actividades relacionadas entre sí, se pueden colocar de acuerdo al objeto o al actor que las ejecuta, o a cuál caso de uso pertenecen </li></ul></ul></ul><ul><ul><li>Las principales diferencias entre los diagramas de estado y los diagramas de actividades son: </li></ul></ul><ul><ul><ul><li>Los diagramas de actividades normalmente NO incluyen eventos, porque los únicos eventos de interés es la terminación de las actividades. </li></ul></ul></ul><ul><ul><ul><li>Las actividades se pretende que se continúen a lo largo del diagrama sin quedarse estancadas. </li></ul></ul></ul>
  42. 42. Diagramas Dinámicos <ul><li>Diagramas de actividades (cont.) </li></ul><ul><ul><li>Ejemplo de un diagrama de actividades en una biblioteca. </li></ul></ul>Encontrar libro en gaveta [prestatario] Esperar en la fila [regresador] Registrar el regreso Poner el libro de Regreso en gaveta Registrar el préstamo Preparar para el siguiente miembro miembro bibliotecario [regresando] [obteniendo prestado]
  43. 43. Diagramas Dinámicos <ul><li>Diagramas de actividades (cont.) </li></ul><ul><ul><li>Cuando utilizar diagramas de actividades: </li></ul></ul><ul><ul><ul><li>Debido a que manejan y promueven el comportamiento en paralelo, son una herramienta muy útil para el modelado de flujo de trabajo y para la programación multihilos. </li></ul></ul></ul><ul><ul><ul><li>Se recomienda usarlos para: </li></ul></ul></ul><ul><ul><ul><ul><li>El análisis de un caso de uso . Para comprender qué acciones deben ocurrir y cuáles son las dependencias de comportamiento. Asignando posteriormente los métodos a los objetos y mostrando tales asignaciones mediante diagramas de secuencia o colaboración. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La comprensión del flujo de trabajo, a través de numerosos casos de uso . Para representar y entender el comportamiento de las interacciones entre los casos de uso. Ayuda a aclarar situaciones dominadas por flujo de trabajo. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Cuando se trata de aplicaciones multihilos. Son adecuados en éste uso </li></ul></ul></ul></ul><ul><ul><ul><li>No sirven para: </li></ul></ul></ul><ul><ul><ul><ul><li>Tratar de ver como colaboran los objetos . Usar mejor diagramas de secuencia o colaboración. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Para tratar de ver como se comporta un objeto durante su período de vida . Es mejor usar un diagrama de estados. </li></ul></ul></ul></ul>
  44. 44. Diagramas Dinámicos <ul><li>Diagrama de secuencias. </li></ul><ul><ul><li>Muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo. Constan de objetos y representando en una línea vertical el tiempo, se indican las operaciones que ejecuta el objeto o activación se representan mediante un rectángulo cuya altura va en relación a la duración de la operación. </li></ul></ul><ul><ul><li>Los mensajes van de un objeto a otro se representan con líneas. Pueden ser simples (transfieren control), sincrónicos (esperan respuesta) o asincrónicos (no espera respuesta) </li></ul></ul>:Objeto 1 :Objeto 2
  45. 45. Diagramas Dinámicos <ul><li>Diagrama de secuencias. (cont.) </li></ul><ul><ul><ul><li>Para ilustrar los diagramas de secuencia se usará el siguiente caso de uso: </li></ul></ul></ul><ul><ul><ul><ul><li>La ventana Entrada de pedido envía un mensaje “prepara” a Pedido. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El Pedido envía entonces un mensaje “prepara” a cada línea de pedido dentro del Pedido. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Cada Línea de pedido revisa el Artículo de inventario correspondiente. </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>- Si esta revisión devuelve “verdadero”, la Línea de pedido descuenta la cantidad apropiada de Artículo de inventario del almacén. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Si no sucede así, quiere decir que la cantidad del Artículo de inventario ha caído más abajo del nivel de reorden y entonces dicho Artículo de inventario solicita una nueva entrega. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>En el diagrama siguiente se muestra el diagrama de secuencia omitiendo las activaciones, que según Fowler, no aportan mucho a la ejecución de procedimientos y solamente sugiere usarlas en situaciones concurrentes. </li></ul></ul></ul></ul>
  46. 46. Diagramas Dinámicos <ul><li>Diagrama de secuencias. (cont.) </li></ul><ul><ul><li>El siguiente ejemplo muestra </li></ul></ul>Ventana de Entrada de Pedidos unPedido prepara() Una Línea de Pedido Un artículo de inventario *[para cada línea de pedido] prepara() hayExistencia:= revisa() [hayExistencia] descuenta() necesitaReorden:= necesitareordenar() Un Artículo de reorden [necesitaReorden] nuevo Un Artículo para entrega [hayExistencia] nuevo() Objeto Iteración Mensaje Condición Autodelegación Creación Regreso
  47. 47. Diagramas Dinámicos <ul><li>Diagrama de secuencias. (cont.) </li></ul><ul><ul><li>De el objeto se desprende una línea vertical conocida como línea de vida del objeto y representa el tiempo de duración del objeto durante la interacción. </li></ul></ul><ul><ul><li>Los mensajes representados por líneas están en orden de arriba hacia abajo. La autodelegación es un mensaje que un objeto se manda a sí mismo. </li></ul></ul><ul><ul><li>Una condición indica cuándo se envía un mensaje, el cual se enviará solo si la condición es verdadera. </li></ul></ul><ul><ul><li>Una iteración muestra cuando un mensaje se envía varias veces a varios objetos receptores, como sucedería cuando se itera sobre una colección. </li></ul></ul><ul><ul><li>El regreso indica el regreso de un mensaje, no un nuevo mensaje. Los regresos SATURAN los diagramas y tienden a oscurecer el flujo, Fowler recomienda usarlo solamente cuando ayuden a aumentar la claridad. </li></ul></ul><ul><ul><li>El borrado de un objeto se muestra con una X grande. Los objetos pueden autodestruirse o pueden ser destruidos mediante otro mensaje. </li></ul></ul>
  48. 48. Diagramas Dinámicos <ul><li>Diagrama de secuencias. (cont.) </li></ul><ul><ul><li>Otra ilustración adicional nos permitirá visualizar las activaciones y la creación de objetos. </li></ul></ul><ul><ul><li>Ejemplo de una transacción bancaria: </li></ul></ul><ul><ul><ul><li>Cuando se crea una Transacción, ésta crea un Coordinador de transacción que coordina el trámite de la transacción. Este coordinador crea una cantidad (en el ejemplo, dos) de objetos Revisor de Transacción, cada uno de los cuales es responsable de una revisión particular. Este proceso permitirá añadir con facilidad otros proceso de revisión, porque cada registro es llamado asincrónicamente y opera en paralelo. </li></ul></ul></ul><ul><ul><ul><li>Cuando termina un revisor de transacción, se le notifica al coordinador de transacción. El coordinador comprueba si todos los revisores respondieron; de no ser así, no hace nada. Si todos han respondido indicando terminaciones exitosas, como en este ejemplo, entonces el coordinador notifica a la Transacción que todo está bien. </li></ul></ul></ul>
  49. 49. Diagramas Dinámicos <ul><li>Diagrama de secuencias. (cont.) </li></ul>Una Transacción nuevo nuevo unCoordinador de transacciones nuevo un primer Revisor de transacción nuevo un segundo Revisor de transacción bien bien ¿ todo terminado? ¿ todo terminado? es Válido se suprimen las demás transacciones el objeto se borra a sí mismo Autodelegación Activación Mensaje asíncrono
  50. 50. Diagramas Dinámicos <ul><li>Diagramas de secuencias. (cont.) </li></ul><ul><ul><li>Cuando utilizar los diagramas de secuencias, se sugieren para: </li></ul></ul><ul><ul><ul><li>Son útiles para ver la interacción entre los objetos, debido a que pone énfasis en la secuencia y es fácil apreciar el orden en el que ocurren las cosas. </li></ul></ul></ul><ul><ul><ul><li>Cuando se desee ver el comportamiento de varios objetos en un caso de uso y la secuencia de los mensajes. </li></ul></ul></ul><ul><ul><li>No se sugieren para: </li></ul></ul><ul><ul><ul><li>No son convenientes para representar el comportamiento condicional, debido a que son para mostrar un comportamiento simple, se sugiere usar mejor diagramas separados para cada una de las condiciones </li></ul></ul></ul><ul><ul><ul><li>No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados) </li></ul></ul></ul><ul><ul><ul><li>Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad. </li></ul></ul></ul>
  51. 51. Diagramas Dinámicos <ul><li>Diagramas de colaboraciones. </li></ul><ul><ul><li>Muestra los objetos,las relaciones entre ellos, los mensajes que se envían los objetos entre sí. </li></ul></ul><ul><ul><ul><li>El mensaje se representa como una flecha cerca de la línea de asociación entre dos objetos. Esta flecha apunta al objeto receptor. El tipo de mensaje se mostrará en una etiqueta cerca de la flecha. </li></ul></ul></ul><ul><ul><ul><li>El mensaje le indicará al objeto receptor que ejecute una de sus operaciones. </li></ul></ul></ul><ul><ul><ul><li>Un diagrama de secuencias puede ser convertido en uno de colaboraciones y viceversa. </li></ul></ul></ul><ul><ul><ul><li>Se agregará una cifra al mensaje para indicar la secuencia propia del mensaje. </li></ul></ul></ul>:Nombre1 :Nombre2 :Nombre3 1:Agregar() 3:Actualizar() 2:Modificar()
  52. 52. Diagramas Dinámicos <ul><li>Diagramas de colaboraciones. (cont.) </li></ul><ul><ul><li>Ejemplo de un diagrama de colaboraciones: </li></ul></ul><ul><ul><ul><li>El actor es el usuario quien inicia la interacción al oprimir una tecla, se inicia la siguiente secuencia: </li></ul></ul></ul><ul><ul><ul><ul><li>La GUI notifica al sistema operativo que se oprimió la tecla </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El sistema operativo le notifica a la CPU </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El sistema operativo actualiza la GUI </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La CPU notifica a la tarjeta de video </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La tarjeta de video envía un mensaje al monitor </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El monitor presenta el carácter alfanumérico en la pantalla, con lo que se hará evidente al usuario. </li></ul></ul></ul></ul>:GUI :Sistema operativo :CPU :Tarjeta de video :Monitor Tecleo 1:notificar(tecleo) 3:actualizar(tecleo) 2:actualizar(tecleo) 4:notificar(tecleo) 5:mostrar(tecleo) 6:respuesta()
  53. 53. Diagramas Dinámicos <ul><li>Diagramas de colaboraciones. (cont.) </li></ul><ul><ul><li>Cuando utilizar los diagramas de colaboración, se sugieren para: </li></ul></ul><ul><ul><ul><li>Es la mejor forma si se quiere mostrar los objetos y mostrar como se reconectan estáticamente unos con otros. </li></ul></ul></ul><ul><ul><ul><li>Cuando se desee ver el comportamiento de varios objetos en un caso de uso. </li></ul></ul></ul><ul><ul><ul><li>Sirven para mostrar la colaboración entre los objetos, sin embargo, no sirven tan bien para la definición precisa del comportamiento </li></ul></ul></ul><ul><ul><li>No se sugieren para: </li></ul></ul><ul><ul><ul><li>No son convenientes para representar el comportamiento condicional, debido a que son para mostrar un comportamiento simple, se sugiere usar mejor diagramas separados para cada una de las condiciones </li></ul></ul></ul><ul><ul><ul><li>No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados) </li></ul></ul></ul><ul><ul><ul><li>Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad. </li></ul></ul></ul>
  54. 54. Diagramas de Implementación <ul><li>Diagramas de componentes </li></ul><ul><ul><li>Un componente es la implementación de un subsistema, la cual da las especificaciones (en términos de casos de uso) y una estructura de clases que lleva a cabo la especificación. Su representación es: </li></ul></ul><ul><ul><li>Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia , Clasificándolos en relación con el proceso de compilación un componente podría ser: </li></ul></ul><ul><ul><ul><li>Código fuente , el cual depende de que otros componentes estén disponibles al momento de compilación. </li></ul></ul></ul><ul><ul><ul><li>Código objeto binario , (biblioteca de clases) que depende de cualquier código objeto al cuál se ligara desde un programa ejecutable. </li></ul></ul></ul><ul><ul><ul><li>Una aplicación ejecutable , la cuál puede depender de otros programas ejecutables al tiempo de ejecución. </li></ul></ul></ul><ul><ul><li>Los detalles dependen del lenguaje de programación usado, se pueden usar estereotipos como «compilar» ó «ligar», igualmente se pueden usar estereotipos para diferenciar los diferentes tipos de componentes, por ejemplo: «archivo» , «biblioteca» , «ejecutable» , «tabla», «documento» </li></ul></ul>calculadora.java
  55. 55. Diagramas de Implementación <ul><li>Diagramas de componentes (cont.) </li></ul><ul><ul><li>Cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo . </li></ul></ul><ul><ul><li>La especificación contiene la interfaz de la clase mientras que el cuerpo contiene la realización de la clase. </li></ul></ul><ul><ul><li>En el caso de clases parametrizables se puede dar una especificación genérica. </li></ul></ul><ul><ul><li>Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro. </li></ul></ul><ul><ul><li>Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación. Son paquetes estereotipados en « subsistemas » para incorporar la noción de biblioteca de compilación y de gestión de configuración. </li></ul></ul>
  56. 56. Diagramas de Implementación <ul><li>Diagramas de componentes (cont.) </li></ul><ul><ul><li>Un diagrama de componentes mostrando las dependencias de tiempo de compilación: </li></ul></ul><ul><ul><li>La interfaz se puede representar por una línea con un círculo </li></ul></ul>streams.o « biblioteca » MiEntradaSalida MiAplicación « ejecutable » « compilar » « ligar » Programa de búsqueda Resultado de la búsqueda
  57. 57. Diagramas de Implementación <ul><li>Diagramas de componentes (cont.) </li></ul><ul><ul><li>Si un componente implementa clases se puede establecer la relación entre el componente y las clases como sigue: </li></ul></ul>ó ProcesadorTextos VerificadorOrtografico ContadorPalabras ProcesadorTextos.exe Clases: ProcesadorTextos VerificadorOrtografico ContadorPalabras ProcesadorTextos.exe
  58. 58. Diagramas de Implementación <ul><li>Diagramas de componentes (cont.) </li></ul><ul><ul><li>Solo se podrán ejecutar las operaciones dentro de un componente a través de su interfase . La relación entre un componente y su interfase se conoce como realización . Un componente puede acceder a los servicios de otro componente mediante el uso de su interfase, al que proporciona el servicio se dice que provee una interfaz de exportación , al que accede a un servicio se dice que utiliza una interfaz de importación . </li></ul></ul><ul><ul><li>Se puede sustituir un componente por otro si el nuevo contiene las mismas interfases que el anterior. Se puede reutilizar un componente en otro sistema si éste puede acceder al componente reutilizado mediante sus interfases. </li></ul></ul>AWTEventMulticaster « Interfaz » ElementoDeEscucha cambioAlEstadoDelElemento()
  59. 59. Diagramas de Implementación <ul><li>Diagramas de componentes (cont.) </li></ul><ul><ul><li>Página Web con controles ActiveX. </li></ul></ul>VBScript Animacion.htm «ActiveX» DisposicionAnimacion.alx «ActiveX» ImagenEsfera «ActiveX» CronometroEsfera «ActiveX» CuadroCombCronometro «ActiveX» BotonReinicar «ActiveX» CuadroCombDistancia «ActiveX» BotonDetener «ActiveX» BotonEjecutar Esfera.gif
  60. 60. Diagramas de Implementación <ul><li>Diagramas de distribución. </li></ul><ul><ul><li>Los diagramas de distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. </li></ul></ul><ul><ul><li>Un nodo representa todo tipo de equipo de cómputo y se representa por un cubo: </li></ul></ul><ul><ul><li>Los estereotipos permiten precisar la naturaleza del equipo: </li></ul></ul><ul><ul><ul><li>Dispositivos </li></ul></ul></ul><ul><ul><ul><li>Procesadores </li></ul></ul></ul><ul><ul><ul><li>Memoria </li></ul></ul></ul><ul><ul><ul><li>Etc. </li></ul></ul></ul>Nodo
  61. 61. Diagramas de Implementación <ul><li>Diagramas de distribución. </li></ul><ul><ul><li>Los nodos se interconectan mediante soportes bidireccionales (en principio) que puede a su vez estereotiparse. </li></ul></ul><ul><ul><li>Se pueden mostrar los componentes en relaciones de dependencia con un nodo: </li></ul></ul>Servidor Directorio telefónico corporativo Programa de búsqueda Resultado de la búsqueda
  62. 62. Diagramas de Implementación <ul><li>Diagramas de distribución. (cont.) </li></ul><ul><ul><li>Las conexiones entre nodos se puede poner mediante una relación </li></ul></ul>Cliente Programa de Presentación Servidor Directorio telefónico corporativo Programa de búsqueda Resultado de la búsqueda «Comunicación»
  63. 63. Diagramas de Implementación <ul><li>Diagramas de distribución. (cont.) </li></ul><ul><ul><li>Aplicación de los diagramas de distribución. </li></ul></ul><ul><ul><ul><li>Un equipo de cómputo casero podría ser como sigue: </li></ul></ul></ul>PC Pentium 300Mhz Windows 95 Office 2000 Visio 5Enterprise PC Pentium 300Mhz Windows 95 Office 2000 Internet Explorer «Dispositivo» Scanner Microtek SlimScanC3 «Dispositivo» Monitor Daewoo CMC-1505 «Dispositivo» Impresora HP Deskjet 610L «Dispositivo» Impresora HP Lasejet 5L «Dispositivo» Camara Digital Polaroid Flash640 «Dispositivo» Modem ESS 336V «Dispositivo» Monitor PackardBell «Dispositivo» Conector T «Dispositivo» Conector T «Dispositivo» Terminador «Dispositivo» Terminador «Procesador» ISP Infosel.net Internet
  64. 64. Caso de Estudio (CS4) <ul><li>Presentación del caso. </li></ul><ul><ul><li>Administración CS4 </li></ul></ul><ul><ul><li>Un estudiante CS4 (eCS4) , es cualquier estudiante que esta tomando cualquier módulo de cuarto año en el departamento de ciencias computacionales, ya sea que este o no inscrito para un grado en ciencias computacionales. </li></ul></ul><ul><ul><li>Al final de cada año académico, el Comité Académico de el Departamento de Ciencias Computacionales determina qué módulos estarán disponibles para los eCS4 en el siguiente año. </li></ul></ul><ul><ul><li>Al final de cada año el Jefe del Departamento fija actividades para los miembros del cuerpo de maestros y otros, en particular a una persona es asignada para enseñar cada uno de los módulos que se supone van a estar disponibles para el próximo año ( adjunto ) </li></ul></ul><ul><ul><li>Cada profesor adjunto actualiza los apuntes en el manual del curso de su módulo. El coordinador CS4 ( CCS4 ) actualiza otras partes de cada manual y checa los apuntes producidos por los profesores adjuntos. Los apuntes de los módulos están escritos en el lenguaje de formato L A T E X. </li></ul></ul><ul><ul><li>Alguien en la Oficina de Enseñanza Profesional ( OEP ) produce la versión en papel de cada manual de curso; el CCS4 produce la versión HTML ejecutando la aplicación latex2html sobre la fuente L A T E X. </li></ul></ul><ul><ul><li>El CCS3 proporciona una lista de los estudiantes entrando a CS4 provenientes de CS3 al CCS4 y al OEP . El CCS4 le dice al OEP acerca de cualquier otro estudiante que provenga de de otros cursos que no sean CS3. El OEP mantiene la lista maestra de todos los eCS4 y actualiza las listas de correo de los estudiantes tomando cursos CS4, la cual se conoce por la dirección de correo cs4class . </li></ul></ul><ul><ul><li>Cada estudiante es avisado por un miembro del cuerpo de maestros que actúa como Director de Estudios ( DdE ). Un DdE se asigna a un estudiante en su primer año de estudios y permanece con ésa función hasta que termina. </li></ul></ul><ul><ul><li>Los estudiantes se inscriben en forma provisional en los módulos llenando una forma y entregándola en la Oficina de Enseñanza Profesional . El OEP verifica que cada estudiante que se inscriba, esté listado como un eCS4 , y cada eCS4 es inscrito en un numero razonable de módulos. En caso de duda, se consulta al DdE del estudiante y se puede tener una plática con el estudiante. </li></ul></ul><ul><ul><li>El OEP produce luego las listas para los adjuntos de los estudiantes que tomarán sus módulos. Estas listas no pueden llegarles a los adjuntos antes de la semana 3. Esto es, muy tarde para que los adjuntos puedan saber cuántas copias deben preparar de su material. </li></ul></ul>
  65. 65. Caso de Estudio (CS4) <ul><li>Administración CS4 (cont.) </li></ul><ul><ul><li>Cada uno de los cursos de grado tiene su propio manual de curso, los principales cursos existentes son: Ciencias Computacionales, Ciencias Computacionales e Inteligencia Artificial, Ciencias Computacionales y la Ingeniería Electrónica, etc. </li></ul></ul><ul><ul><li>Los detalles de la asesoría y las reglas acerca de cuáles combinaciones de módulos son aceptables, son diferentes para cada grado, igualmente hay manuales separados para cada uno de ellos. </li></ul></ul><ul><ul><li>Sin embargo, muchos módulos se aceptan en varios diferentes cursos de grado, y en cada caso la descripción de cada curso es igual en cada manual. </li></ul></ul><ul><ul><li>Cada estudiante se inscribe para un curso de grado y recibe el manual de curso apropiado. </li></ul></ul><ul><ul><li>El CCS4 de producir todos los manuales de cursos (en los casos de alumnos adjuntos que lleven los cursos es posible que reciban duplicado el manual, debido a que los otros departamentos producen sus propios manuales) </li></ul></ul><ul><ul><li>Se pide desarrollar un sistema que permita: </li></ul></ul><ul><ul><ul><li>Disminuir la cantidad de trabajo rutinario para todo el staff, especialmente el CCS4 . </li></ul></ul></ul><ul><ul><ul><li>Permitir a los estudiantes inscribirse en los módulos en línea. </li></ul></ul></ul><ul><ul><ul><li>Que el OEP pueda obtener fácilmente información actualizada y confiable. </li></ul></ul></ul><ul><ul><ul><li>Mejorar el seguimiento de dicha información. </li></ul></ul></ul><ul><ul><ul><li>Hacer que la información tal como los manuales de cursos y las listas de los estudiantes que toman los cursos estén disponibles cuanto antes, automatizando su producción. </li></ul></ul></ul><ul><ul><ul><li>El sistema de administración CS4 deberá poder producir un informe sobre cada eCS4 indicando si es de 4to año o aún no se gradúa, qué módulos está tomando el estudiante, cuales cursos de grado esta llevando un eCS4 , o cuál miembro del staff es el DdE de un eCS4 . </li></ul></ul></ul><ul><ul><ul><li>Deberá poder dar información sobre los módulos, quiénes los imparten, de que curso forman parte y que estudiantes los están tomando. </li></ul></ul></ul>
  66. 66. Caso de Estudio (CS4) <ul><li>Diagrama de casos de uso (CS4) </li></ul><ul><ul><li>Las consultas pueden ser realizadas mediante una base de datos y usando técnicas estándar para hacer objetos persistentes. Y se dejará fuera de la respuesta, quedando pues los siguientes casos de uso: </li></ul></ul><ul><ul><ul><li>Producir el manual del curso </li></ul></ul></ul><ul><ul><ul><li>Producir la lista CS4 </li></ul></ul></ul><ul><ul><ul><li>Inscribir en los módulos. </li></ul></ul></ul>Producir la lista CS4 Producir el manual del curso Inscribir en los Módulos Organizador Cursos CS3 CCS4 OEP Adjunto CS4 eCS4 Director de estudios CS4
  67. 67. Caso de Estudio (CS4) <ul><li>Diagrama de casos de uso (CS4) </li></ul><ul><ul><li>Descripción de caso de uso: Producir el manual del curso </li></ul></ul><ul><ul><ul><li>Este caso de uso se puede usarse solamente cuando el comité académico ha determinado el conjunto de módulos que estarán disponibles y que el jefe de departamento ha asignado los adjuntos. </li></ul></ul></ul><ul><ul><ul><li>El organizador de CS4 actualiza las secciones principales de cada manual de curso obteniendo el texto actual del sistema, modificándolo y regresándolo modificado al sistema. </li></ul></ul></ul><ul><ul><ul><li>El adjunto de cada módulo, actualiza la descripción del módulo tomándolo del sistema, actualizándolo y regresándolo al sistema. </li></ul></ul></ul><ul><ul><ul><li>Estas actualizaciones pueden suceder en cualquier orden. El sistema conserva el registro de cuáles cambios se han hecho. Una vez que se hicieron todas las actualizaciones, el sistema envía el texto completo del manual por correo electrónico al OEP, el cual imprime y actualiza la pagina Web del mismo. </li></ul></ul></ul><ul><ul><li>Desarrolle las descripciones de los casos de uso para: </li></ul></ul><ul><ul><ul><li>Producir la lista CS4 </li></ul></ul></ul><ul><ul><ul><li>Inscribir en los módulos. </li></ul></ul></ul>
  68. 68. Caso de Estudio (CS4) <ul><li>Diagrama de clases (CS4) </li></ul><ul><ul><li>Un diagrama de clases a nivel conceptual, sin incluir actividades y operaciones: </li></ul></ul>Adjunto Módulo Cursos Grado Estudiante 4to año Estudiante otros años Estudiante Director de Estudios 1 1 0..* 6..* 1..* 6 1..* 0..* 0..* 1 Imparte toma dirige esta en
  69. 69. Caso de Estudio (CS4) <ul><li>Diagrama de actividad (CS4) </li></ul><ul><ul><li>El siguiente diagrama muestra el flujo de trabajo requerido para determinar qué cursos hay, quien los imparte, generar los manuales de los cursos: </li></ul></ul>Determinar los módulos Comité Académico Asignar Adjuntos Jefe de Departamento Adjunto OEP CCS4 Imprimir manual Generar versión HTML Actualizar secciones principales Actualizar registro de módulo
  70. 70. Caso de Estudio (Restaurante) <ul><li>Presentación del caso. </li></ul><ul><ul><li>Las empresa Restaurantes,S.A. ha hecho una encuesta sobre el mundo de los restaurantes y ha llegado a sorprendentes conclusiones: a la gente le gusta comer fuera, pero no disfruta algunos momentos de ésa experiencia. Y deciden construir el restaurante del futuro, que deje a la gente darse el gusto y que mejore los resultados para el cliente. </li></ul></ul><ul><ul><li>Entrevista de Análisis </li></ul></ul><ul><ul><li>¿ Qué sucede cuando un cliente entra al restaurante ? R: Si el cliente tiene un abrigo,le ayudamos a quitárselo, lo almacenamos en el guardarropa y le damos un boleto para solicitarlo posteriormente. Lo mismo hacemos con el sombrero. </li></ul></ul><ul><ul><li>¿ Y si hay línea de espera, se forma ? R: Se le pregunta si hizo reservación, en cuyo caso lo pasamos lo más pronto posible. Si no hay reservación deja su nombre y puede ir al bar a tomar algo antes de comer o esperar sentado en área de espera. </li></ul></ul>[Prefiere el área de espera] Entra el cliente Ayudar a quitárselo Guardarlo Dejar su nombre Espera en el bar Aguarda en el Área de espera [Tiene abrigo y/o sombrero] [Lista de espera] [No hizo reservación] [Prefiere el bar]
  71. 71. Caso de Estudio (Restaurante) <ul><li>Presentación del caso. (cont.) </li></ul><ul><ul><li>Entrevista de Análisis (cont.) </li></ul></ul><ul><ul><li>¿ Cuando le llega el turno al cliente, es hora de sentarlo ? R: La mesa deberá estar lista; para ello, deberá ser limpiada. Un mozo de piso debe cambiar el mantel usado por el cliente anterior y acomodar la mesa. Cuando esta lista el capitán de meseros lleva al cliente a su mesa y luego llama a un mesero, si el cliente estaba bebiendo en el bar, se podrá llevar su bebida. Los meseros tienen asignadas sus áreas de servicio y saben cuando está lista una mesa. </li></ul></ul><ul><ul><li>¿ Luego que ocurre ? R: El mesero llega a la mesa, entrega un menú a cada comensal y les pregunta si desean alguna bebida mientras deciden. Luego llama a un “asistente” quién coloca una charola con pan y mantequilla. Si alguien ha pedido una bebida el mesero la traerá. </li></ul></ul><ul><ul><li>¿ Cómo deciden los clientes qué van a consumir ? R: El mesero propone siempre a los clientes la sugerencia del día y les da de 5 a 10 minutos para que decidan. Cuando el cliente llama la atención del mesero, éste regresa a tomarle su orden. Y luego lo notifica al chef. Mediante la transcripción de la elección en un formulario, llamado comanda. </li></ul></ul><ul><ul><li>¿ Qué contiene la comanda ? R: La mesa, la elección y la hora. Debido a que generalmente la cocina está muy ocupada y el chef tiene que dar prioridad a las comandas en el orden que hayan llegado. </li></ul></ul><ul><ul><li>¿ Por qué es tan importante la prioridad ? R: La mayoría de las comidas incluyen un entremés antes del plato fuerte. A la mayoría de la gente le gusta comer el plato fuerte caliente, el chef prepara el entremés y el mesero se lo lleva al cliente. El reto está en llevar el plato fuerte, caliente a todos los comensales en la mesa al mismo tiempo. </li></ul></ul>
  72. 72. Caso de Estudio (Restaurante) <ul><ul><li> Diagrama: “Servir a un cliente” </li></ul></ul>[Prefiere el área de espera] Entra el cliente Ayudar a quitárselo Guardarlo Dejar su nombre Espera en el bar Aguarda en el Área de espera [Tiene abrigo y/o sombrero] [Lista de espera] [No hizo reservación] [Prefiere el bar] Alistar la mesa Sentar al cliente Llamar al mesero Mostrar el menú Tomar un pedido de bebidas [Desea bebida] Llamar al asistente Ir por las bebidas Servir Pan y agua Traer bebida Sugerir platillo Leer Menú Elegir Notificar al chef Traer entremes Preparar platillo Modelado en un diagrama Por separado
  73. 73. Caso de Estudio (Restaurante) <ul><li>Entrevista de Análisis (cont.) </li></ul><ul><ul><li>¿ Cómo le sirven al cliente ? R: El chef preparará el plato fuerte y el mesero lo recogerá cuando se dé cuenta de que los comensales han terminado con el entremés; después el mesero lleva el plato fuerte a la mesa. Los comensales ingerirán sus alimentos, y el mesero regresará al menos una vez para verificar si todo está bien. </li></ul></ul><ul><ul><li>¿ Qué sucede cuando los clientes terminan de comer ? R: El mesero regresa y pregunta si desean postre, en cuyo caso el mesero dará el menú de postres y tomará las órdenes. En caso de no desearlo pregunta si desean café, en caso de aceptarlo, traerá el café, tazas y les servirá. Si no desean nada, traerá la cuenta. Luego regresará y obtendrá el pago en efectivo o en tarjeta de crédito. Luego traerá el cambio o los vouchers, los clientes dejarán una propina, recogerán sus abrigos y se irán. </li></ul></ul><ul><ul><li>¿ Qué debe hacer el mesero cuando el cliente salga ? R: Llamar al mozo de piso para limpiar la mesa, la preparará y estará lista para los siguientes comensales. </li></ul></ul>
  74. 74. Caso de Estudio (Restaurante) <ul><li>Diagrama de “Servir a un cliente” (cont.) </li></ul>Traer entremés Preparar platillo Modelado en un diagrama Por separado Traer el plato fuerte Ingerir entremés Ingerir plato fuerte Traer el menú de postres [Desea postre] Traer postres Ingerir postres Servir café Beber café [Desea café] Trae la cuenta Liquidar cuenta Dejar propina Recoger abrigo o sombrero [Guardar abrigo/sombrero] Salir
  75. 75. Caso de Estudio (Restaurante) <ul><li>Preparación de platillos </li></ul><ul><ul><li>¿ Cómo se coordina el chef para tener los platillos a tiempo ? R: La gente en una mesa casi siempre termina sus entremeses, en momentos distintos. Entre el mesero y el chef se coordinan para traerles a todos los platos fuertes al mismo tiempo. El chef recibe la comanda y empieza a preparar los entremeses y el plato fuerte, cuando esta terminado el entremés, el mesero va a la cocina, los toma y los lleva a la mesa. </li></ul></ul><ul><ul><li>¿ Cómo se entera el mesero que ya están listos los entremeses ? R: El mesero va a la cocina de vez en cuando. El chef luego de dar el entremés al mesero, espera que este le avise cuando la mayoría de los comensales ya casi ha terminado con sus entremeses para poderle dar el toque final a cada plato fuerte. El mesero va a la cocina, y le avisa al chef que ya casi están listos para el plato fuerte, el chef termina su preparación. El mesero los toma y los lleva a la mesa </li></ul></ul>
  76. 76. Caso de Estudio (Restaurante) <ul><li>Preparación de platillos </li></ul>Recibir comanda Preparar entremeses Iniciar la preparación Del plato fuerte Coordinar la preparación de otros pedidos Llevar entremeses Ingerir entremeses Recibir la notificación de que los Entremeses casi se han consumido Finaliza la preparación de plato fuete Tomar el plato fuerte Llevar Plato fuerte
  77. 77. Caso de Estudio (Restaurante) <ul><li>Clases y asociaciones </li></ul><ul><ul><ul><li>El cliente se asocia con una gran cantidad de clases, como muestran las asociaciones a continuación: </li></ul></ul></ul>Cliente Postre Ingiere Cuenta Liquida Propina Deja Reservación Hace Mesero Es atendido por Sombrero Abrigo Da a guardar Encargado del Guardarropa Orden Hace Menú Elige del Alimento Ingiere Menú del postre Elige del 1 1 1 1 1 1 1 1 1..* 1 1 0..* 1 1 Da a guardar 1 0..* 1 1 1 1 1 1 1 1
  78. 78. Caso de Estudio (Restaurante) <ul><li>Detalle de las clases </li></ul><ul><ul><li>Cliente, sus atributos serían: </li></ul></ul>Cliente nombre horallegada orden horaservicio ingerir() beber() ordenar() pagar()
  79. 79. Caso de Estudio (Restaurante) <ul><li>Detalle de las clases </li></ul><ul><ul><li>Empleado es una clase abstracta que puede contener la información de los empleados y como clases secundarias, se pueden tener Mesero, Chef, Gerente, Asistente. </li></ul></ul>Empleado nombre domicilio RFC añosExperiencia fechaContratación salario Asistente trabajaCon preparar() cocinar() servirPan() servirAgua() Mesero llevar() servir() recoger( llamar() verificarEstado() DeLaOrden() Chef preparar() cocinar() darPrioridad() crearReceta() Gerente monitor() operaRestaurante() asignar() rotar()
  80. 80. Caso de Estudio (Restaurante) <ul><li>Diagrama de distribución, Restaurante </li></ul><ul><ul><li>Los meseros contarán con una computadora palmtop y la utilizarán para comunicarse con la cocina y con los mozos de piso. Estos últimos también tendrán palmtops para comunicarse. La cocina tendrá una terminal de escritorio y una o varias pantallas. El gerente tendrá una en su oficina. </li></ul></ul>« Dispositivo » Computadora palmtop « Dispositivo » Red Inalámbrico « Dispositivo » PC de la cocina « Dispositivo » PC del gerente
  81. 81. Caso de Estudio (Restaurante) <ul><li>Casos de uso </li></ul><ul><ul><li>El paquete mesero </li></ul></ul>Mesero Tomar una orden Cambiar una orden Transmitir la orden a la cocina Incluir Incluir Llamar a un Asistente Sondear el progreso De la orden Totalizar Una cuenta Transmitir una Orden al bar Notificar al chef del progreso de los clientes En sus alimentos Tomar una orden De bebida Llamar a un mozo de piso Recibir una notificación de la cocina Recibir una notificación del bar Imprimir una cuenta Obtener un acuse De recibo

×