Caso de Uso Venta de recursos digitales / Sitio de descargas / Resuelto por Nicolás Callejas Boreto
Caso de Uso Alquiler de vehículos / Resuelto por Emanuel Soldo
Ejemplo: Ficha de descripción de requisitos
Nombre del caso de uso
|
Crear usuario
|
Actor/es
|
Usuario no registrado
|
Visión
general
|
Habilitar al usuario para poder realizar reservas.
|
Pre
condiciones
|
Ingresar a la pagina
|
Post condiciones
|
|
Incluye
|
Ingresar usuario y contraseña
|
Extiende
|
|
Hereda de
|
|
CursoTípico
de Eventos: Acción del Actor / Respuesta del Sistema
|
|
1
|
El usuario ingresa a la página web
|
2
|
El usuario se registra con sus datos personales y un nombre que no
esté siendo usado por otro
|
3
|
El caso de uso finaliza cuando el sistema almacena los datos del
usuario registrado.
|
Cursos alternativos
|
|
Línea
1
|
La página web se encuentre en mantenimiento.
|
Linea 2
|
El nombre de
usuario ya esté siendo usado por otra persona, el sistema emite una alerta al
usuario para que se registre con otro nombre.
|
Nombre del caso de uso
|
Devolver el vehículo
|
Actor/es
|
Usuario registrado
|
Visión
general
|
Devolución del vehículo alquilado
|
Pre
condiciones
|
Alquilar un vehículo y haber convenido fecha horario y lugar de
devolución.
|
Post condiciones
|
El vehículo debe ser devuelto a la empresa con el tanque lleno y en el mismo estado en que se retiró.
|
Incluye
|
|
Extiende
|
|
Hereda de
|
|
CursoTípico
de Eventos: Acción del Actor / Respuesta del Sistema
|
|
1
|
El usuario se acerca en la fecha lugar y hora convenidas para la
devolución del vehículo.
|
2
|
El personal de la empresa revisa el vehículo y acepta la devolución.
|
3
|
El caso de uso finaliza con la aceptación del vehículo.
|
Cursos alternativos
|
|
Línea
2
|
El personal constata de que el vehículo no se encuentra en las
condiciones acordadas para su devolución.
|
Asignación de trabajos prácticos
Descargar ejercicio
En la guía de ejercicios se plantea el caso de estudio: Hotel
El mismo será resuelto por OCAMPO, Felipe y su presentación oral se realizará el día Miércoles 12/06/19.
El mismo será resuelto por OCAMPO, Felipe y su presentación oral se realizará el día Miércoles 12/06/19.
Descargar ejercicio
En la guía de ejercicios se plantea el caso de estudio: Venta de recursos digitales / Sitio de descargas
El mismo será resuelto por CALLEJAS BORETTO, Nicolás y su presentación oral se realizará el día Viernes 14/06/19.
El mismo será resuelto por CALLEJAS BORETTO, Nicolás y su presentación oral se realizará el día Viernes 14/06/19.
Descargar ejercicio
En la guía de ejercicios se plantea el caso de estudio: Juegos en red
El mismo será resuelto por SOTTI, Santiago y su presentación oral se realizará el día Miércoles 19/06/19.
El mismo será resuelto por SOTTI, Santiago y su presentación oral se realizará el día Miércoles 19/06/19.
Descargar ejercicio
En la guía de ejercicios se plantea el caso de estudio: Alquiler de vehículos
El mismo será resuelto por SOLDO, Emanuel y su presentación oral se realizará el día Miércoles 21/06/19.
El mismo será resuelto por SOLDO, Emanuel y su presentación oral se realizará el día Miércoles 21/06/19.
Parcial 05/07/19
Presentar TP impreso - Normas APA
Partes
Presentar TP impreso - Normas APA
Partes
- Carátura
- Contenido
- Bibliografía
- Descripción del contexto del caso de estudio
- DCU
- Fichas descriptivas
- DC
Interfaces
Una clase abstracta es una clase de la cual no se pueden definir instancias (u objetos). Por ejemplo:
Una clase abstracta, al no poder ser instanciada, no tiene sentido hasta que una serie de clases la implementan completamente y le dan un significado a todos sus métodos.
Llamaremos concretas a las clases que se pueden instanciar, a las cuales se les puede definir atributos y métodos, para diferenciarlas de las clases abstractas.
A las clases abstractas puras, es decir, a las clases que no contienen ninguna implementación, se les llama interfaces.
Cuando deseemos contar con algún medio para capturar todas las operaciones reutilizables del modelo, debemos usar una interfaz.
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.
La interfaz puede establecer un subconjunto de las operaciones de una clase y no necesariamente todas ellas. Podemos modelar la interfaz igual que una clase, con un símbolo rectangular. La diferencia es que la interfaz no tiene atributos.
Las maneras de distinguir una interfaz de una clase que no muestra sus atributos son usando un estereotipo y especificando la palabra << interfaz >> en el rectángulo, o colocar la letra “I” al principio del nombre de una interfaz.
Gráficamente una interfaz se puede representar de forma expandida como una clase estereotipada con la etiqueta <> o, en su forma abreviada, con una figura en forma de piruleta.
La relación entre una clase y una interfaz se conoce como realización. Esta relación se representa con una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que adjunte y apunte a la interfaz.
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces.
En UML una interfaz es una colección de operaciones que sirven para especificar los servicios de una clase o un componente.
Una
interfaz sólo contiene las cabeceras de las operaciones, no su implementación.
Dependencias
Hay dos relaciones que pueden
existir entre una clase y una interfaz: la dependencia y la realización.
La dependencia
entre una clase y una interfaz tiene el mismo significado y representación que entre dos
clases, indica que la clase usa la interfaz.
Para que una interfaz se pueda usar hace falta
que otra clase implemente las operaciones que la interfaz especifica.
A esta relación
entre la interfaz y la clase que la implementa se le llama realización.
La realización
indica que la clase implementa todas las operaciones de la interfaz.
Gráficamente la
realización se representa como una generalización con la línea discontinua.
Estereotipos
Si la lista de atributos y métodos es larga, se pueden usar estereotipos para organizarla de
de manera que sea más comprensible:
Diferencia
entre Clase Abstracta e Interfaz
Resumen de asociaciones
Una clase abstracta es una clase de la cual no se pueden definir instancias (u objetos). Por ejemplo:
Una clase abstracta, al no poder ser instanciada, no tiene sentido hasta que una serie de clases la implementan completamente y le dan un significado a todos sus métodos.
Llamaremos concretas a las clases que se pueden instanciar, a las cuales se les puede definir atributos y métodos, para diferenciarlas de las clases abstractas.
A las clases abstractas puras, es decir, a las clases que no contienen ninguna implementación, se les llama interfaces.
Cuando deseemos contar con algún medio para capturar todas las operaciones reutilizables del modelo, debemos usar una interfaz.
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.
La interfaz puede establecer un subconjunto de las operaciones de una clase y no necesariamente todas ellas. Podemos modelar la interfaz igual que una clase, con un símbolo rectangular. La diferencia es que la interfaz no tiene atributos.
Las maneras de distinguir una interfaz de una clase que no muestra sus atributos son usando un estereotipo y especificando la palabra << interfaz >> en el rectángulo, o colocar la letra “I” al principio del nombre de una interfaz.
Gráficamente una interfaz se puede representar de forma expandida como una clase estereotipada con la etiqueta <
La relación entre una clase y una interfaz se conoce como realización. Esta relación se representa con una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que adjunte y apunte a la interfaz.
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces.
En UML una interfaz es una colección de operaciones que sirven para especificar los servicios de una clase o un componente.
Dependencias
Un estereotipo representa el principal mecanismo de extensión de UML.
Un estereotipo extiende el
vocabulario de UML.
Se representa con
un nombre entre dos pares de mayor y menor (<< >>).
Estereotipos en Diagrama de Clases
El estereotipo sirve para dar una particularidad a la clase, es como declararle un tipo, por tanto, puede
haber unas clases de un estereotipo, otras de otro, etc. Podríamos escribir un
diagrama de cualquier tipo con un diagrama de clases usando estereotipos.
Si la lista de atributos y métodos es larga, se pueden usar estereotipos para organizarla de
de manera que sea más comprensible:
 |
|
Estereotipos
en Diagrama de Casos de Uso
En las relaciones:
• <<extend>>: Representa opcionalidad. Un caso de uso extiende
la funcionalidad de otro. Por ejemplo una transferencia a fecha
extiende el caso de uso de una transferencia en el día. La relación de
extensión se utiliza para modelar la parte de un caso de uso que puede
considerarse como un comportamiento opcional. De esta forma se separa
el comportamiento opcional del
obligatorio. Esta relación se representa como una dependencia estereotipada
como <<extiende>>.
• <<include>>: Representa obligatoriedad. Por ejemplo una transferencia o un pago con tarjeta incluye el caso de uso Debitar
dinero de cuenta.
• <<uses>>: No especifica ni
opcionalidad ni obligatoriedad. Esta relación significa que un caso de uso,
llamado base, incorpora explícitamente el comportamiento de otro caso de uso.
El caso de uso incorporado nunca se encuentra aislado. Es instanciado sólo como
parte de algún caso de uso base que lo utiliza. La relación de uso se representa como una dependencia estereotipada con la etiqueta <<usa>>.
 La
relación de uso se utiliza
para delegar un comportamiento, común a varios casos de uso (los casos
de uso base), a un sólo caso de uso. En el ejemplo del cajero automático todos los casos
de uso tienen un comportamiento común: el cliente debe validarse antes
de retirar dinero, ingresar dinero o consultar el saldo de su cuenta. En lugar
de incluir este comportamiento en cada caso de uso, como hicimos cuando
escribíamos la especificación de Extraer Dinero, podemos agruparlo en un nuevo
caso de uso Validar Cliente. Los casos de uso Extraer Dinero, Ingresar Dinero y
Consultar Dinero utilizarán el caso de uso Validar Cliente. La figura muestra
el diagrama de casos de uso del cajero empleando las relaciones de uso.
La relación de uso debe indicarse
explícitamente en el flujo de eventos de la especificación del caso base. Por
ejemplo, el flujo de eventos principal de la especificación del caso de uso
Extraer Dinero debería escribirse de esta forma:
 Flujo de Eventos Principal
1.
Usa Validar Cliente.
2.
El cajero
solicita la cantidad a retirar.
3.
El cliente
introduce la cantidad a retirar.
4.
El cajero
comprueba si el cliente dispone de esa cantidad en su cuenta y si hay
suficiente dinero en el cajero.
5.
Si el
cliente dispone de esa cantidad y el cajero tiene suficiente dinero, el cajero actualiza
la cuenta del cliente, registra la operación y le entrega el dinero al cliente.
Estereotipos en Diagrama de
Interfaces
Como vimos, a las clases abstractas puras, es decir, a las
clases que no contienen ninguna implementación, se les llama interfaces.
Gráficamente
una interfaz se puede representar de forma expandida como una clase
estereotipada con la etiqueta
<<interface>> o, en su forma abreviada, con una figura en forma de piruleta.
|
En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces. La forma abreviada generalmente se usa en los diagramas de componentes.
Hay dos relaciones que pueden existir entre una clase y una interfaz: la dependencia y la realización.
La dependencia entre una clase y una interfaz tiene el mismo significado y representación que entre dos clases, indica que la clase usa la interfaz.
Para que una interfaz se pueda usar hace falta que otra clase implemente las operaciones que la interfaz especifica. A esta relación entre la interfaz y la clase que la implementa se le llama realización. La realización indica que la clase implementa todas las operaciones de la interfaz. Gráficamente la realización se representa como una generalización con la línea discontinua.
Diferencia
entre Clase Abstracta e Interfaz
Las clases abstractas obligan la
herencia. No
se pueden instanciar, es decir, no se puede crear objetos de ellas.
Las clases abstractas pueden
definir métodos y propiedades abstractos.
Las interfaces contienen las
declaraciones de los métodos, pero no su implementación. Al igual que las clases
abstractas, son plantillas de comportamiento que deben ser implementados por otras clases.