https://www.dropbox.com/s/gy6jrca5491dw4f/Diagrama%20de%20Clases.uml


https://www.dropbox.com/s/jvd17pth6cv03c0/Diagrama%20de%20secuencia.uml

Ejemplo de Diagrama de Clases y Secuencia

 https://www.dropbox.com/s/kehmsckt626ffbw/clases.uml

 

 

 

 

https://www.dropbox.com/s/pb1waa29k0lbp5b/secuencia.uml

 

Un ejemplo de Diagrama de Secuencia

Un ejemplo de Diagrama de Secuencia

Para el caso de uso “Mover Pieza” en un juego de Ajedrez, se ha decidido hacer tres librerías/paquetes, una para la interfaces de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes

En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer.

Ejemplo de Diagrama de Clases de Una Universidad

Ejemplo de Diagrama de Clases de Una Universidad

Se quiere desarrollar un sistema de información para la Universidad de Oriente según la descripción siguiente.

La Universidad se caracteriza mediante su nombre y la ciudad donde se sitúa. En la Universidad están vinculados dos tipos de Persona: Trabajadores, que la Universidad emplea, y Estudiantes, que estudian en la Universidad. Cada Persona tiene una CI y un nombre.

Los Trabajadores pertenecen a dos grupos: PDI y PAS. Cada Trabajador tiene asociada una fecha de inicio de su contrato. Cada miembro del PDI también tiene una categoría, mientras que cada miembro del PAS tiene un puesto. Los miembros del PDI pueden o no ser Doctores. Las actividades que desarrolla el PDI son investigar y enseñar, mientras que la actividad que desarrolla el PAS es administrar.

La Universidad se compone de un conjunto de Departamentos, cada uno de los cuales tiene un nombre y un conjunto de Trabajadores adscrito. Un Trabajador no puede estar adscrito a más de un Departamento. Un PDI está adscrito obligatoriamente a un Departamento, mientras que un PAS, no. Cada Departamento está dirigido por un Doctor.

Un Estudiante' puede ser bien 'Estudiante de grado, de una determinada titulación, bien 'Estudiante' de Doctorado, de un determinado programa de Doctorado. Un Estudiante de grado puede también colaborar con un Departamento como becario y puede realizar un PFC dirigido por un miembro del PDI'. Un 'Estudiante de Doctorado realiza una tesis dirigida por un Doctor. Puede suponer que un Estudiante no puede estudiar en más de una Universidad y que un Trabajador no puede ser empleado por más de una Universidad.

Una Persona puede ser a la vez Trabajador y Estudiante,

Un Estudiante no puede ser a la vez 'Estudiante de grado y 'Estudiante de Doctorado,

Los únicos tipos de Trabajador que existen son PDI y PAS,

Un Trabajador no puede ser a la vez PDI y PAS.

Glosario:

PAS: Personal de Administración y Servicios

PDI: Personal Docente e Investigador

Casos de Uso Completo

Listado de Requerimientos Funcionales

R1: El sistema debe permitir ingresar  un cliente: Nombre, Rut,  apellido paterno, apellido materno, teléfono, fecha de nacimiento.

R2: El sistema debe permitir mostrar si un departamento está ocupado o deshabitado.

R3: El sistema debe permitir mostrar si un departamento esta comprado o arrendado.

R4: El sistema debe permitir mostrar si un departamento incluye balcón o no.

R5: El sistema debe permitir mostrar el costo de un departamento con balcón.

R6: El sistema debe permitir mostrar el costo de un departamento sin balcón.

R7: El sistema debe permitir mostrar el historial seleccionando un parámetro de “desde” y otro parámetro “hasta” para escoger una fecha de pago de un cliente con los siguientes datos: Pago de luz, pago de agua, pago de gastos comunes.

R8: El sistema debe permitir mostrar los clientes morosos hasta la fecha actual y mostrar los siguientes datos: Nombre cliente, Rut cliente, mes en deuda y monto que debe.

R9: El sistema debe permitir mostrar que estacionamiento está ocupado.

R10: El sistema debe permitir mostrar los siguientes datos del cliente si el estacionamiento está ocupado: numero de estacionamiento, Nombre de cliente, Rut y departamento en el que esta habitando.

R11: El sistema debe permitir mostrar que estacionamiento está desocupado.

R12: El sistema debe permitir  mostrar los siguiente datos del estacionamiento si esta desocupado número de estacionamiento y costo.

R13: El sistema debe permitir ingresar el pago que está realizando el cliente como; pago de agua, pago de luz, pago gastos comunes.

R14: El sistema debe permitir mostrar en ingreso exitosos del cliente que está haciendo el pago.

R15: El sistema debe permitir validar que los campos estén debidamente completados según las instrucciones del cliente.

R16: El sistema, tendrá un modulo o menú que permitirá  generar reportes por fecha de pago de gastos comunes por Departamento.

R17: El sistema, tendrá un modulo o reporte que generara reportes de todos los propietarios/arrendatarios que habitan en el Edificio.

R18: El sistema debe permitir modificar los datos de un arrendatario

R19: El sistema debe permitir actualizar los costos de los departamentos

R20: El sistema debe permitir mostrar un informe anual de ingresos

R21: El sistema tendrá un modulo que debe permitir generar un informe diario/semanal/ mensual/trimestral/anual  de egresos/ingresos de costos de gastos comunes, de mantenciones realizadas en el Edificio.

R21: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Gastos Comunes.

R22: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado  a Estacionamiento.

R23: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Bodega.

R24: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Terraza.

R25: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Saldo Anterior.

R26: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Llaves.

R27: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el gasto asociado a Otros.

R28: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla el mes y año correspondiente que se esta cobrando.

R29: El sistema debe permitir mostrar al ingresar el número de departamento en una plantilla la fecha hasta la que tiene plazo para pagar.

R30: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a Administración con los siguientes datos: Tipo, Número, Valor, Total Mes.

R31: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a Servicios Básicos con los siguientes datos: Tipo, Número, Valor, Total Mes.

R32: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a Mantenciones y Reparaciones con los siguientes datos: Tipo, Número, Valor, Total Mes.

R33: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a Mantenciones y Reparaciones con los siguientes datos: Tipo, Número, Valor, Total Mes.

R34: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a  Materiales e Insumos con los siguientes datos: Tipo, Número, Valor, Total Mes.

R35: El sistema debe permitir mostrar en una plantilla los gastos mensuales del edificio asociados a Gastos Comunes del Mes con los siguientes datos: Tipo, Número, Valor, Total Mes.

Diagrama de Casos de Uso

Diagrama de Casos de Uso

GESTIÓN DE PROPIETARIO

Descripción breve

Este caso de uso permite al conserje o administrador mantener los datos de registro de los propietarios de cada departamento del edificio. El administrador o conserje puede Crear, Listar, Eliminar o Modificar los datos de un propietario y actualizar sus datos.

Actores

1.- Actor Primario: Conserje o Administrador

2.-Actor Secundario: Modulo Mantenedor de Propietarios

Flujo Principal

1.1 Iniciar Sesión

Se inicia cuando el Conserje o Administrador accede al Sistema de Administración de Edificio. El Conserje o Administrador ingresa su ID y contraseña y obtiene ingreso al sistema.

1.2 Crear Propietario

El sistema solicita al Conserje o Administrador ingresar los datos del Propietario. Al ingresar el número de cédula de identidad, el sistema comprobará, mediante el número de cedula de identidad que el Propietario no se encuentre registrado. Si no se encuentra el número de

cedula de identidad ingresada, el sistema solicita el resto de la información y mediante confirmación registra al Propietario. Si la cedula de identidad ingresada se encuentra registrada, el sistema despliega la información del Propietario y permite modificar los datos.

1.3 Listar

El sistema entregará un listado de todos los Propietarios existentes.

1.4 Eliminar Propietario

El sistema solicitará el ingreso del número de cédula de identidad del propietario. Si este existe, mediante confirmación permite borrar al Propietario del sistema.

1.5 Modificar Propietario

A través del ingreso del número de cedula de identidad del Propietario, se comprueba que esté registrado. El sistema desplegará la información del propietario y permitirá modificarla. Mediante confirmación el sistema guarda la información actualizada.

Diagrama Casos de USo