RESUMEN CLASE 2. 1.

UML (Unified Modeling Language) :es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Actor: es un rol que un usuario juega con respecto al sistema Caso de uso: describe el comportamiento de cmo un sistema responde a las solicitudes de uno de los involucrados relevantes llamado actor primario. Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.

2. 3.

4.

Asociacin: Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple. Permite asociar objetos que colaboran entre s. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro

5.

Generalizacin: Herencia (Especializacin/Generalizacin): Indica que una clase (clase derivada) hereda los mtodos y atributos especificados por una clase (clase base), por lo cual una clase derivada adems de tener sus propios mtodos y atributos, podr acceder a las caractersticas y atributos visibles de su clase base (public y protected). En la siguiente figura podr observar un ejemplo de este tipo de relacin:

En este ejemplo se especifica que las clase Alumno y Profesor heredan de la clase Persona, es decir, Alumno y Profesor podrn acceder a las caractersticas de Persona. Tambin puede tener su respectiva diferenciacin, ya que un Alumno puede obtener sus notas previa evaluacin realizada por parte de un Profesor. 6. Composicin: La composicin es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye (el objeto base se construye a partir del objeto incluido, es decir, es parte/todo). En la siguiente figura podr observar un ejemplo de este tipo de relacin:

7.

Agregacin: La agregacin es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye (el objeto base utiliza al incluido para su funcionamiento). En la siguiente figura podr observar un ejemplo de este tipo de relacin:

EXTENSIONES un caso de uso incluye un conjunto de pasos que ocurren slo en algunas oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentacin sobre los nuevos productos disponibles, sus caractersticas y sus precios. En este caso, tengo una excepcin dentro del caso de uso Ingresar Pedido. La excepcin consiste en interrumpir el caso de uso y pasar a ejecutar el caso de uso Revisar Presentacin de Nuevos Productos. En este caso decimos que el caso de uso Revisar Presentacin de Nuevos Productos extiende el caso de uso Ingresar pedido y se representa por una lnea de trazos desde el caso que extiende a al caso que es extendido. Las extensiones tienen las siguientes caractersticas: 1) Representan una parte de la funcionalidad del caso que no siempre ocurre. 2) Son un caso de uso en s mismas. 3) No necesariamente provienen de un error o excepcin.

INCLUSIONES Indica que un caso de uso siempre llama la funcionalidad de otro caso de uso el cul se decidi separarlo debido a que su funcionalidad poda ser reutlizada. 1) Aparecen como funcionalidad comn, luego de haber especificado varios casos de uso. 2) Los casos usados son casos de uso en s mismos. 3) El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales.

Recomendaciones sobre casos de uso Define bien los lmites del sistema. Los actores interaccionan con el sistema. Pregunta qu quieren los actores del sistema: Distingue el flujo normal de los flujos alternativos. Lo importante es escribir la descripcin del caso de uso, no dibujar diagramas de casos de uso. Uso limitado de las relaciones include y extend No incluir casos de uso CRUD; casos de uso Crear y Consulta si son relevantes. Cada caso de uso debe tener por lo menos una relacin con un actor. No especificar casos de uso que incluyan detalles de diseo de interfaces de usuario.