Introducción a UML Diagrama de Clase y Uso

Presentación del tema: "Introducción a UML Diagrama de Clase y Uso"— Transcripción de la presentación:

1 Introducción a UML Diagrama de Clase y Uso
Republica Bolivariana de Venezuela Universidad Central de Venezuela Caracas – Venezuela Introducción a UML Diagrama de Clase y Uso Conceptos Básicos de Sistemas Franklin Sandoval

2 Estructuras de Objetos
Diagramas UML La relación existente entre los diversos diagramas de UML se muestra a continuación: Casos de Uso Diagrama de Secuencias Colaboración Clases Estados Actividad Distribución Componentes CODIGO

3 Procesos donde utilizar UML.
Los procesos iterativos deberán tener un plan de que serán las iteraciones y que será cubierto por cada una de ellas. En la fase de construcción: 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. 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. La construcción termina con una versión beta del sistema. Transición es el proceso de introducir el sistema a sus usuarios. Otros procesos han adoptado UML como su lenguaje de modelación: Catalysis, Rational Unified Process, etc.

4 Casos de Uso 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. 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. 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. Cuando se tienen varios subsistemas es común dibujar la frontera del sistema, pero generalmente se omite. Sist. de Información de Biblioteca Recursos para Prestamo Usuario Bibliotecario Agregar recursos Regresar Recursos

5 Casos de Uso (cont.) Interacciones con sistemas externos:
Las opiniones de incluir a los sistemas externos como casos de uso o no, varían: 1.- Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama. Si requiere acceso a Reuters se debería indicar. 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. 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. 4.- Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor.

6 Casos de Uso (cont.) Un actor en un caso de uso representa un rol que alguien debe jugar, en vez de representar a alguien en individual. 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. 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. Actores no humanos, como otros a sistemas o en algunos casos se pueden identificar diferentes dispositivos externos al sistema.

7 Casos de Uso (cont.) Utilización de los casos de uso.
Los casos de uso sirven a capturar los requerimientos al proporcionar una forma estructurada de: Identificar a los actores 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. Casos de uso a través del desarrollo. 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: Una buena idea de lo que significa cada uno Entender quién quiere cada uno y qué tanto lo desea. Conocer cuál caso de uso acarrea más riesgo Un plan de que tanto tomará implementar cada caso de uso. 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. 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. 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.

8 Casos de Uso (cont.) Posibles problemas con los casos de uso.
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. 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. 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.

9 Relaciones entre casos de uso.
Casos de Uso (cont.) Relaciones entre casos de uso. La inclusión permite volver a utilizar los pasos de un caso de uso dentro de otro Al reusar los casos de uso se tienen las siguientes ventajas: Buena forma de registrar la conveniencia de se usara un componente o evitar duplicidades. Al hacer en forma externa partes del caso de uso puede hacerlo más corto y fácil de entender 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. Sin embargo se tienen las siguientes desventajas: Peligro de buscar funcionalidad y al hallarla fomentar la elaboración de un sistema basado en funciones, top-down con sistemas inflexibles. Es difícil para alguien no adiestrado en UML entender la notación de «incluir» Recolectar dinero Exhibir el interior Cubrir el interior «incluir»

10 Punto de extensión llenar
Casos de Uso (cont.) Relaciones entre casos de uso.(cont.) 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. Generalización. Un caso de uso secundario hereda las acciones y significado del primario y además agrega sus propias acciones. Reabastecer Punto de extensión llenar los compartimientos Exhibir el interior Cubrir el interior «incluir» Reabastecer de Acuerdo a las ventas «extender» (llenar los Compartimientos) Comprar gaseosa Comprar un vaso de gaseosa

11 Casos de Uso (cont.) Relaciones entre casos de uso.(cont.)
Las reglas para aplicar «incluir» o «extender» son: Utilice extender cuando describa una variación de conducta normal. Emplee incluir para repetir cuando se trate de uno o varios casos de uso y desee evitar repeticiones 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. Cuando emplear los casos de uso 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. El modelado conceptual junto con los usuarios ayuda a descubrir los casos de uso. 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.

12 ¿Qué es un objeto? 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. El estado de un objeto se representa mediante los datos almacenados en el mismo, los cuales son llamados atributos. 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. Representación UML de un objeto (Diagrama de Clase): Empleado - Nombre:String - Sexo:Boolean - Direccion:String - RFC:String + TomarNombre:String + TomarRFC:String + TomarDireccion:String

13 Problemas con la definición de objetos
Se pueden crear objetos degenerados como: Un objeto sin datos. Que sería lo mismo que una biblioteca de funciones. 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). Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos. “Las aplicaciones de gestión están constituidas mayoritariamente por objetos degenerados”

14 Clases Atributos Métodos Mensajes Interfases
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. Atributos 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) Métodos 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. Mensajes 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. Interfases 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.

15 Herencia 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. Las clases Perro y Gato heredan de la clase Mamíferos, esto significa que la clase Perro tiene los siguientes atributos: colorOjos Heredada de la clase Mamíferos frecuenciaLadrido Definida solo para la clase Perro y los siguientes métodos: tomarColorOjos Heredada de la clase Mamíferos Ladrar Definida solo para la clase Perro Superclase Subclases Mamíferos - colorOjos: int + TomarColorOjos: int Perro -frecuenciaLadrido: int + Ladrar: int gato -frecuenciaMaullido:int + Maullar: int

16 Abstracción Polimorfismo Encapsulamiento Asociaciones Composiciones
Quitar las propiedades y acciones de un objeto para dejar sólo aquellas que sean necesarias. Polimorfismo 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. 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. Encapsulamiento Se oculta la funcionalidad de los objetos, evitando que otros objetos o el mundo exterior puedan ver sus operaciones internas. Asociaciones Un objeto puede estar relacionado con uno o más objetos Composiciones La agregación de objetos permite definir composiciones, en las que cada componente se considera como tal sólo como parte del objeto compuesto.

17 Diagramas 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. 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. Los modelos de diagramas a considerar son: El modelo de casos de uso que describe el sistema requerido desde el punto de vista de los usuarios. El modelo estático que describe los elementos de el sistema y sus relaciones. El modelo dinámico que describe el comportamiento del sistema a través del tiempo. podremos tomar una: Vista lógica nos permitirá alcanzar los requerimientos funcionales. Cuáles partes van juntas? Cuáles son las clases y sus relaciones? 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? Vista de desarrollo ayuda a administrar el proyecto. Cuál parte hará cada elemento del equipo de gente? Que partes pueden reusarse? 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?

18 Objetos y Clases Identificar las clases que deben existir en nuestro sistema, es la parte mas grande del trabajo de diseñar sistemas orientados a objetos. Construir rápidamente y lo más barato posible el sistema que alcance nuestros requerimientos. Construir un sistema que sea fácil de mantener y adaptar para los requerimientos futuros. Cada pieza de comportamiento requerida por el sistema deberá ser proporcionada de una manera sensible, por los objetos de las clases que elijamos. Un buen modelo de clases consiste de clases de los objetos principales, los cuales no dependen de la funcionalidad particular requerida actualmente 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 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.

19 Objetos y Clases (cont.)
Diagramas de clases 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: ejemplo: 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 (#) 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. Las propiedades se indican mediante llaves, dando propiedades a los elementos donde se haya n incluido estas. 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 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

20 Objetos y Clases (cont.)
Diagramas de clases (cont.) 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. 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. 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. Un objeto se especifica con una firma o con precondición, post-condición algoritmo y el efecto que tiene sobre un objeto. La precondición debe ser cierta antes de que la operación pueda ejecutarse. La post-condición debe ser cierta después de que la operación sea ejecutada. Estas especificaciones son como propiedades para una operación. Las propiedades usualmente no se muestran directamente en los diagramas de clases. 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. 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.

21 Relaciones entre clases.
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. Corresponden a los verbos. Existen instancias de asociación. 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. Asociación normal: Las restricciones en las asociaciones, permiten que se siga cierta regla: 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}

22 Diagramas Estáticos Relaciones entre clases (cont.)
Hay asociaciones que establecen una relación en ambas direcciones La multiplicidad es la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada: La asociación recursiva es una asociación de una clase a sí misma, una conexión entre objetos de la misma clase 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

23 Diagramas Estáticos Relaciones entre clases (cont.)
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. Contrato de Seguros Compañía Aseguradora tiene Asegurador Refiere a 1 0..* Póliza de 0..1 Está expresado en un 1..* Persona Asegurado casado con esposo esposa

24 Diagramas Estáticos Tipos de asociaciones
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. Asociación Or {or}. En algunos modelos no todas las combinaciones de asociación son válidas Asociación Ordenada {ordered}. Cuando los enlaces entre objetos pueden tener un orden implícito {ordered} {ordenadas por incremento de tiempo}. Cuadro Tablero 1 renglón:{1,2,3} columna:{1,2,3} Académico Estudiante de Educación Media Superior Elige Comercial {Or}

25 Tipos de asociaciones 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. Asociación ternaria (Ternary association). Más de dos clases pueden asociarse con otra, la asociación ternaria asocia tres clases. Equipo Jugador Participa en Contrato Director General Negociado por Contrato de Seguros Compañía Aseguradora Asegurador 1 0..* 1..* Persona Asegurado Póliza de 0..1

26 Diagramas Estáticos Tipos de asociaciones (cont.)
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. Se puede tener una restricción en una agregación, como en la relación {O} que se indica con línea punteada Una composición es una agregación donde cada componente puede pertenecer tan solo a un todo. Se representa con diamante sólido. Comida 1 Ensalada PlatoFuerte Postre {O} Tablero 1 Cuadros 9

27 Tipos de asociaciones (cont.)
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). 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. Vehículo Carro Bote Camión

28 Interfaces y realizaciones
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: Adicionalmente la interfaz puede ser representada como un circulo conectado con una línea a la clase Teclado marca cantidadDeteclas Ctrl() Alt() RePag() AvPag() ... «interfaz» MaquinaDeEscribir Teclazo() Teclado MaquinaDeEscribir

29 Diagrama de objetos 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. Clases: Usa 0..* 1..* Autor nombre: String edad: Integer Computadora memoria: Integer Juan: Autor nombre= “Juan P.” edad = 33 Bob1:Computadora nombre=“IBM 128” Memoria=128 Objetos:

30 Diagrama de Clases Modelo Conceptual de Punto de Venta VentasLinea
deProducto cantidad Venta Fecha Hora Pago Monto Cliente TPDV Tienda Dirección Nombre Catalogo Especificacion Descripcion Precio Codigode barras Producto Gerente Cajero Pagado-por Iniciado-por Contenidas-en Capturadas-en Capturas terminadas Registra-ventas-en Almacena Usado-por Contiene Describe Descritas-por Registra-venta-de 0..1 1 1..* *

31 Diagramas de estados 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. Los símbolos UML en un diagrama de estados son: 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) Nombre Variables de estado Actividades Inicio Transición Evento que dispara Estado Fin

32 Diagramas de estados (cont.)
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. Las condiciones de seguridad permiten establecer una relación entre estados que dependen de que se cumpla dicha condición. 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

33 Diagramas de actividades
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. Elementos de un diagrama de actividades: La actividad se muestra como una caja con nombre con las esquinas muy redondeadas, representa cuando la actividad ha terminado La transición se muestra como una flecha, normalmente no se les pone etiqueta, a menos que se tenga una condición. Actividad Actividad 1 Actividad 2

34 Diagramas de actividades (cont.)
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. Fin de la jornada Baño Descanso

35 Diagramas de actividades (cont.)
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. Televisión Remoto.Tecleo (canal) Oprimir numero de canal Fin de la jornada Cambiar(canal) Cambiar(canal) Oprimir numero de canal

36 Diagrama de secuencias.
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. 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) :Objeto 1 :Objeto 2

37 Diagrama de secuencias. (cont.)
Para ilustrar los diagramas de secuencia se usará el siguiente caso de uso: La ventana Entrada de pedido envía un mensaje “prepara” a Pedido. El Pedido envía entonces un mensaje “prepara” a cada línea de pedido dentro del Pedido. Cada Línea de pedido revisa el Artículo de inventario correspondiente. - Si esta revisión devuelve “verdadero”, la Línea de pedido descuenta la cantidad apropiada de Artículo de inventario del almacén. 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. 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.

38 Diagrama de secuencias. (cont.) El siguiente ejemplo muestra
Ventana de Entrada de Pedidos unPedido prepara() Una Línea de Pedido Un artículo de inventario *[para cada línea de pedido] hayExistencia:= revisa() [hayExistencia] descuenta() necesitaReorden:= necesitareordenar() Un Artículo de reorden [necesitaReorden] nuevo para entrega nuevo() Objeto Iteración Mensaje Condición Autodelegación Creación Regreso

39 Diagramas de secuencias. (cont.)
Cuando utilizar los diagramas de secuencias, se sugieren para: 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. Cuando se desee ver el comportamiento de varios objetos en un caso de uso y la secuencia de los mensajes. No se sugieren para: 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 No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados) Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad.

40 Diagramas de componentes
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: 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: Código fuente, el cual depende de que otros componentes estén disponibles al momento de compilación. Código objeto binario, (biblioteca de clases) que depende de cualquier código objeto al cuál se ligara desde un programa ejecutable. Una aplicación ejecutable, la cuál puede depender de otros programas ejecutables al tiempo de ejecución. 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» calculadora.java

41 Diagramas de Implementación
Diagramas de componentes (cont.) Cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo. La especificación contiene la interfaz de la clase mientras que el cuerpo contiene la realización de la clase. En el caso de clases parametrizables se puede dar una especificación genérica. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro. 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.

42 Diagramas de componentes (cont.)
Un diagrama de componentes mostrando las dependencias de tiempo de compilación: La interfaz se puede representar por una línea con un círculo streams.o «biblioteca» MiEntradaSalida MiAplicación «ejecutable» «compilar» «ligar» Programa de búsqueda Resultado de la búsqueda

43 Administración CS4 Presentación del caso.
Un estudiante CS4, 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. 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. 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) 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 LATEX. 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 LATEX. 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. 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. 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. 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.

44 Administración CS4 (cont.)
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. 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. 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. Cada estudiante se inscribe para un curso de grado y recibe el manual de curso apropiado. 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) Se pide desarrollar un sistema que permita: Disminuir la cantidad de trabajo rutinario para todo el staff, especialmente el CCS4. Permitir a los estudiantes inscribirse en los módulos en línea. Que el OEP pueda obtener fácilmente información actualizada y confiable. Mejorar el seguimiento de dicha información. 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. 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. 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.

45 Diagrama de casos de uso (CS4)
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: Producir el manual del curso Producir la lista CS4 Inscribir en los módulos. 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

46 Diagrama de casos de uso (CS4)
Descripción de caso de uso: Producir el manual del curso 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. 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. El adjunto de cada módulo, actualiza la descripción del módulo tomándolo del sistema, actualizándolo y regresándolo al sistema. 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. Desarrolle las descripciones de los casos de uso para: Producir la lista CS4 Inscribir en los módulos.

47 Diagrama de clases (CS4)
Un diagrama de clases a nivel conceptual, sin incluir actividades y operaciones: Adjunto Módulo Cursos Grado Estudiante 4to año otros años Director de Estudios 1 0..* 6..* 1..* 6 Imparte toma dirige esta en

48 Diagrama de actividad (CS4)
El siguiente diagrama muestra el flujo de trabajo requerido para determinar qué cursos hay, quien los imparte, generar los manuales de los cursos: 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

49 Caso de Estudio (Restaurante)
Presentación del caso. 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. Entrevista de Análisis ¿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. ¿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. [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]

50 Presentación del caso. (cont.)
Entrevista de Análisis (cont.) ¿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. ¿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á. ¿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. ¿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. ¿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.

51 Caso de Estudio (Restaurante)
[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 Diagrama: “Servir a un cliente”

52 Caso de Estudio (Restaurante)
Clases y asociaciones El cliente se asocia con una gran cantidad de clases, como muestran las asociaciones a continuación: Postre Cuenta Propina Reservación 1 1 1 Ingiere Liquida 1 Deja 1 1 1 Hace Cliente 1 1..* Es atendido por 1 1 Mesero Sombrero Da a guardar 1 0..* 1 1 1 1 1 Da a guardar Encargado del Guardarropa 1 Elige del 0..* Abrigo Ingiere Hace 1 1 Elige del 1 1 Orden Menú Alimento Menú del postre

53 Caso de Estudio (Restaurante)
Detalle de las clases Cliente, sus atributos serían: Cliente nombre horallegada orden horaservicio ingerir() beber() ordenar() pagar()

54 Caso de Estudio (Restaurante)
Detalle de las clases 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. Empleado nombre domicilio RFC añosExperiencia fechaContratación salario Asistente trabajaCon preparar() cocinar() servirPan() servirAgua() Mesero llevar() servir() recoger( llamar() verificarEstado() DeLaOrden() Chef darPrioridad() crearReceta() Gerente monitor() operaRestaurante() asignar() rotar()

55 Caso de Estudio (Restaurante)
Casos de uso El paquete mesero Mesero Tomar una orden Cambiar Transmitir la orden a la cocina 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 del bar Imprimir una cuenta Obtener un acuse De recibo