Casos De Uso

Tema 5. Casos de Uso. Ejercicios Resueltos

Ejercicio 1. Gestión de fincas e inmuebles

Enunciado

Se desea desarrollar una aplicación de gestión de fincas e inmuebles. La aplicación

deberá cubrir todos los aspectos relacionados con dicho tema, teniendo en cuenta la

siguiente dinámica de funcionamiento:

Una empresa gestiona un conjunto de inmuebles, que administra en calidad de

propietaria. Cada inmueble puede ser bien un local (local comercial, oficinas, ...), un

piso o bien un edificio que a su vez tiene pisos y locales. Como el número de

inmuebles que la empresa gestiona no es un número fijo, la empresa propietaria

exige que la aplicación permita tanto introducir nuevos inmuebles, con sus datos

correspondientes (dirección, número, código postal, ...), así como darlos de baja,

modificarlos y consultarlos. Asimismo, que una empresa administre un edificio

determinado no implica que gestione todos sus pisos y locales, por lo que la

aplicación también deberá permitir introducir nuevos pisos o locales con sus datos

correspondientes (planta, letra,...), darlos de baja, modificarlos y hacer consultas

sobre ellos.

Cualquier persona que tenga una nómina, un aval bancario, un contrato de trabajo o

venga avalado por otra persona puede alquilar el edificio completo o alguno de los

pisos o locales que no estén ya alquilados, y posteriormente desalquilarlo. Por ello

deberán poderse dar de alta, si son nuevos inquilinos, con sus datos correspondientes

(nombre, DNI, edad, sexo, fotografía, ... ), poder modificarlos, darlos de baja,

consultar, etc. (para la realización de cualquiera de estas operaciones es necesaria la

identificación por parte del inquilino). Por otra parte, cada mes el secretario de la

empresa pedirá la generación de un recibo para cada uno de los pisos y de los

locales, el cual lleva asociado un número de recibo que es único para cada piso y

para cada local y que no variará a lo largo del tiempo, indicando el piso o local a que

pertenece, la fecha de emisión, la renta, el agua, la luz, la actualización del IPC

anual, portería, IVA, etc. Y otros conceptos, teniendo en cuenta que unos serán

opcionales (sólo para algunos recibos) y otros obligatorios (para todos los recibos).

Además, para cada recibo se desea saber si está o no cobrado.

Con vistas a facilitar la emisión de recibos cada mes, la aplicación deberá permitir la

generación de recibos idénticos a los del mes anterior, a excepción de la fecha.

Además deberán existir utilidades para inicializar los conceptos que se desee de los

recibos a una determinada cantidad y también debe ser posible modificar recibos

emitidos en meses anteriores al actual. La aplicación también deberá presentar los

recibos en formato impreso, pero teniendo en cuenta que en un recibo nunca

aparecerán aquellos conceptos cuyo importe sea igual a cero.

De igual forma, el secretario debe poder gestionar los movimientos bancarios que se

producen asociados a cada edificio, piso o local. Un movimiento bancario siempre

estará asociado a un banco y a una cuenta determinada de ese banco. En esa cuenta

existirá un saldo, acreedor o deudor, que aumentará o disminuirá con cada

movimiento. Para cada movimiento se desea saber también la fecha en que se ha

realizado. Un movimiento bancario puede ser de dos tipos: un gasto o un ingreso.

Si el movimiento bancario es un gasto, entonces estará asociado a un inmueble

determinado, y se indicará el tipo de gasto al que pertenece entre los que se tienen

estipulados. Ejemplos de gastos son el coste de la reparación de un ascensor del

inmueble que pertenece a gastos de reparación, el sueldo de la señora de la limpieza,

etc. Sí el movimiento bancario es un ingreso entonces estará asociado a un piso de

un inmueble determinado o a un local y también se indicará el tipo de ingreso al que

pertenece, como en el caso de los gastos. Ejemplos de ingresos son precisamente los

recibos que se cobran cada mes a los inquilinos.

Basándose en los gastos e ingresos que se deducen de los movimientos bancarios, la

aplicación deberá ser capaz de ocuparse de la gestión económica generando los

informes que facilitan la realización de la declaración de la renta.

Por último, la aplicación deberá ser capaz de proporcionar el acceso, de forma

estructurada, a toda la información almacenada en el sistema, generando para ello

los listados necesarios que requiere el secretario.

Ejemplos de listado son: el listado de todo los inquilinos ordenado por fechas, el

listado de inquilinos que han pagado o no en un determinado intervalo de tiempo, el

listado de todos los inmuebles, el listado de todos los pisos y locales de cada

edificio, el listado de todos los recibos pendientes de cobro en un determinado

intervalo de tiempo, etc.

Solución:

A continuación se muestra el diagrama de casos de uso en el que se representan al

actor propietario y las tareas requeridas por el sistema de gestión de fincas e

inmuebles (ver Figura 5.1).

El propietario será el responsable de la gestión del edificio, local o de los pisos

mediante el alta, las modificaciones, consulta y la baja de los mismos.

En este diagrama de casos de uso asociado con el propietario, los casos de usos con

los que se comunica el actor son:

? Gestión de edificios.

? Gestión de locales.

? Gestión de pisos.

Cada uno de los casos de uso anteriores refleja las actividades comunes que se deben

realizar en el alta, baja, modificación y consulta. Ya que en el enunciado se hace

referencia a estas cuatro funcionalidades que se deben permitir en el sistema, se ha

reflejado tal situación introduciendo un caso de uso específico si se hace referencia

al edificio, al local o al piso. Se ha hecho este desglose y diferenciación dependiendo

de si es un edificio, local o piso, ya que las operaciones que conllevan cada uno es

distinta aunque podamos nombrarlas de la misma forma. Los datos y actividades que

se manejan son diferentes.

Figura 5.1:.Casos de uso relacionados con el actor propietario.

La relación empleada para organizar los casos de uso es la de un extend, ya que se

intenta identificar que cualquiera de estas funcionalidades se pueden o no realizar

tanto individual corno conjuntamente. Además, hemos relacionado mediante un

extend el caso de uso de Gestión de locales y de pisos con el caso de uso Gestión

de edificio. Con esto reflejamos que la gestión de edificios puede conllevar la

gestión de locales, de pisos o de ambos.

En el siguiente diagrama (ver Figura 5.2) se muestran los casos de uso relacionados

con el actor inquilino. El inquilino va a ser aquella persona que tiene algún tipo de

aval, de los expuestos en el enunciado, y, por tanto, puede realizar algunas de las

siguientes operaciones en el sistema:

? Alquilar.

? Desalquilar.

? Darse de baja.

? Modificar sus datos.

? Consultarlos.

Para cada una de estas operaciones hay un caso de uso en el diagrama reflejando la

situación anterior. Además, ya que se nos dice que para la realización de cualquiera

de las operaciones es necesaria su identificación, se ha reflejado un caso de uso

nombrado Identificación que se relaciona con los anteriores mediante la relación de

include. Con la relación de include hacemos especial énfasis en esta situación.

Figura 5.2: Casos de uso del actor 'Inquilino".

Tras volver a examinar con más detalle la descripción proporcionada se observa que

cuando se produce el alquiler éste puede ser el de un piso (Alquiler Piso) un local

(Alquiler Local) y de edificio (Alquiler de Edificio). Por ello se generan tres

nuevos casos de uso que implican una relación de extend con el caso de uso de

Alquilar.

Como hemos observado que la primera vez que se produce una operación de alquiler

se debe permitir el alta de los datos del inquilino, se ha creado el caso de uso Alta

Inquilino como una extensión de Alquiler Piso, Alquiler Local y Alquiler Edificio.

Finalmente, el último diagrama de caso de uso que se muestra (Figura 5.3) es aquel

en el que se encuentra involucrado el actor secretario. Tras una visión general de

las características del sistema, observamos que las tareas del secretario son:

Obtención de los distintos tipos de recibos. Obtener los informes económicos.

Generación de los listados.

Como vemos, en aras de reflejar de una forma más meticulosa las funcionalidades

que debe contemplar el sistema, todos los casos de uso genéricos, con los cuales está

relacionado, se desglosan en otros casos de uso. Para ello se ha utilizado la relación

de extensión en algunos casos de uso.

Así pues, el caso de uso de "Generar recibos" está relacionado mediante un extend

con los casos de uso:

? Recibos idénticos mes anterior.

? Inicializar conceptos.

? Modificar los del mes anterior.

Este desglose se ha realizado para reflejar lo que el enunciado

...