Java Desarrollo de sistemas: Diseño de sistemas

Roles

Jefe de Proyecto/Scrum Master/Arquitecto Software
- Es el interlocutor válido con el profesor, que actuará como gerente del proyecto y origen de los requisitos de usuario.
- Diseña la arquitectura de los componentes, servidores de aplicación, bases de datos, y de todos los sistemas software que intervengan en el despliegue de la aplicación para ponerla en funcionamiento.
- Coordinación del proyecto, planificación ágil, asignación de tareas, gestión de la Wiki.
- Planifica, controla y organiza el trabajo.
Analista/Ingeniero de Requisitos
- Análisis de requisitos y diseño, casos de uso, diagramas de robustez, diagramas de secuencia
Administrador de sistemas:
- Instala y configura los entornos de desarrollo, servidores y sistemas software de los que depende la aplicación (base de datos, servidor web, servidor de aplicaciones, sistema de control de versiones, etc.)
- Analiza, diseña y mantiene el esquema de base de datos de la aplicación; ayuda en la codificación de las clases de entidad que tengan que ver con el acceso a la base de datos
Diseñador de interfaz de usuario
- Gurú balsamiq, maquetación CSS, gestión interfaces
- Analiza, diseña y codifica la interfaz de usuario (clases de vista) en HTML y JavaScript.
Codificador de pruebas
- Planifica, codifica y configura la ejecución de casos de prueba unitarias, funcionales y de integración.
Analista/Programador
- Codifica los componentes de software; programa las clases en Groovy
- Implementación MVC Grails/Groovy, gestión de plugins

Participante	Rol
Carlos M. Cornejo Crespo	Jefe de Proyecto/Scrum Master/Arquitecto Software
Antonio Falcón Aragón	Analista/Ingeniero de Requisitos
Antonio Fco. Martín Romero	Administrador de sistemas
Jose Luis Falcón Ramírez	Diseñador de interfaz de usuario/Integración con la Vista
Antonio Fco. Martín Romero	Codificador de pruebas
Carlos Villegas Núñez	Analista/Programador/Gurú GRails

Entregable 1 - Planificación y configuración

En cada sprint el trabajo del equipo de desarrollo se va a organizar en un conjunto de tareas, que identificarán cada unas de las funcionalides a implementar. A continuación se definen:
ScrumMaster - Gestiona la planificación de tareas y asume responsabilidades de estudio/integración con plugins/funcionalidades que surgen de otras tareas. Gestión de documentación.

Planificar tareas
Documentación/Entregables

Análisis - Identifica necesidades UML en el análisis y dirige el modelado guaido por casos de uso

Casos de Uso
Diagramas de Robustez
Diagramas de Secuencia

Integración con la Vista

Maquetación Balsamiq
Integración HTML/GSP
Estudio de taglibs y layout SiteMesh
Maquetación CSS

Implementación - Da cuerpo al diseño con Grails, generando las estructuras de datos necesarias en cliente y lógica de negocio.

Domain/Controller/Services/Hibernate mapping

Pruebas - Recopila todas la pruebas software aplicables al proyecto.

Pruebas Unitarias.
Pruebas Integración.
Pruebas Funcionales.

Capa de acceso a BD - Da soporte a la capa de acceso a datos con MySQL. Genera scripts de startup y actualiza la BD.

Scripts actualización del DDL/DML/DCL
Creación startup bash.

Sprint	Duración
Sprint 0 - Planiﬁcación y conﬁguración	hasta 17/04/2011
Sprint 1 - Consulta de habitación disponible	hasta 27/04/2011
Sprint 2 - Reserva de habitación disponible	hasta 11/05/2011
Sprint 3 - Cancelar reserva	hasta 18/05/2011
Sprint 4 - Consumos (bebida/teléfono)	hasta 25/05/2011
Sprint 5 - Llegada de cliente con reserva	hasta 1/05/2011
Sprint 6 - Cálculo de factura y salida del cliente + Entrega Proyecto	hasta 8/06/2011

Reuniones

Reunión del día 19/04/2011

Contexto:
Videoconferencia con skype y duración 1.5h.
Participantes:

José Luis Falcón Ramírez
Antonio Falcón Aragón
Carlos M. Cornejo Crespo
Antonio Fco. Martín Romero
Carlos Villegas Núñez

Temas tratados:
Hemos repasado el conjunto de tareas que nos hemos asignado. Hemos solucionado algunas dudadas referentes al uso de los tickets y funcionamiento de assembla.
Hemos decido subir los fuentes de:

maquetaciones
robustez

También hemos comentado la necesidad de subir las capturas en png de los casos de uso, maquetaciones y robustez que se añadirán a la wiki.
Hemos configurado el plug-in Subversive SVN Connectors del IDE Eclipse.
Instalación del plugin de authentication

Reunión 11/05/2011

Contexto:
Reunión informal en clase durante 30 mins.
Participantes:

José Luis Falcón Ramírez
Antonio Falcón Aragón
Carlos M. Cornejo Crespo
Antonio Fco. Martín Romero
Carlos Villegas Núñez

Durante la reunión hemos hablado de la necesidad de completar las tareas para evitar dependencias entre componentes, y de esta forma cada compañero puede ir avanzando sin verse afectado por la demora.
Después hemos repasado la planificación, tras introducir cambios en la tipología de tickets/finalización tickets padre.
También se trató de los problemas de versionado con las herramientas proporcionadas con el IDE SSTS. Se han detectado comportamientos que retrasan el trabajo.

Entregable 2 - Requisitos y arquitectura

En esta sección se define la estructura del sistema que comprende los elementos software con sus propiedades visibles y no software, además de las relaciones de dichos elementos, mediante sus respectivas interfaces.

Arquitectura Física

La arquitectura física no es más que la asignación de los componentes software necesarios para el correcto funcionamiento del sistema, sobre elementos hardware. En nuestro caso, observemos el siguiente diagrama de despliegue.

En la imagen anterior abstraemos el funcionamiento de nuestra aplicación, identificando tres módulos atómico como son:

El WAR de la aplicación
El servidor de despligue, en este caso un Tomcat
Servidor de Bases de Datos, como puede ser MySQL

Hardware Recomendado

CPU: Cualquier arquitectura x86
Memoria RAM: 2GB
HDD: 320GB

Software Base

SSOO: Windows XP/7/Ubuntu/Linux
Máquina Virtual de Java, superior a 1.5
MySQL Server 5
Tomcat 5.5
Navegador Web: Firefox 4, Chrome 10, IE 8

Arquitectura Lógica

La arquitectura lógica especifica la forma en que los artefactos software son unidades de composición, para que mediante la combinación de todos ellos se consiga implementar los requisitos del sistema.

Integración con log4j

En esta sección repasaremos como configurar log4j con nuestro proyecto grails.
Archivos a modificar:
grails-app/conf/Config.groovy

log4j = {
appenders {
console name: 'stdout', layout: pattern(mineIs: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')

rollingFile name:'mineIs', file: "../loggy.log", append: true,
layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
}

info mineIs:'milog', additivity:false
}

Añadimos el ámbito de log o cargamos logger dentro de class

Entregable 3 - Documento de análisis

Casos de Uso

Consulta Habitación Disponible

Caso de Uso: Consultar Habitación/es Disponible/s. 
Descripción: El sistema comprueba si existen habitaciones disponibles

según un período de días establecido. 
Precondición: 
Postcondición: El sistema procesa la operación según indicaciones del usuario

y muestra por pantalla las habitaciones disponibles. 
Escenario Principal: 
1. El sistema solicita los siguientes datos al usuario: Fecha Entrada,

 Fecha Salida, Nº Habitaciones, NºAdultos, NºNiños.
2. El actor Usuario introduce los datos y pulsa en Consultar Disponibilidad.
3. El sistema comprueba que el rango de fechas sea válido.
4. El sistema comprueba que hay suficientes habitaciones disponibles

para esa categoría, en ese período de fechas.
5. El sistema muestra un listado de las habitaciones disponibles. 
Flujos Alternativos: 
3a. Si el rango de fechas no es válido:
1. El sistema muestra el error y se reinicia el Caso de Uso.
4a. Si no hay habitaciones disponibles de esa categoría:
1. El sistema comprueba la disponibilidad de habitaciones con

diferente categoría en ese rango de fechas.
2. El sistema muestra un listado con las habitaciones.
*a. En cualquier momento el cliente cancela la consulta:
1. El sistema reinicia el Caso de Uso.

Reserva de Habitación

Caso de Uso: Reservar Habitación/es.
Descripción: El sistema realiza la reserva de la habitación seleccionada,

según el rango de fechas establecido. 
Precondiciones: 
* La habitación seleccionada debe estar disponible en las fechas indicadas.
* El usuario debe estar registrado en el sistema.
Postcondición: El sistema procesa la operación y entrega al usuario el Código

de la reserva realizada. 
Escenario Principal: 
1. El sistema muestra la habitación y el coste final para la estancia

seleccionada.
2. El actor Usuario acepta la reserva.
3. El sistema establece el estado de la habitación en Reservada para esos días.
4. El sistema devuelve al cliente el código y los detalles de la reserva. 
Flujos Alternativos: 
2a. Si el usuario no acepta la reserva:
1. Se reinicia el Caso de Uso.
3a. Si el proceso de reserva falla:
1. El sistema muestra el error y se reinicia el Caso de Uso..
*a. En cualquier momento el usuario decide cancelar la reserva:
1. El sistema reinicia el Caso de Uso.

Cancelar Reserva

Caso de Uso: Cancelar Reserva. 
Descripción: El sistema comprueba si el usuario ha realizado una reserva

 con antelación y la cancela, aplicando el coste de penalización adecuado. 
Precondición:
* El usuario está registrado en el sistema.
* El usuario ha realizado una reserva, y tiene el código de la misma.
Postcondición: 
* El sistema cancela la reserva
* Se cobra al cliente el coste de penalización, en caso de haberlo.
Escenario Principal: 
1. El actor Usuario solicita la cancelación de la reserva.
2. El sistema comprueba el nº de días que faltan hasta el día reservado.
3. El sistema calcula el coste de penalización.
4. El sistema realiza el cobro sobre la tarjeta de crédito del usuario.
5. El sistema cancela la reserva y vuelve a marca la habitación como Disponible. 
Flujos Alternativos: 
2a-5a. Si el proceso falla:
1. El sistema muestra el error y se reinicia el Caso de Uso.
*a. En cualquier momento el cliente cancela la operación:
1. Se reinicia el Caso de Uso.

Realizar Llamada Telefónica

Caso de Uso: Realizar Llamada Telefónica.
Descripción: El cliente realiza una llamada telefónica. 
Precondición: El cliente ocupa una habitación del hotel.
Postcondición: El sistema calcula la duración y el coste de la llamada. 
Escenario Principal: 
1. El cliente comienza la llamada indicando si es nacional o internacional.
2. El cliente habla por teléfono.
3. El cliente termina la llamada.
4. El sistema calcula la duración de la llamada y el coste total de la misma.

Consumir Bebida

Caso de Uso: Consumir Bebida/s. 
Descripción: El cliente consume una bebida del minibar. 
Precondición: El cliente ocupa una habitación del hotel.
Postcondición: El sistema calcula el coste de las consumiciones que el

cliente ha realizado. 
Escenario Principal: 
1. El cliente elige el tipo de bebida que va a tomar.
2. El cliente consume la bebida.
3. El sistema calcula el coste de la consumición, dependiendo del tipo de

bebida y de la categoría de la habitación.

Llegada de Cliente

Caso de Uso: Llegada de Cliente. 
Descripción: El cliente llega al hotel. 
Precondición: El cliente ha realizado la reserva de la habitación previamente.
Postcondición: El sistema asigna la habitación determinada al cliente, marcando

su estado como ocupado. 
Escenario Principal: 
1. El sistema solicita los datos del cliente.
2. El cliente facilita los datos al sistema.
3. El sistema busca una habitación concreta, según la reserva del usuario, y

la marca como ocupada, asignándosela al cliente. 
4. El sistema reinicia el contador de llamadas de la habitación.
Flujo Alternativo:
2a. Los datos son erróneos:
1. El sistema reinicia el C.U.
2b. El cliente no ha realizado reserva
1. Finaliza el C.U, quedando sin efecto sobre el sistema.
3a. El proceso falla:
1. Se reinicia el C.U.
4a. El proceso falla
1. Se reinicia el C.U.

Calcular Factura

Caso de Uso: Calcular Factura. 
Descripción: Se calcula el precio total de la estancia y se presenta la

factura al cliente. 
Precondición: El cliente tiene asociada una reserva y ocupa una habitación

del hotel.
Postcondición: Se presenta la factura al cliente. 
Escenario Principal: 
1. Se calcula el coste total de las llamadas realizadas.
2. Se calcula el coste total de las bebidas consumidas.
3. Se calcula el coste total de la factura (reserva, llamadas, bebidas).
4. Se devuelve al cliente la factura, detallando los costes por apartados.
Flujo Alternativo
1-4a. El proceso falla:
1. Se reinicia el C.U.

Salida de Cliente

Caso de Uso: Salida de Cliente. 
Descripción: El cliente termina su estancia en el hotel. 
Precondición: Se ha realizado la facturación al cliente.
Postcondición: Se eliminan los datos de reserva del cliente. 
Escenario Principal: 
1. Se presenta la factura.
2. Se inicializa el tiempo de llamadas de la habitación.
3. Se reponen las bebidas del minibar.
4. Se marca la habitación como libre, incrementándose el número de

habitaciones libres del hotel.
Flujo Alternativo
1-4a. El proceso falla:
1. Se reinicia el C.U.

Entregable 4 - Documento de diseño

Diagrama de Clases

Con el siguiente diagrama queremos representar el comportamiento estático de nuestro sistema, identificando aquellas relaciones entre entidades que se correspondan con la realidad a implementar.