Caso de Uso Veterinaria / Resuelto por Ruiz Agostina
Ejemplo: Ficha de descripción de requisitos
Ejemplo: Ficha de descripción de requisitos
Clase suspendida - Paro Nacional
Se transfiere la clase del día al 29 al 31/05/2019, Sala de Informática III.
Recursos
Descargar DOCx Hora 6 y 7.Actividades
Corrección entrevista II, próximo Viernes 31/05/19. Versión sin editar en https://drive.google.com/file/d/1m8QjNb5vK1D1JGHbTDeKj4jlQyxTxHBu/view?usp=sharing
Laboratorio Alquileres - Enunciado en Clase XI
Resumen de la clase
Utilidad de un Diagrama de Clase
El propósito de un diagrama de clase es describir las
clases que conforman el modelo de un determinado sistema. Se puede decir que
existen tres perspectivas diferentes desde las cuales se pueden utilizar los
diagramas de clase:
Relaciones entre clases
Dentro de las relaciones entre clases que existen se
pueden definir las siguientes:
Asociaciones
Las asociaciones representan las relaciones más generales
entre clases, es decir, las relaciones con menor contenido semántico. Para UML
una asociación va a describir un conjunto de vínculos entre las instancias de
las clases.
Las asociaciones pueden ser binarias (conectan dos
clases) o n-arias (conectan n clases), aunque lo más normal en un modelo es
utilizar sólo relaciones binarias (en general, y sin entrar en detalles, se
puede afirmar que una relación n-aria puede modelarse mediante un conjunto
finito de relaciones binarias).
La forma de representar las asociaciones binarias en UML
es mediante una línea que conecta las dos clases. En general, las asociaciones
son bidireccionales, esto es, no tienen un sentido asociado.
Ejemplo:
Si tenemos la clase perro y persona las siguientes
relaciones podrían darse:
La cual muestra que una persona es propietaria de uno o
varios perros pero estos son solo de esta persona.
Composición
La composición implica que los componentes de un objeto
sólo pueden pertenecer a un solo objeto agregado, de forma que cuando el objeto
agregado es destruido todas sus partes son destruidas también.
Ejemplo:
A una empresa la componen empleados.
Agregación
La agregación es una asociación con unas connotaciones
semánticas más definidas: la agregación es la relación parte-de, que presenta a
una entidad como un agregado de partes (en orientación a objeto, un objeto como
agregado de otros objetos).
Ejemplo:
Una empresa tiene clientes
Herencia
La herencia es la típica relación de
generalización/especialización entre clases. En UML la herencia se representa
mediante una flecha, cuya punta es un triángulo vacío. La flecha que representa
a la herencia va orientada desde la subclase a la superclase.
Cuando de una superclase se derivan varias subclases
existen dos notaciones diferentes, aunque totalmente equivalentes, para su
representación.
Herencia múltiple
UML permite implementar la herencia múltiple cuando una
clase hereda directamente de varias clases.
Ejemplo:
Un profesor emérito puede ser un profesor como también un
conferenciante
Conclusión
El diagrama de clases pertenece a la categoría de
diagramas de estructura de UML, este debe ser capaz de ofrecer los
mecanismos necesarios para capturar y modelar la abstracción de un sistema
desde diferentes puntos de vista ya que representa la definición estática del
sistema. Se puede presentar de diferentes maneras entre las cuales tenemos el
modelo conceptual donde se definen las características del
problema, especificación donde se definen las interfaces del diagrama
para simplificarlo e implementación donde se muestran tal y como
aparecen las clases en el entorno de programación.
Dentro de un diagrama de clases se pueden relacionar las
clases con una asociación que define un vínculo que puede darse entre ciertas
clases, composición donde las clases son fundamentales para la implementación
de otra clase, agregación donde se utilizan clases que no son esenciales para
su funcionamiento y la herencia que es la relación de generalización que se
utiliza para heredar características de una clase a otra.
Descargar ejercicio
En la guía de ejercicios se plantea el caso de estudio: Hospital.
El mismo será resuelto por OCAMPO, Felipe y su presentación oral se realizará el día Viernes 07/06/19.
El mismo será resuelto por OCAMPO, Felipe y su presentación oral se realizará el día Viernes 07/06/19.
Caso de Uso Veterinaria / Resuelto por Bonfietti Melina
Ejemplo: Ficha de descripción de requisitos
Nombre caso de uso
|
Ingresar datos de mascotas.
|
|
Actor
/es
|
Auxiliar de administración (A.A).
|
|
Propósito
|
Capturar y almacenar
datos de la mascota a tratar.
|
|
Visión
General
|
Permite dar de alta los datos de un nuevo paciente / mascota.
|
|
Pre
condiciones
|
Los datos del propietario de la
mascota deben estar cargados en la BD.
|
|
Post
condiciones
|
||
Incluye
|
Ingresar datos cliente previamente.
|
|
Extiende
|
||
Hereda
de
|
||
Curso
Típico de Eventos: Acción del Actor /
Respuesta del Sistema
|
||
1
|
En la primer consulta, el A.A solicita al cliente los datos de la mascota
a tratar para almacenarlos en la BD.
|
|
2
|
El A.A comprueba que el propietario de la mascota / cliente haya sido cargado anteriormente.
|
|
3
|
El A.A rellena la ficha “Mascota”.
|
|
4
|
El A.A almacena la ficha “Mascota” completa.
|
|
Cursos
alternativos
|
||
Línea
2
|
El A.A, comprueba que los datos del cliente no fueron almacenados previamente.
|
|
E.1 El A.A interrumpe el llenado de la ficha de la mascota.
E.2 Se cancela el caso de uso hasta completar los datos del propietario.
|
||
Diagramas de clases
Descargar DOCx Hora 5.
Descargar DiagramaClases.pptx
Un lenguaje de modelado debe ser capaz de ofrecer los mecanismos necesarios para capturar y modelar la abstracción de un sistema desde diferentes puntos de vista.
Estos puntos de vista deben dar lugar a diferentes diagramas que recojan tanto la definición estática del sistema, como la componente de comportamiento dinámico del mismo.
Para el modelado de la parte estática de un sistema, UML cuenta con los diagramas que representan abstracciones identificadas en forma de clases y objetos, mostrando su estructura interna, así como sus interrelaciones.
Existen dos tipos de diagramas de estructura: los diagramas de clase y los diagramas de objetos.
Los diagramas de clase describen los tipos de objetos de un sistema, así como los distintos tipos de relaciones que pueden existir entre ellos. Los diagramas de clase se convierten así en la técnica más potente para el modelado conceptual de un sistema software, la cual suele recoger los conceptos clave del modelo de objetos subyacente al método orientado a objetos que la incorpora, en este caso UML.
Por su parte, los diagramas estáticos de objetos representan una instantánea del estado del sistema en un momento dado, esto es, cada diagrama de objetos es una instancia del diagrama de clase, que representa uno de los infinitos escenarios a los que puede dar origen un diagrama de clase.
Utilidad de un diagrama de clase
El propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema.
Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema.
Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden utilizar los diagramas de clase:
• Conceptual: El diagrama de clase representa los conceptos en el dominio del problema que se está estudiando. Este modelo debe crearse con la mayor independencia posible de la implementación final del sistema.
• Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que un tipo representa una interfaz que puede tener muchas implementaciones diferentes.
• Implementación: Esta vista representa las clases tal cual aparecen en el entorno de implementación.
Descargar DOCx Hora 5.
Descargar DiagramaClases.pptx
Un lenguaje de modelado debe ser capaz de ofrecer los mecanismos necesarios para capturar y modelar la abstracción de un sistema desde diferentes puntos de vista.
Estos puntos de vista deben dar lugar a diferentes diagramas que recojan tanto la definición estática del sistema, como la componente de comportamiento dinámico del mismo.
Para el modelado de la parte estática de un sistema, UML cuenta con los diagramas que representan abstracciones identificadas en forma de clases y objetos, mostrando su estructura interna, así como sus interrelaciones.
Existen dos tipos de diagramas de estructura: los diagramas de clase y los diagramas de objetos.
Los diagramas de clase describen los tipos de objetos de un sistema, así como los distintos tipos de relaciones que pueden existir entre ellos. Los diagramas de clase se convierten así en la técnica más potente para el modelado conceptual de un sistema software, la cual suele recoger los conceptos clave del modelo de objetos subyacente al método orientado a objetos que la incorpora, en este caso UML.
Por su parte, los diagramas estáticos de objetos representan una instantánea del estado del sistema en un momento dado, esto es, cada diagrama de objetos es una instancia del diagrama de clase, que representa uno de los infinitos escenarios a los que puede dar origen un diagrama de clase.
Utilidad de un diagrama de clase
El propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema.
Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema.
Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden utilizar los diagramas de clase:
• Conceptual: El diagrama de clase representa los conceptos en el dominio del problema que se está estudiando. Este modelo debe crearse con la mayor independencia posible de la implementación final del sistema.
• Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que un tipo representa una interfaz que puede tener muchas implementaciones diferentes.
• Implementación: Esta vista representa las clases tal cual aparecen en el entorno de implementación.
Laboratorio
La empresa inmobiliaria XX, cuenta con clientes, propietarios de locales y viviendas (casas, dptos, chalets, de uno, dos,tres o + ambientes), que ceden sus propiedades en alquiler.
Los propietarios que desean poner en alquiler alguna propiedad se acercan a la empresa y dejan sus datos de contacto y los de la propiedad a alquilar (ubicación, costo del alquiler, tiempo mínimo, fotos, cantidad de ambientes, etc.). Cada propietario puede tner varias propiedades consignadas en alquiler.
El auxiliar administrativo de la empresa genera registros de esa información y los almacena en la BD, previa verificación de su inexistencia.
El propietario puede retirar su propiedad de la lista de la empresa si no desea ofrecer en alquiler su propiedad. También puede negarse a alquilar su propiedad a una persona, si así lo desea.
Los interesados en alquilar, pueden consultar a la empresa personalmente o vía web en los archivos clasificados del Diario Nuevo Día.
Si un acuerdo de alquiler se lleva a cabo, se firma un contrato entre las partes con supervisión del auxiliar contable de la empresa y se generan los registros de altas pertinentes (alta propietario, alta inquilino, alta inmueble si no existieren).
El locatario puede rescindir el contrato a los 6 meses, previo aviso.
Finalizado el contrato el inquilino puede renovar el contrato.
Diagramar el DCU, fichas CU y DC para el texto enunciado.
Se transfiere la clase del día al 17 al 22/05/2019, Sala de Informática 3.
Caso de estudio: Ventas
b)
Explicar
…
. . . por
qué se eliminó color, tamaño y marca de la tabla Productos? ¿Dónde se
almacenarán dichos datos?
. . .
por qué se eliminaron los datos edad y sexo de la tabla de Clientes?
. . .
concepto y nombre del cliente de la tabla Facturas?
Modelo final
Casos de uso
Casos de uso
Clases
Resumen CU
Diagrama de casos de uso
El diagrama de casos de uso es uno de los diagramas
incluidos en UML 2.5, estando este clasificado dentro del grupo
de diagramas de comportamiento. Es, con total seguridad, el diagrama más
conocido y es utilizado para representar los actores externos que interactúan
con el sistema de información y a través de que funcionalidades (casos de uso o
requisitos funcionales) se relacionan.
Dicho de otra manera, muestra de manera visual las
distintas funciones que puede realizar un usuario (más bien un tipo de usuario)
de un Sistema de Información.
El diagrama de casos de uso, dependiendo de la
profundidad que le demos, puede ser utilizado para muchos fines, entre ellos
podemos encontrar los siguientes:
- Representar los requisitos funcionales.
- Representar los actores que se comunican con el sistema. Normalmente los actores del sistema son los usuarios y otros sistemas externos que se relacionan con el sistema. En el caso de los usuarios hay que entender el actor como un “perfil / rol”, pudiendo existir varios usuarios que actúan como el mismo actor.
- Representar las relaciones entre requisitos funcionales y actores.Guiar el desarrollo del sistema. Crear un punto de partida sobre el que empezar a desarrollar el sistema.
- Comunicarse de forma precisa entre cliente y desarrollador. Simplifica la forma en que todos los participantes del desarrollo, incluyendo el cliente, perciben como el sistema funcionará y ofrecerá una visión general común del mismo.
Elementos de un
diagrama de casos de uso
Un diagrama de casos de uso está compuesto,
principalmente, de 3 elementos: Actores, Casos de uso y Relaciones.
Actores
Un actor es algo o alguien externo al sistema que
interactúa de forma directa con el sistema. Cuando decimos que interactúa nos
referimos a que aporta información, recibe información, inicia una acción, etc.
.
Se representan con una imagen de un “muñeco de palo” con
el nombre del actor debajo.
Representación de un actor
Existen dos tipos de actores: Los usuarios y los
sistemas.
No hay que entender los usuarios como personas
singulares, sino como “perfiles o roles” que identifican a un tipo de usuario,
pero no al usuario en sí. Por ejemplo, en una aplicación de gestión de nóminas,
un actor de este tipo podría ser “gestor de nóminas” que se encarga de emitir y
firmar nóminas. Este rol podría ser tomado, por ejemplo, por cualquier
individuo del personal de recursos humanos y, además, por el jefe de la
empresa. Es un ejemplo sencillo, en donde un actor no representa a una única
persona o a un único usuario.
Ejemplo de actor
Por otro lado, los actores pueden ser otros sistemas que
también interactúan con nuestro propio sistema. Un ejemplo podría ser, en
nuestra aplicación de nóminas, un sistema que almacene las nóminas firmadas a
modo de archivo. En este caso cuando se firma la nómina se recibe la misma por
el sistema de archivo, por tanto el caso de uso se relaciona con el actor.
En ocasiones este tipo de actores no se representa con un “hombre de palo” porque puede dar la sensación de que es un usuario y queda poco intuitivo. Se utiliza un rectángulo rotulado.
Casos de uso
Un caso de uso se utiliza para representar una de las
funcionalidades que realiza el sistema. Es una secuencia de acciones que hace
el sistema y que producen un resultado que puede percibir un usuario.
Formalmente hablando, un caso de uso es una clasificación
de comportamiento que especifica una unidad de funcionalidad completa y que
está realizada por uno o más sujetos que se relacionan con el caso de uso
colaborando para ello con uno o más actores y que produce un resultado que
tiene alguna utilidad para cualquier de esos actores.
Se representan con una elipse que incluye en su interior
el nombre del caso de uso.
Representación de un caso de uso
Ejemplos de casos de uso: Crear pedido, Listar productos,
Enviar correo. Cualquier acción que realice la aplicación.
Las especificaciones anteriores a UML 2.5 requerian que
un caso de uso sea invocado por un actor. En UML 2.5 esto se eliminó, lo que
significa que podría haber algunas situaciones en las que la funcionalidad del
sistema la inicie el propio sistema y, al mismo tiempo, brinde resultados
útiles a un actor. Por ejemplo, el sistema podría notificar a un cliente que se
envió la orden, programar la limpieza y el archivo de la información del
usuario, solicitar información de otro sistema, etc.
Relaciones
Las relaciones conectan los casos de uso con
los actores o los casos de uso entre sí.
Cuando conectan un actor con un caso de uso representa
que ese actor interactúa de alguna manera con ese caso de uso y se
representa con una linea continua con la
identificación <<communicates>>.
Cuando conectan casos de uso entre sí se pueden
diferenciar dos tipos de relaciones: <<include>> y
<<extends>>.
En español a veces se usa la nomenclatura
<<usa>> y <<extiende>>:
<<include>>: Se utiliza para representar
que un caso de uso utiliza siempre a otro caso de uso. Es decir, un
caso de uso se ejecutará obligatoriamente (lo incluye, lo usa). Se representa
con una flecha discontinua que va desde el caso de uso de origen al caso de uso
que se incluye.
Relación
include entre dos casos de uso
Un uso típico de este tipo de relaciones se produce cuando dos casos de uso comparten una funcionalidad. Esa funcionalidad es extraída de los dos y se crea un caso de uso nuevo que se relaciona con los anteriores con un include.
Ejemplo de uso de include
En este ejemplo, los casos de uso emitir factura y enviar producto ejecutarán ambos el caso de uso autenticación.
<<extend>>: Este tipo de relaciones se
utilizan cuando un caso de uso tiene un comportamiento opcional, reflejado
en otro caso de uso. Es decir, un caso de uso puede ejecutar, normalmente
dependiendo de alguna condición o flujo del programa, otro caso de uso. Se
representa con una flecha discontinua que va desde el caso de uso opcional al
original.
Relación extend entre dos casos de uso
Un ejemplo de esta relación podría ser la siguiente:
Ejemplo de relaciones extend
En este supuesto el caso de uso Hacer pedido puede dar lugar
(o no) a otros dos casos de uso: Enviar notificación SMS y Enviar notificación
email. Se supone que, cuando un usuario hace un pedido, el sistema le permite
elegir si quiere que se envíe una notificación de ese pedido por SMS o por
email.
Existe, además, otra relación
denominada generalización que consiste en hacer que un elemento
herede el comportamiento de otro. Aunque se puede utilizar entre casos de uso,
es más común utilizarlo entre actores, haciendo que uno de los actores tenga
acceso a las funcionalidades de otro. Se representa con una flecha con la punta
hueca que va desde el elemento que hereda al elemento heredado:
Generalización entre dos actores
Descripción de requisitos funcionales y no funcionales
Es común en este tipo de diagramas describir cada caso de
uso junto con la secuencia de pasos necesaria para completarlo y las posibles
excepciones hasta definir todas las situaciones posibles. Esta descripción
servirá de guía para el desarrollo, la profundidad de las situaciones que se traten
dependerá de cada fase del proyecto o de cada situación en particular.
Existen dos tipos de requisitos:
- Requisitos funcionales
- Requisitos no funcionales
Los requisitos suelen ser plasmados junto a la siguiente
información:
Identificador y nombre descriptivo: Se utiliza una
identificación única para diferenciarlo de los demás y un nombre descriptivo
que suele coincidir con el objetivo que los actores esperan alcanzar al
realizar el caso de uso.
Versión
Autores
Objetivos asociados
Requisitos asociados
Descripción: Este campo debe completarse de forma
distinta en función de si el caso de uso es abstracto o concreto.
Precondición: se expresan en lenguaje natural las
condiciones necesarias para que se pueda realizar el caso de uso.
Secuencia normal: secuencia normal de interacciones
del caso de uso. En cada paso, un actor o el sistema realiza una o más
acciones, o se realiza otro caso de uso.
Postcondición: se expresan en lenguaje natural las
condiciones que se deben cumplir después de la terminación normal del caso de
uso.
Excepciones: especifica el comportamiento del
sistema en el caso de que se produzca alguna situación excepcional durante la
realización de un paso determinado, lo que modifica el flujo “normal” del caso
de uso.
Ejemplos de representación de un requisito en forma de
tabla:
Modelado de un requisito funcional
Modelado de un requisito no funcional
Cómo dibujar un diagrama de casos de uso
A la hora de dibujar un diagrama de casos de uso es
conveniente que se compruebe que se ha realizado previamente todos estas
tareas, respondiendo a las preguntas detalladas a continuación:
- Recopilar fuentes de información: ¿cómo se supone que debo saber eso?
- Identificar actores potenciales: ¿qué usuarios utilizan los bienes y servicios del sistema empresarial?.
- Identificar posibles casos de uso: ¿a qué bienes y servicios pueden recurrir los actores?
- Conectar los casos de uso: ¿quién puede hacer uso de los bienes y servicios del sistema empresarial?
- Describir actores: ¿a quién o qué representan los actores?
- Buscar más casos de uso: ¿Qué más debe hacer el sistema?
- Documentar casos de uso: ¿qué sucede exactamente en cada caso de uso?
- Relacionar modelos entre casos de uso empresarial: ¿qué actividades se realizan repetidamente?
- Verificar la vista, ¿todo es correcto?
Los pasos se han escrito en este orden a propósito, ya
que es la forma lógica de seguirlos. Sin embargo, este orden no es obligatorio,
ya que en la práctica, los pasos individuales a menudo se superponen unos con
otros.
Para poder seguir los pasos de una forma óptima, es
importante comprender el negocio/sistema para conseguir seguir cada paso individual.
Descargar ejercicios
En la guía de ejercicios se plantean tres casos de estudio: Veterinaria, Ventas y Almacén.
El caso de estudio Veterinaria será resuelto por BONFIETTI, Melina y su presentación oral se realizará el día 22/05/19.
El caso de estudio Ventas se resolverá en clase el día 15/05/19.
El caso de estudio Almacén será resuelto por RUIZ, Agostina y su presentación oral se realizará el día 29/05/19.