University Program Schedule

Documento de Arquitectura del Sistema

Nombre del Equipo de Trabajo: UPS

Nombre de los Integrantes:

Andrés Felipe Aguirre e-mail: pipekike@hotmail.com

Juan David Arango e-mail: juan.arango@correo.icesi.edu.co

Ricardo Alejandro Arcila e-mail: ricartomojo@hotmail.com

Andrés Fabián Barrera e-mail: andres397@gmail.com

Oscar Kiyoshige Garcés e-mail: oscarkiyoshige@hotmail.com

Tabla de Contenido Sección 1. Descripción del Documento .......................................................................................... 6

1.1 Propósito y Audiencia ........................................................................................................... 6

1.2 Organización del Documento ................................................................................................ 6

1.3 Convenciones ........................................................................................................................ 6

1.4 Terminología y Definiciones .................................................................................................. 6

1.5 Documentos Relevantes ........................................................................................................ 7

Sección 2. Generalidades del Proyecto ........................................................................................... 8

2.1 Problema a Resolver .............................................................................................................. 8

2.2 Descripción General del Sistema a Desarrollar ..................................................................... 8

2.3 Objetivos ................................................................................................................................ 8

2.4 Stakeholders .......................................................................................................................... 9

Sección 3. Motivadores Arquitecturales ....................................................................................... 11

3.1 Motivadores de Negocio ..................................................................................................... 11

3.2 Restricciones de Tecnología ................................................................................................ 12

3.3 Atributos de Calidad ............................................................................................................ 12

3.3.1 Escenarios de Calidad ...................................................................................................... 12

Sección 4. Contexto ....................................................................................................................... 13

Sección 5. Estilo y Tácticas Arquitecturales ................................................................................... 13

Sección 6. Puntos de Vista y Modelos Arquitecturales ............................................................... 14

6.1 Punto de Vista Funcional ..................................................................................................... 14

6.1.1 Modelo de Componentes ................................................................................................. 15

6.2 Punto de Vista de Despliegue .............................................................................................. 16

6.2.1 Diagrama de Deployment ................................................................................................. 16

Ilustración 1 ................................................................................................................................... 14

Ilustración 2 ................................................................................................................................... 15

Ilustración 3 ................................................................................................................................... 16

Tabla 1 ............................................................................................................................................. 8

Tabla 2 ............................................................................................................................................. 9

Tabla 3 ........................................................................................................................................... 10

Tabla 4 ........................................................................................................................................... 11

Tabla 5 ........................................................................................................................................... 12

Tabla 6 ........................................................................................................................................... 12

Tabla 7 ........................................................................................................................................... 12

Tabla 8 ........................................................................................................................................... 13

Sección 1. Descripción del Documento

1.1 Propósito y Audiencia

Breve descripción de la organización y los usuarios a los que está dirigido este documento

Somos un grupo de estudiantes de Ingeniería de Sistemas de la universidad Icesi, cursando la materia de Ingeniería de Software II. Estamos desarrollando una aplicación que se encargue de facilitar la asignación de horarios para la universidad. Este documento está dirigido principalmente a los desarrolladores del sistema, que en este caso somos todos los integrantes del grupo. También está dirigido al profesor, con el fin de que conozca la arquitectura de nuestro sistema.

1.2 Organización del Documento

Descripción de la organización del documento de arquitectura

Para lograr al objetivo de dejar una arquitectura claramente establecida para nuestro proyecto, redactamos este documento que se encuentra organizado de la siguiente manera. En primer lugar, se hace una breve descripción del documento, donde resaltamos los aspectos más importantes a tener en cuenta durante el desarrollo de este. En segundo lugar, describimos el proyecto, haciendo énfasis en los aspectos más generales, tales como el problema, descripción, objetivos, etc. Posteriormente, comenzamos a hablar de los motivadores arquitecturales, los cuales incluyen los motivadores del negocio, los atributos de calidad y las restricciones. A continuación se menciona el contexto del proyecto, seguido de los estilos y tácticas arquitecturales. Finalmente se define los puntos de vista y modelos arquitecturales, donde se incluye la estrategia arquitectural llevada a cabo en nuestro proyecto.

1.3 Convenciones

Descripción de las notaciones y símbolos utilizados en este documento

En este documento se establecen las siguientes notaciones: ● AFAG: Andrés Felipe Aguirre Guzmán ● JDAP: Juan David Arango Paredes ● RAAT: Ricardo Alejandro Arcila ● AFBS: Andrés Fabián Barrera Salinas ● OKGA: Oscar Kiyoshige Garcés

1.4 Terminología y Definiciones

Descripción de los términos utilizados en el documento y parte del dominio y contexto del problema

● Objeto: Es la representación abstracta de un objeto de la realidad implementado en software mediante una clase. ● Clase: Implementación en software de un objeto. ● Roles de usuarios:

○ Schedule Administrator: Este usuario realizará el cruce de los horarios de cada uno de los Cursos con los Recursos.

○ Main Lecturer: Este usuario podrá agregar información más detallada de los cursos.

○ Program Manager: Este usuario podrá crear, editar, y eliminar Cursos a los cuales les asignará un Main Lecturer.

○ Program Administratror: Este usuario podrá crear, editar, y deshabilitar Programas a los cuales le asignará un Program Manager. También podrá añadir, editar, y (des)habilitar un Recurso de la Universidad.

● Tecnologías utilizadas ○ EJB: Entreprise JavaBeans ○ GWT: Google Web Toolkit

○ JPA: Java Persistence API ○ JDO: Java Data Objects

1.5 Documentos Relevantes

Listado de documentos relevantes, utilizados durante el desarrollo de la arquitectura

Los siguientes documentos son importantes para el desarrollo de la arquitectura: ● launch_v2.5 ● documentacion prototipo_v2.0 ● documento de requerimientos_v2.3 ● strategy_v2.1

1.

Sección 2. Generalidades del Proyecto

2.1 Problema a Resolver

Breve descripción del problema o problemas más relevantes que tiene el cliente en este momento.

Cada universidad se ve enfrentada al mismo problema cada año: Como organizar todos los cursos de forma óptima, cumpliendo con

todas las restricciones tales como salas de conferencias disponibles, la limitada disponibilidad de los profesores, la selección de

cursos por parte de los estudiantes etc. Este es el principal problema al que se enfrentan las universidades, en la actualidad esta

asignación se hace casi manualmente, lo que resulta una tarea muy tediosa que requiere personal especializado.

2.2 Descripción General del Sistema a Desarrollar

Esta sección describe la funcionalidad y el propósito del sistema o subsistemas cuya arquitectura es descrita en este documento.

University Program Schedule hará posible ingresar datos y requerimientos de una forma sencilla, usando una interfaz web, la cual

facilita la asignación manual de horarios. El programa debe permitir:

● Ingresar datos como cursos, recursos, programas, miembros de la facultad como profesores, directores de programa y

decano, reservas de recursos para un curso, relaciones entre profesores y cursos, entre directores de programa y

programas etc. y restricciones relacionadas con el horario.

● Permite la asignación manual de los horarios, es decir un curso se dicta en determinado recurso, en determinados días a

determinadas horas, las cuales dependen de la intensidad horaria del curso.

Tabla 1: Solicitudes del usuario

TABLA 1

Id Solicitudes del usuario Descripción Func. Arq. Sig.

2.3 Objetivos

Esta sección describe los objetivos generales de la arquitectura del sistema dentro del contexto del ciclo de vida del proyecto.

● Objetivo 1: Registrar usuarios, cursos, programas, y recursos en la base de datos, en menos de

30 segundos.

● Objetivo 2: Garantizar que el sistema sea seguro, en cuanto fallos durante la ejecución de la

aplicación.

● Objetivo 3: Garantizar la usabilidad del sistema, integrando de manera correcta nuevas

tecnologías (GWT, EJB).

● Objetivo 4: Garantizar la modificabilidad del sistema, en cuanto a que las funcionalidades van a

estar correctamente separadas, respetando la arquitectura por capas.

2.4 Stakeholders

Esta sección presenta una lista de los stakeholders involucrados en el proyecto. Para cada uno de ellos, se deben listar los concerns que van a ser tenidos en cuenta en el documento de arquitectura. Esta información se presenta en forma de matriz, donde las filas representan los stakeholders y las columnas los concerns. Cada celda determina el grado de relevancia del concern para el stakeholder (Tabla 2). Finalmente, basados en los concerns relevantes a cada stakeholder se dermina los puntos de vista que se le presentarán. El standard ANSI/IEEE 1471-2000 propone que al menos los siguientes stakeholders sean considerados: usuarios, clientes, desarrolladores y administradores.

● Customer ● Application software developers

● Infrastructure software developers

● End users

● Application system engineers

● Application hardware engineers

● Project manager ● Communications engineers

● Chief Engineer/Chief Scientist

● Program management

● System and software integration and test engineers

● Safety engineers and certifiers

● External organizations ● Operational system managers

● Trainers

● Maintainers

● Auditors

● Security engineers and certifiers

Tabla 2: Listado de los Stakeholders

TABLA 2

Stakeholder Descripción

Main Lecturer De tipo usuario final

Program Manager De tipo usuario final

Program Administrator De tipo usuario final

Schedule Administrator De tipo usuario final

Rector Cliente del software

Profesor de Ingeniería de Software II Supervisor del avance del proyecto

Tabla 3: Stakeholders y Expectativas

TABLA 3

Stakeholder Expectativas

Usuario final Funcionalidad especifica del software

Cliente Atributos de calidad del negocio

Supervisor Tecnologías especificas a usar durante el desarrollo

Sección 3. Motivadores Arquitecturales

3.1 Motivadores de Negocio

Esta sección busca identificar los motivadores de negocio de la organización. Normalmente estos motivadores son encontrados, respondiendo a las preguntas:

● Cómo genera utilidad la organización

● De dónde provienen las utilidades de la organización?

● Cuáles son los elementos claves del negocio? En resumen, un motivador de negocio es una descripción corta que define clara y específicamente los resultados deseados de negocio de una organización así como las actividades necesarias para lograrlos. Los motivadores de negocio deben ser: Específicos, Medibles, Agresivos pero viables, Orientados al resultado y limitados en el tiempo. El objetivo es hacer una lista priorizada de motivadores de negocio. Ayuda para su uso:

● El nombre del motivador: Sigue en general la regla: <verbo> + <elemento a medir> + <área de énfasis>

○ Ejemplo: Incrementar ventas en las áreas metropolitanas

● La descripción del motivador: Sigue en general la regla: <Retorno esperado del negocio>+ Mediante+ <Actividad planeada de negocio>

○ Ejemplo: Incrementar ventas en 15 % mediante la apertura de nuevas oficinas

● La medida: Define en una frase como valorar el impacto en el negocio del motivador. Se organiza por rangos y se determina para cada rango, la unidad de medida del impacto. Adicionalmente, se definen los valores mínimos y máximos para cada rango de impacto.

○ Ejemplo:

○ Medida: Crecimiento de las ventas en áreas metropolitanas medido en millones de pesos Ninguna : 0 – 0.9 millones Bajo: 1 millón – 99 millones Moderado: 100 y 499 millones Fuerte: 500 y 899 millones Muy Fuerte: 900 millones o más

● La asociación con el negocio define el motivador a que área organizacional pertenece:

○ Ejemplo:

○ Definido Por: Gerente de Ventas

○ Ejecutado Por: Director y Ejecutivos de Ventas

○ Ubicación en el portafolio: Servicios persona a persona

TABLA 4

Nombre del Motivador de Negocio

Descripción del Motivador de Negocio

Disminuir el tiempo de generación de horarios

Disminuir a 1 semana el tiempo de asignación de horarios a los recursos

Medida del Impacto

Disminución de tiempo medido en semanas.

Ninguna: 6 a 5 semanas Bajo: 5 a 4 semanas

Moderado: 4 a 3 semanas

Fuerte: 3 a 2 semanas

Muy Fuerte: 2 a 1 semana

3.2 Restricciones de Tecnología

Esta sección describe las restricciones de tecnología impuestas por la organización y/o el dominio del problema

TABLA 5

ID Restricción

RES01 Tipo: Tecnología ( J2EE ) Negocio ( Ing. Software II )

Nombre: Restricción de Arquitectura

Descripción:

La aplicación debe estar basada en componentes EJB.

Establecida por: Profesor de la materia Ingeniería de Software II

Alternativas: Ninguna

Observaciones: Ninguna

Esta sección describe las restricciones de negocio impuestas por la organización y/o el dominio del problema

TABLA 6

ID Restricción RES02

Tipo: Tecnología ( GWT ) Negocio ( Ing. Software II )

Nombre: Restricción de Interfaz gráfica

Descripción: La interfaz de la aplicación debe estar desarrollada en la nueva tecnología de Google GWT.

Establecida por: Profesor de la materia Ingeniería de Software II

Alternativas: Ninguna

Observaciones: Ninguna

3.3 Atributos de Calidad

3.3.1 Escenarios de Calidad

Ver wiki TABLA 7

Escenario de Calidad # Stakeholder:

Atributo de Calidad

Justificación

Fuente

Estímulo

Artefacto

Ambiente

Respuesta

Medida de la Respuesta

Sección 4. Contexto

TABLA 8

Título del Caso de Uso

ID del Caso de Uso

Descripción General del Caso de Uso

Entidades Involucradas

Precondiciones

Flujo normal de Eventos

Pos condiciones principales del caso de uso

Sección 5. Estilo y Tácticas Arquitecturales Los sistemas por capas están organizados de manera jerárquica, cada capa provee servicios a otra inmediatamente superior. En Layers Systems algunas capas internas están ocultas a todos, excepto la capa externa adyacente, con la excepción para ciertas funciones cuidadosamente

seleccionadas para la exportación. Así, en estos sistemas los componentes implementan una máquina virtual para algunas capas en la jerarquía. (En otros sistemas, las capas pueden ser sólo parcialmente opacas.) Los conectores son definidos por los protocolos que determinan cómo las capas interactúan. Restricciones topológicas incluyen la limitación de las interacciones de las capas adyacentes. El sistema desarrollo cumple con las descripciones del sistema por capas (cliente-servidor) por ello este es el estilo arquitectural a utilizar.

Sección 6. Puntos de Vista y Modelos Arquitecturales

Esta sección presenta los puntos de vista de la arquitectura del sistema. Comenzando por una breve descripción de la estrategia arquitectural.

1. En el siguiente diagrama, se explica claramente la estrategia arquitectural de nuestro proyecto, en la que se distinguen 3 capas: la capa web cliente, la capa web servidor, y la capa ejb. La capa cliente muestra la interfaz al servidor, el cual se encarga de conectar al cliente con los ejbs, los cuales contienen la lógica del negocio. El módulo ejb - remote, utiliza clases de tipo Request y Response, para enviar y recibir la información de la base de datos.

6.1 Punto de Vista Funcional

ILUSTRACIÓN 1

ILUSTRACIÓN 2

6.1.1 Modelo de Componentes

ILUSTRACIÓN 3

6.2 Punto de Vista de Despliegue

En esta sección se presenta el punto de vista de despliegue

6.2.1 Diagrama de Deployment