Universidad Simón Bolívar
Ingeniería de Software 2
Septiembre-Diciembre 2000
Arquitectura de Delta Pensum 1.x
Este documento presenta la arquitectura y decisiones clave de diseño
de Delta Pensum 1.0 y 1.1.
Arquitectura de tres capas
El software fue organizado en las tres capas típicas de un sistema
de información;
-
Capa de presentación o interfaz;
-
Capa del dominio de la aplicación;
-
Capa del repositorio.)
Se adopta la recomendación de Larman de incorporar
una clase controladora denominada Despachador que sirve de
fachada a la capa del dominio de la aplicación. Por ende la arquitectura
podría legítimamente considerarse de cuatro capas, donde
la capa de la aplicaciónse está centrada en esa clase Despachador.
Sin embargo, la simplicidad de la capa sugiere que es preferible considerarla
como un estrato dentro de la capa del dominio de la aplicación.
Para el resto de la discusión se supondrán sólo tres
capas y sería conveniente que la versión 2.x se pronuncie
explícitamente si adopta el modelo de cuatro capas.
La arquitectura fue concebida originalmente sólo para implantar
el escenario
I y el escenario III según Buschmann
et al. Es decir, preve que la capa superior (presentación) genera
solicitudes que se envían a la capa intermedia (del dominio de la
aplicación) y que esta capa inferior puede o cumplir con la tarea
solicitada o requerir generar solicitudes a la capa inferior (repositorio)
como parte de las tareas necesarias para cumplir con la solicitud original.
Esta arquitectura tropieza con el problema de los empates. Cuando
la capa de presentación solicita que se construya una recomendación
curricular, la capa del dominio de la aplicación generalmente no
puede cumplir con la solicitud sin asistencia del usuario. Ocasionalmente
la capa del dominio se encuentra incapaz de decidir cuál(es) asignaturas
o elementos genéricos debe agregar a la recomendación curricular,
por lo que requiere envíarle al usuario el conjunto de asignaturas
y elementos entre los que no se puede decidir (denominado el empate)
y esperar la decisión del usuario.
El problema de los empates se ha resuelto con una aplicación
del patrón Editorial-Suscriptor. De esta manera la solicitud de
construcción de la recomendación curricular incluye entre
sus parámetros el objeto de la clase de la presentación que
atiende los empates. Al presentarse un empate, el objeto de la capa intermedia
que detecta el empate sabe el suscriptor a quien debe dirigir la información
de empate.
El software debe evolucionar hacia una plataforma cliente-servidor,
pero la versión 1.x no muestra señales de ello.
Patrón Editorial-Subscriptor
Capa de presentación
No está documentada la capa de la presentación. Fundamentalmente
está basada en los componentes y filosofía Swing de JDK 1.2,
por lo que las clases que constituyen la capa heredan de las clases JFrame
y
JInternalFrame o implementan las interfaces ActionListener
y
ListSelectionListener.
[**]Está pendiente por averiguar cómo los grupos desarrolladores
obtienen del repositorio la información que requieren del repositorio,
tal como las abreviaciones de las asignaturas de un pensum y la agrupación
de estas asignaturas por período. Lógicamente deberían
solicitarle esta información a la clase que funge de Fachada a la
capa del dominio de la aplicación (Despachador).
Las funciones de las cuatro ventanas claves de la aplicación
son:
-
Presentar uno de los calendarios curriculares del pensum viejo y permitir
marcar sobre él los elementos a considerar como aprobados por el
pensum viejo;
-
Presentar uno de los calendarios del pensum nuevo, mostrando los elementos
aprobados por equivalencia con el pensum viejo, y permitir marcar sobre
él los elementos adicionales a considerar como aprobados por el
pensum nuevo;
-
Presentar los empates que se dan durante la construcción
de la Recomendación Curricular para que el usuario seleccione los
elementos que conforman el desempate.
-
Presentar la Recomendación Curricular.
Los nombres de estas cuatro ventanas son DP_oldPensum, DP_newPensum,
DP_desempatar y DP_recomendacion. Note que en Delta Pensum 1.x los
nombres de ventanas comienzan con el prefijo "DP_".
Cada una de estas ventanas se maneja como una forma a llenar
con un mínimo de campos en formato libre. Los campos de la forma
pueden llenarse y editarse en cualquier orden. El usuario es el responsable
de indicarle a la interfaz cuando ha terminado de llenar la forma a su
satisfacción. En ese momento, la interfaz envía una o más
solicitudes de servicio a la capa del dominio con los datos capturados
relevantes.
Capa del dominio de la aplicación
Esta capa contiene una instancia del patrón Fachada para maximizar
sus independencia de la capa de presentación. El objeto que hace
de fachada a la capa pertenece a una clase controlador (en el sentido
de Larman) denominado Despachador.
El desarrollo 1.x no identifica más estructura en esta capa que
la proporcionada por las clases que lo conforman. Sin embargo un estudio
más detallado de ellas, presenta al menos dos opciones estructurantes:
-
Una partición vertical (particiones en la terminología
de Larman) en paquetes.
-
Una partición horizontal en subcapas (estratos en la terminología
de Larman).
Conviene revisar el capítulo 22 del texto de Larman
en relación al tema de estructuración de la capa del dominio
de la aplicación.
Posible partición vertical en paquetes de la capa del dominio
En este caso, el paquete de conceptos claves de la capa incluye las clases
Despachador y Pensum. Los paquetes adicionales son:
-
Calendarios, que maneja lo relacionado con conceptos como Calendario Curricular
y Recomendación Curricular;
-
Encajables, que maneja las asignaturas, los bloques y los elementos genéricos.
-
Prelaciones, que maneja para cada pensum, las prelaciones entre sus asignaturas,
bloques y elementos genéricos.
-
Equivalencias, que maneja todo lo relacionado con las equivalencias entre
dos pensa de estudios.
-
Rastros, que maneja los conceptos que tienen que ver con los requerimientos
de seguridad (es decir lo relacionado con rastros auditables).
Originalmente se había concebido separar en un paquete aparte lo
relacionado con la oferta de las asignaturas, pero lo relacionado con oferta
terminó implementándose tan estrechamente con los encajables,
que no queda más remedio que ubicarlo en el paquete Encajables.
Posible partición horizontal de la capa del dominio
Un estudio de los paquetes identificados previamente sugiere una división
de la capa del subdominio en cuatro estratos, nuevamente bajo el modelo
del escenario I y III de Buschmann et al:
-
Estrato de la aplicación.
Previamente había presentado un modelo de cuatro capas, donde
una de las capas era la de aplicación. En Delta Pensum 1.x, esta
capa es muy simple, por lo que considero que una solución mucho
más satisfactoria es considerarla como un estrato en la capa del
dominio.
-
Estrato de Pensa;
-
Estrato de Componentes Estructurados de Pensa, incluye los paquetes Prelaciones,
Calendarios y Equivalencias;
-
Estrato de Componentes Básicos de Pensa, particionado entre el paquete
Encajables y el paquete Rastros.
A grosso modo los últimos tres estratos tienen las siguientes
funciones:
-
El estrato de los Pensa ayuda a identificar qué debe ser cursado
y si un cursable aprobado cuenta o no para graduarse;
-
El estrato de los Componentes Estructurados de Pensa ayuda a identificar
y manejar las restricciones sobre cuándo puede ser cursado lo cursable;
-
El estrato de Componentes Básicos de Pensa identifica qué
es cursable, sus características, cuáles de los cursables
está aprobado y maneja lo relativo a la noción de rastro
auditable.
Decisiones claves
Las siguientes decisiones son importantes y se encuentran explicadas en
las páginas web a que enlazan:
-
Calendarios
-
Pensum
-
otros paquetes....
Capa del repositorio
La capa del repositorio se basa en datos guardados en archivos planos,
con un formato estilo XML. Para manejar la lectura de esta capa se recurre
a Claire, un software desarrollado en proyectos de grado de la Universidad
Simón Bolívar, bajo la dirección del Prof. Ascánder
Suárez. La versión actual sólo lee del repositorio
ya que, a diferencia de la versión 0.1, no salva nada de lo que
construye (la versión 0.1 salvaba el estado del estudiante, tanto
en el pensum nuevo como en el viejo). La organización de esta capa
es temporal y está prevista su revisión en una futura versión.
Para ello se desea introducir el patrón Fachada para aislar los
futuros cambios de esta capa de las otras dos.
En la clase pasada mencioné que convenía estudiar cómo
acoplar la capa del dominio a la capa del repositorio.
Según Fowler, la forma obvia en que objetos de la capa del dominio
pueden hacer uso de la capa del repositorio es que las clases del dominio
incluyan rutinas capaces de extraer la data necesaria de la base de datos
para construirse. Es importante que todo esto sea transparente a la aplicación
(la aplicación pide un objeto, el dominio ve si ya existe en memoria
y si no le piede que se construya --la aplicación no sabe qué
está sucediendo).
Esta forma obvia no funciona tan bien si la aplicación necesita
una configuración específica sobre la cual trabajar y esta
configuración se puede armar en un paso al inicio de la aplicación
(esto probablemente sea más eficiente --y más agradable para
el usuario que espera que la aplicación cargue una sola vez). Este
es exactamente el caso de Delta Pensum 1.x, donde la construcción
de los pensa es disparada directamente por lo que podríamos considerar
el objeto que conforma la capa de la aplicación.
Estas dos formas de acoplar el dominio con el repositorio puede resultar
demasiado pesado para los objetos del dominio que terminan encapsulando
el procedimiento de recuperación de la base de datos --esto se exacerba
si hay que recurrir a varias bases de datos.
La solución puede ser incluir una fachada a la capa del repositorio.
Observe que esta fachada es, en cierto modo, inversa a la fachada aplicación:
la aplicación recibe solicitudes de una capa (Presentación)
que maneja tipos simples y los convierte en solicitudes a objetos de clases
más complejas, mientras que la fachada de la base de datos recibe
solicitudes sobre objetos complejos y los convierte en solicitudes a tipos
más simples (tablas).
Fowler
(sección 12.4, vp. 252-253) sugiere que cada clase del dominio tiene
un "espejo" en la capa de interfaz al repositorio (la clase X tiene una
clase interfazDeXaBD) pero que si un objeto x de la clase X quiere salvarse
o recuperarse de la BD hace lo siguiente:
-
Envía un mensaje salvame(x) o cargame(x) a un
Corredor (patrón Broker) que hace de fachada.
-
Este corredor le pregunta al objeto x a qué clase pertenece
y en base a eso, decide qué objetos tipo interfazDeXaBD necesita
consultar.
Confieso que encuentro la sugerencia demasiado compleja. Yo propondría
la aplicación del patrón Estrategia, qué separa un
algoritmo (como cargar o salvar) del objeto que lo requiere. La clase InterfazDeXaBD
corresponde a una estrategia de X., que puede entonces cambiarse incluso
dinámicamente de acuerdo con la disponibilidad de diferentes fuentes
de datos. La solución es más eficiente que la propuesta por
Fowler, pero deben estudiarse dos aspectos:
-
Cómo garantizar que las operaciones comunes a la BD sean hechas
(por ej. ¿cómo garantizamos que la BD fue "inicializada"
es decir, conctada y una sesión abierta en ella?). Con la propuesta
del Corredor es más fácil lograrlo [se me ocurre que cada
BD puede tener su controlador/fachada].
-
El manejo de restricciones de integridad [en principio lo veo más
fácil en mi modelo, para que la BD y el dominio satisfagan las mismas
restricciones, pero habría que estudiarlo].
Queda pendiente revisar 1.x a la luz de esta discusión para decidir
qué hacer al respecto en 2.x/
El patrón Estrategia (Gamma)
Otros factores de una arquitectura de capas
En un documento previo se mencionaron varios
factores que afectan una arquitectura top-down de capas . Estos factores
han sido tomados en cuenta en la arquitectura de Delta Pensum 1.x, salvo
el último:
-
Diseñe la estrategia de manejo de errores.
Esta estrategia nunca fue diseñada. Como hipótesis de trabajo
puede suponerse que el objeto que detecta un error trata de corregirlo
o soslayarlo. Si no logra ninguna de las dos acciones, puede avisarle a
su invocador, mediante un valor de retorno o puede lanzarle una excepción.
El hecho que no se diseñó explicitamente una estrategia
de esta índole no significa que el manejo de errores no esté
documentado.
Los
contratos documentan las precondiciones exigidas por los eventos al
sistema (es decir por los mensajes que envían los objetos de la
capa de la presentación a objetos de la capa del dominio de la aplicación)
y las excepciones que se pueden producir si no se cumplen.
En los diagramas de colaboración producidos por
la empresa Injavakus se extiende la notación para incluir la posibilidad
de documentar el lanzamiento de excepciones (raise nombreExcepción)
y su manejo. [**Esta notación hay que revisarla y explicitarla]
Esta página fue creada por el Prof. Alejandro Teruel
el 19 de septiembre de 2000.
Ultima actualización: 21 de septiembre de 2000.