UNIVERSIDAD CENTROCCIDENTAL

LISANDRO ALVARADO

ARQUITECTURA DE SOFTWARE PARA AUTOMATIZAR LOS

REGISTROS ACADEMICOS EN LA UNIVERSIDAD
CENTROCCIDENTAL LISANDRO ALVARADO

RAMON ANTONIO VALERA ARANGUREN

Barquisimeto, 2010

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO

DECANATO DE CIENCIAS Y TECNOLOGIA
DEPARTAMENTO DE SISTEMAS

ARQUITECTURA DE SOFTWARE PARA AUTOMATIZAR LOS

REGISTROS ACADEMICOS EN LA UNIVERSIDAD CENTROCCIDENTAL

LISANDRO ALVARADO

Trabajo Presentado Como Requisito Para Optar a la

Categora de Agregado en el Escalafn del Personal Docente
y de Investigacin

RAMON ANTONIO VALERA ARANGUREN

Barquisimeto, 2010

INDICE GENERAL

RESUMEN ....................................................................................................................... 4
INTRODUCCION ........................................................................................................... 6
METODOLOGIA DE TRABAJO ............................................................................... 9
DESCRIPCIN DEL PROBLEMA ...........................................................................12
BASES TEORICAS .......................................................................................................16
Arquitectura de Software .................................................................................16
Patrn de Software ............................................................................................20
Clasificacin de los Patrones ............................................................................22
Lenguaje de Patrones ........................................................................................23
Lenguaje de Patrones para Aplicaciones Empresariales .............................24

DESARROLLO DE LA PROPUESTA ......................................................................28

Requisitos Funcionales ......................................................................................28
Requisitos no Funcionales.................................................................................37
Lista de Funcionalidades ..................................................................................38
Modelo de Requisitos.........................................................................................40
Propuesta de Arquitectura de Software .........................................................44

CONCLUSIONES ..........................................................................................................53
REFERENCIAS BIBLIOGRAFICA ..........................................................................55

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO

DECANATO DE CIENCIAS Y TECNOLOGIA
DEPARTAMENTO DE SISTEMAS

ARQUITECTURA DE SOFTWARE PARA AUTOMATIZAR LOS

REGISTROS ACADEMICOS EN LA UNIVERSIDAD CENTROCCIDENTAL

LISANDRO ALVARADO

Autor(a): Ramn Antonio Valera Aranguren

RESUMEN
El uso de tcnicas de Ingeniera de software en la construccin de proyectos de

Software de amplio impacto, garantiza la calidad del mismo y su fcil adaptacin para
la incorporacin nuevas funcionalidades y modificaciones menores, en este contexto la
Arquitectura de Software es preponderante en las primeras etapas de desarrollo del
sistema, pues ofrece una visin general y abstracta del sistema a desarrollar, una
descripcin a muy alto nivel de su estructura y control global, los protocolos de
comunicacin y sincronizacin utilizados, la distribucin fsica del sistema y sus
componentes, la arquitectura puede ser enriquecida por un conjunto de patrones que
supervisen la composicin de sus componentes y las restricciones de comunicacin
entre ellos. Estas tcnicas de construccin de software pueden ser de gran valor
cuando se aplican a procesos dinmicos y cambiantes como por ejemplo

los

relacionados a la gestin acadmica de una Universidad, en este caso, el presente

trabajo se centra a generar una arquitectura de software que permita automatizar y
estandarizar los procesos en las Unidades de Control de Estudio de de cada uno de
los Decanatos que conforman la UCLA de manera incremental e iterativa, soportado
en documentos agiles y usando patrones, como un paso previo a resolver los

problemas de interoperabilidad y coordinacin

que existen entre las diversas

dependencias de la Universidad.
Palabras Claves: Arquitectura de Software, Lenguaje de Patrones, Patrn de
Software.

INTRODUCCION

Los modelos de desarrollo de software organizan el conjunto de actividades

necesarias para obtener productos de software de calidad, se centran en definir un
proceso de desarrollo racional y controlable, pero de ninguna manera existe un modelo
de desarrollo universal y nico, existen mltiples variantes, y una u otra son ms o
menos efectivas en el contexto donde se empleen. Los modelos de desarrollo
representan una gua de cmo y en qu orden deben realizarse cada una de estas
actividades, y establecen el marco del ciclo de vida del software.

La propuesta arquitectural de software es un resultado esperado en cualquier

modelo de desarrollo moderno, destinado a dar una visin general del sistema en

etapas tempranas a diseadores y desarrolladores, para tomar decisiones firmes y

minimizadas en riesgo, en cuanto a la determinacin de responsabilidades, divisin de
esfuerzo dentro del equipo de trabajo, organizacin de la aplicacin, puntos de

coordinacin, despliegue de aplicacin, entre otros. XP es una metodologa gil muy

empleada y efectiva, puesto que propone un equipo de trabajo horizontal dinamizado
por la comunicacin y la interaccin continua entre desarrolladores y usuarios finales
de la aplicacin. Establece un conjunto de actividades que de manera incremental e

iterativa permite construir productos de software, entre ellos la arquitectura de

software.

Para el presente trabajo se recurre primordialmente a un modelo de desarrollo

gil, para que de manera sistematizada y rpida se pueda atacar una situacin de
problema en el rea de gestin acadmica en la Universidad Centroccidental Lisandro
Alvarado (UCLA).

La UCLA est constituida por Decanatos, los cuales son rganos administrativos

y acadmicos a travs de los cuales, la Universidad realiza sus funciones de docencia,

investigacin y extensin. Para que en los Decanato se puedan llevar a cabo estas
actividades, se requiere de la administracin de recursos tanto fsicos (aulas,

laboratorios, equipos, etc.), humanos (profesores, auxiliares docente, personal

administrativo, obreros) como de tiempo. As mismo dentro de la UCLA existe la
Secretara General, que es la Unidad Administrativa responsable de:

Recibir, procesar y emitir informacin relacionada a la gestin universitaria,

tanto dentro como fuera de la UCLA.

Para lograr este objetivo se apoya en una estructura organizativa, en la que

convergen diversas direcciones y unidades, estas son:
Direccin Docente.

Direccin de Admisin y Control de Estudios.

Archivo General.

Unidad de Patrimonio.
Es indispensable para la secretaria general lograr que la informacin que maneja

fluya de la manera ms rpida posible hacia las distintas unidades y direcciones, ya que
este es un insumo indispensable para la toma de decisiones en la estructura gerencial
de la UCLA.
La Direccin de Admisin y Control de Estudios (DACE) es la encargada de

planificar, coordinar y controlar todos los procesos relativos a admisin, registro,

informacin y graduaciones del estudiantado, as como tambin, es responsable de

velar por el cumplimiento de reglamentos, normas y disposiciones relacionadas a los
programas de estudio que se desarrollan en los distintos decanatos de la UCLA.

La DACE lleva a cabo sus actividades con el apoyo de cada unidad de Registro
Acadmico

presente en cada Decanato de la UCLA. La DACE se encarga de

7

gestionar el ingreso y egreso de estudiantes a cada programa que imparte la

universidad y la unidad Registro Acadmico se encarga, segn lo especifica la
resolucin N 051-2004 del Consejo Universitario, de efectuar el seguimiento

acadmico de toda la poblacin estudiantil en el Decanato donde tiene jurisdiccin, as

mismo, es la responsable del control y custodia de expedientes de estudiantes, as
como los trmites referidos a: inscripciones, retiros, cancelaciones, inclusiones y
constancias.
La fuerte dependencia entre la DACE y cada unidad de registro acadmico hace

necesario un flujo constante de informacin, para ello en la actualidad, la informacin

se encuentra en aplicaciones locales en cada Decanato y son integrados por distintas
vas en una aplicacin del DACE, este proceso de integracin se realiza en lotes, por

lo que el repositorio de datos de la DACE nunca refleja la situacin actual de los

procesos acadmicos que se llevan a cabo los decanatos.

En fin existen un conjunto de problemas relacionados a la coordinacin de los

diversos procesos de gestin acadmica que llevan en conjunto la DACE y los

diversos Registros Acadmicos de la UCLA, este problema tiene que ver con

aspectos tecnolgicos, integracin de datos y procesos, seguridad, auditoria y

elementos organizacionales. En este contexto el siguiente trabajo expone una
propuesta arquitectural de software como solucin a toda esta problemtica, tomando
como base un conjunto de necesidades descubiertas en un proceso de levantamiento
de informacin sustentado en el manifiesto gil, y empleando estrategias y tcnicas de
Ingeniera de Software.

METODOLOGIA DE TRABAJO

Como lo refiere Beck(2000), eXtreme Programming (XP) es una metodologa

gil para equipos de desarrollo de software pequeos y medianos, diseada para

responder rpidamente a los cambios y lograr entregas de software, continuas, rpidas

y de valor. Esta metodologa es ideal para direccionar los esfuerzos necesarios en la
intencin de generar una arquitectura de solucin para el problema de Registro

Acadmico y Control de Estudio en UCLA, pues con pasos firmes y concisos se

pueden lograr entregas de valor para avanzar en la consecucin de los objetivos

planteados, XP establece un ciclo de vida para el proyecto de software de seis fases:
Exploracin, Planificacin de la Entrega de una Versin, Iteraciones, Produccin,
Mantenimiento y Muerte del Proyecto. (Ver Figura 1)

Figura 1. El proceso de desarrollo XP

Fuente: Beck (2000).

Exploracin
Esta fase tiene como objetivo realizar un anlisis de las necesidades en el cliente.
Para el caso particular de este trabajo se recurre a la tcnica JAD, que mediante un
trabajo grupal entre especialistas de dominio, diseadores y clientes finales, permite
capturar las necesidades de los usuarios y en consecuencia enumerar las historias de
usuario. Cada una de estas debe ser analizada para de tal manera que se establezca un
estimado del esfuerzo requerido para convertirla en un componente de software.
Planificacin
La fase de planificacin incluye organizar el conjunto de funcionalidades

recogidas en la fase de exploracin en la forma de un plan de trabajo que muestra la

prioridad y el tiempo estimado de culminacin de cada funcionalidad, esto se hace en

conjunto con el cliente, esto sirve de insumo para que el gerente de proyecto asignado
por la empresa y el cliente, entienda el avance del proyecto. El plan de proyecto
muestra el conjunto de iteraciones necesarias para construir el software y contiene los
puntos de liberacin de las versiones del software producido, para que el cliente final
vaya comprobando y validando los avances obtenidos.
Iteracin
Cada iteracin representa un proceso de construccin en la que cada miembro del
equipo desarrollador elabora los artefactos de software asignados. Dentro de las
iteraciones de desarrollo se producen adems de los componentes de software la
siguiente documentacin:

Arquitectura de la Aplicacin.
Lenguaje de Patrones (Buenas Prcticas que regulan el comportamiento de los
componentes de la arquitectura).

Modelo de Dominio. (Conceptos Involucrados en el Desarrollo)

10

De acuerdo al plan de proyecto, se puede liberar versiones del cdigo ejecutable

del sistema para que sea probado y validado por el usuario final.
Mantenimiento
La fase de mantenimiento incluye las actividades de soporte para que bajo los
parmetros acordados en el contrato de servicio se le de continuidad a los artefactos
de software validados y verificados por el cliente final.
Fin del Proyecto
Se llega a esta etapa cuando el cliente no tiene ms historias para ser incluidas en
el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos
como rendimiento y confiabilidad del sistema. Se genera la documentacin final del
sistema y no se realizan ms cambios en la arquitectura.

11

DESCRIPCIN DEL PROBLEMA

Para conocer en detalle la problemtica actual relacionada al funcionamiento de

las Unidades de Registro acadmico y su interaccin con DACE, se realizaron diversas

actividades de reconocimiento y levantamiento de informacin soportado por la
tcnica Joint Application Development (JAD), Yatco (1999) indica que tiene como
objetivo central facilitar la cooperacin entre usuarios y analistas durante el desarrollo
de sistemas. Los analistas de sistemas y los representantes funcionales realizan
reuniones de trabajo con los usuarios directos para discutir las caractersticas de los
sistemas objeto de estudio y, sobre la marcha de las mismas discusiones, se van
trazando los modelos que permitirn definir los requerimientos funcionales de esos
sistemas.

Las sesiones de JAD son de dos tipos: de adiestramiento y de trabajo. A su vez,

las sesiones de trabajo se cumplen, normalmente como lo muestra la Figura 2, en tres
etapas: revisin, formalizacin y validacin.
En cada sesin de trabajo, a medida que van discutindose diferentes aspectos del
sistema objeto de estudio, se van elaborando modelos de procesos y datos en
borrador, haciendo uso de un pizarrn o de rotafolios, con el fin de que los
participantes puedan confirmar, al equipo de desarrollo, si los modelos representan
razonablemente bien los puntos por ellos expuestos

12

Figura 2. Etapas de la Tcnica Joint Application Development (JAD)

Fuente: Beck (2000).

Las sesiones JAD realizadas con el personal de diversos Registros Acadmicos en

la UCLA arrojaron las siguientes conclusiones:

Las aplicaciones de los registros acadmicos estn desarrolladas en ambientes

tecnolgicos diversos y no compatibles, es comn ver trabajando en algunos
sitios, equipos y aplicaciones de tecnologa obsoleta, esto hace difcil los
procesos de control, auditoria e integracin, as mismo,

no es posible

garantizar la integridad y coherencia de los datos depositados en ellos.

La mayora de las aplicaciones instaladas en los Registros Acadmicos de la

UCLA, fueron desarrolladas por el mismo personal de la unidad, esto se hizo
sin ningn tipo de documentacin, con lo cual su funcionamiento y
operatividad esta directamente ligada al personal que lo desarrollo, esto es

13

inconveniente desde el punto de vista operativo, pues la ausencia del personal

ocasionara retrasos en la ejecucin de los procesos.

Existen problemas en los Registros Acadmicos de la UCLA que marcan el

desempeo de los procesos acadmicos de los Decanato y que estn muy

relacionados al uso e implementacin de tecnologas de informacin, entre
ellos podemos citar:
o Informacin no oportuna a las unidades responsables externas a las
Oficina de Registro Acadmico de cada Decanato, el acceso a los
sistema de informacin de cada Registro Acadmico est limitado solo

al personal de la unidad, si la informacin estuviera al alcance de los

Directores de Programa, Jefes de Departamento y Profesores, la toma
de decisiones en los procesos acadmicos se realizara de una forma
ms expedita.
o Falta de Integridad y consistencia de los datos, este inconveniente est
relacionado al uso de una infraestructura de base de datos obsoleta o al
modelaje incorrecto de los datos en la Base de Datos.
o No hay procesos estandarizados ni definidos, la ausencia de
documentacin acerca del desarrollo de los procesos acadmicos es
evidente, es comn ver distintas interpretaciones del reglamento

general de evaluacin en los distintos decanatos de la UCLA, as

mismo se presentan procesos cuyo desarrollo se realiza sin algn
procedimiento estandarizado.
o Discrecionalidad del personal tcnico en el manejo de los procesos de la

unidad, la ausencia de polticas que regulen el uso y desarrollo de las

tecnologas de informacin y comunicacin en la UCLA, as como la

ausencia en la estandarizacin de los procesos acadmicos, facilita al

personal tcnico que desarrolla las aplicaciones en la unidades de

Registro Acadmico, discrecionalidad en el manejo e implementacin

de los procesos en sus sistemas, son evidentes las diferencias en las

14

interpretaciones acerca del desarrollo de los procesos en los distintos

decanatos.
o Ausencia de mecanismos de auditora, supervisin y control, en el
desarrollo de los procesos acadmicos, de los cuales es responsable la
unidad de Registro Acadmico.
o Ausencia de polticas de seguridad y respaldo para los datos de la
unidad de Registro Acadmico.
o Dada la dependencia que tiene la DACE de la informacin que maneja

las unidades de Registro Acadmico, la ausencia de polticas en

aspectos claves como la seguridad, auditoria, control y respaldos, as
como la discrecionalidad del personal tcnico para el desarrollo de los
procesos, afecta la confiabilidad y fiabilidad de los datos que le son
enviados.

Se comprob igualmente que los datos producidos en los procesos de gestin

acadmica ejecutados en los Registros Acadmicos de los Decanatos y en la DACE,

son consumidos o requeridos por otras dependencias estas son:

Planificacin Universitaria.
Desarrollo Estudiantil.

Direccin de Deportes.

Direccin de Biblioteca.

Direccin de Cultura.

Vicerectorado Administrativo.

15

BASES TEORICAS

A continuacin se presentan un conjunto de conceptos y definiciones relativos al

rea de Ingeniera de Software, con la idea de construir un marco conceptual que

apoye el desarrollo del presente trabajo, en este sentido se comenzar por entender el
uso y ventaja de la Arquitectura de Software y como esta se puede representar usando
el lenguaje de modelado UML, luego se introducir los conceptos, clasificacin y
utilidad de los patrones y la forma en que pueden encadenarse formando Lenguajes de
Patrones, estos lenguajes de patrones a su vez pueden marcar la distribucin y
comportamiento de los componentes de la arquitectura desarrollada en un proyecto de
construccin de software, para reusar practicas exitosas de diseo y con ello
garantizar la calidad del software.

Arquitectura de Software

Se puede comenzar con la definicin de Clements (1998) donde describe que la

Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los
componentes principales del mismo, la conducta de esos componentes segn se la
percibe desde el resto del sistema y las formas en que los componentes interactan y se
coordinan para alcanzar la misin del sistema. Esta definicin permite entender a la

Arquitectura de Software como la descripcin de un sistema macro, basndose en los

componentes o elementos que la integran y como estos se relacionan e interactan
entre s, es una visin general del sistema con un alto nivel de abstraccin que le
permite al ingeniero visualizar a la solucin general al problema.

16

Otra de las definiciones de la Arquitectura de Software, es la realizada por Bass

(1998) en la cual este autor se refiere a ella como la estructura a grandes rasgos del
sistema, estructura consistente en componentes y relaciones entre ellos. Esta
estructura se vincula con el diseo, pues la Arquitectura de Software es despus de
todo una forma de diseo de software que se manifiesta tempranamente en el proceso

de creacin de un sistema; pero este diseo ocurre a un nivel ms abstracto que el de

los algoritmos y las estructuras de datos. En el que muchos consideran un ensayo
seminal de la disciplina, Garlan y Shaw (1994), sugieren que dicha estructura incluye
una organizacin a grandes rasgos y control global; protocolos para la comunicacin,

la sincronizacin y el acceso a datos; la asignacin de funcionalidad a elementos del

diseo; la distribucin fsica; la composicin de los elementos de diseo; escalabilidad

y rendimiento; y la seleccin entre alternativas de diseo, es por ello que representa un

diseo ajustable o cambiante hasta que proporcione la mejor solucin del problema, y
una visin general del sistema antes de que este sea desarrollado.

Garlan (2000), establece en una definicin tal vez bastante amplia que la
Arquitectura de Software constituye un puente entre el requerimiento y el cdigo,
ocupando el lugar que en los grficos antiguos se reservaba para el diseo. La
definicin oficial de Arquitectura de Software proporcionada por IEEE (2000),

adoptada tambin por Microsoft, dice as: La Arquitectura de Software es la

organizacin fundamental de un sistema encarnada en sus componentes, las relaciones

entre ellos y el ambiente y los principios que orientan su diseo y evolucin.

En conclusin, se puede observar que todas las definiciones de la Arquitectura de

Software radican en que es una estructura del sistema, representada o descrita a travs
de sus componentes y como estos se relacionan entre s.

Para representar una arquitectura de software existen distintos enfoque y

perspectiva, en todas es comn la presencia de mltiples diagramas y vistas para

representar las distintas perspectivas del sistema a desarrollar, al anlisis de todos en

17

conjunto permite al equipo de desarrollo una visin holstica del sistema que

representa, estos a su vez sirven de medio de comunicacin entre los miembros del
equipo y como un elemento comn para discusin y toma de decisiones.

Existen unos cuantos organismos de estndares (ISO, CEN, IEEE, OMG) que
han codificado diferentes aspectos de la Arquitectura de Software, con el objetivo de
homogeneizar la terminologa, los modelos y los procedimientos. Como producto de
este trabajo se han construido marcos de trabajo que reconocen entre tres y seis vistas
diferentes del sistema.

Uno de los marcos para representar arquitectura mas empleado es el llamado

modelo 4+1, vinculado al Rational Unified Process (RUP), que segn Kruchten
(1995) define cuatro vistas diferentes de la arquitectura de software: (1) La vista
lgica, que comprende las abstracciones fundamentales del sistema a partir del
dominio de problemas. (2) La vista de proceso: el conjunto de procesos de ejecucin
independiente a partir de las abstracciones anteriores. (3) La vista fsica: un mapeado

del software sobre el hardware. (4) La vista de desarrollo: la organizacin esttica de

mdulos en el entorno de desarrollo. El quinto elemento considera todos los anteriores

en el contexto de casos de uso. Lo que acadmicamente se define como Arquitectura
de Software concierne a las dos primeras vistas. El modelo 4+1 se percibe hoy como
un intento se reformular una arquitectura estructural y descriptiva en trminos de
objeto y de UML.

Otro marco de trabajo para representar arquitectura construido sobre la base de

UML y confeccionado para usarse en el desarrollo de software de gran escala, es el
propuesto por Garland(2003), aqu se propone el uso de tres vistas, una encargada de
mostrar los aspectos conceptuales y de anlisis de la aplicacin, otra dedicada a la
representacin del diseo lgico y una tercera responsable del ambiente de
funcionamiento y despliegue, en las Tabla 1 se puede apreciar los entregables y
componentes en trminos de diagramas de cada una de ellas.

18

Despliegue

Contexto y

Diseo Lgico

Conceptual y Anlisis

Nombre

Diagrama UML

Centrado en el Anlisis

Clases

Anlisis de Interaccin

Interaccin

Anlisis General

Clases

Contexto

Casos de Uso

Componentes

Componente

Interaccin de
Componentes

Interaccin

Estado de Componentes

Estado/Actividad

Capas de Subsistemas

Paquetes

Datos Lgicos

Clases

Interfaces de
Dependencia entre
Subsistemas

Clases

Despliegue

Despliegue

Datos Fsicos

Despliegue

Procesos

Despliegue

Estado de Procesos

Estado

Descripcin

Describe las entidades del Sistema en

respuesta a un escenario,
frecuentemente se refiere a una vista
de las clases participantes
Diagrama de Interaccin entre objetos
del anlisis
Combinacin de todas las clases
detectadas en las distintas vistas que se
centran al anlisis de un escenario en
particular.
Muestra los sistemas externos, actores
y el propio sistema bajo diseo
Ilustra la comunicacin entre los
diversos componentes
Muestra la Interaccin entre los
diversos componentes
Diagrama de Estado u/o actividad de
un componente o conjunto de
componentes.
Ilustra las capas y los subsistemas.
Muestra una vista de los datos crticos
sensibles para la integracin.
Muestra la dependencia de los
subsistemas y sus diversas interfaces.
Mapea el software y su ubicacin en
los distintos dispositivos de hardware.
Vista fsica de una base de datos en
particular.
Muestra los procesos de una instancia
particular de sistema.
Muestra los estados dinmicos de un
procesos

Tabla 1. Vistas de una Arquitectura de Software.

Fuente: El Autor.

Para efectos de este trabajo se utilizara este segundo mtodo de representacin de

arquitectura, pues muestra de una forma intuitiva y concreta al equipo de trabajo los
componentes estructurales de la aplicacin; Garland(2003) afirma que desde sus
comienzos fue concebida como una forma gil de representar arquitectura, exponiendo

19

que el arquitecto puede hacer uso de aquellos artefactos que verdaderamente

presenten informacin til al equipo de diseadores.

Patrn de Software

En el sentido ms general, un patrn es un modelo a seguir que describe una

solucin exitosa de un problema particular en un contexto dado.

Zambrano y Acosta (2001) se refieren a un patrn desde el punto de vista

informtico, como una descripcin de una solucin computacional exitosa a un

problema recurrente en un contexto particular; esta solucin expresa la experiencia y

el conocimiento de expertos y, en este sentido, sirve como medio de comunicacin
para difundir este conocimiento.
Un patrn soluciona un problema recurrente, ya que si el problema es poco o

nada frecuente, entonces pudiera no tener sentido construir un patrn de su solucin,

el cual no se utilizar ms. De all que, una de las ventajas de los patrones es fomentar
y facilitar el reso, en este caso, de soluciones.
Los patrones facilitan la reutilizacin de diseos y arquitecturas de software que

han tenido xito, adems capturan la experiencia y la hacen accesible a los no

expertos, se pueden agrupar y el conjunto de sus nombres forma un vocabulario que

ayuda a que los desarrolladores se comuniquen mejor. Ayudan a los desarrolladores a
comprender un sistema ms rpidamente cuando est documentado con los patrones

que usa. Facilitan la reestructuracin de un sistema tanto si fue o no concebido con

patrones en mente. Pavn (2004)

20

Los patrones segn Buschmann (1996) le ayudan a construir sobre la

experiencia colectiva de ingenieros de software experimentados. Estos capturan la
experiencia existente y que ha demostrado ser exitosa en el desarrollo de software, y
ayudan a promover las buenas prcticas de diseo. Cada patrn aborda un problema
especfico y recurrente en el diseo o implementacin de un sistema de software.
Para que un patrn sea efectivo debe segn Buschmann (1996):

Resolver un problema: Los patrones capturan soluciones, no principios o

estrategias abstractas.

Ser concepto probado: Capturan soluciones, no teoras o especulaciones.

Describir una relacin: Los patrones no describen mdulos sino estructuras y

mecanismos.

Poseer un componente humano significante: El software sirve a las

personas. Los mejores patrones aplican a la esttica y a las utilidades.

21

Clasificacin de los Patrones

Buschmann (1996), define una taxonoma para los patrones, el cual los rene en

tres grandes grupos, estos en cada grupo varan respecto a su nivel de detalle y
abstraccin esto se puede ver en la Figura 3:

Figura 3. Patrones segn el nivel de detalle, adaptado de POSA.

Fuente: Microsoft(2004)

Patrones de Arquitectura Arquitecturales

Estos expresan un paradigma fundamental para estructurar un sistema software y
proporcionan un conjunto de subsistemas predefinidos, que especifica sus
responsabilidades, e incluye reglas y guas para organizar las relaciones entre ellos.

Algunos ejemplos: Tuberas y filtros, Cliente/Servidor, Maestro-Esclavo, Control

centralizado y distribuido
Patrones de diseo

22

Los patrones de diseo, estn compuestos de varias unidades arquitecturales ms

pequeas y describen el esquema bsico para estructurar subsistemas y componentes

resolviendo un diseo general dentro de un contexto particular. Como por ejemplo:
Proxies, Factoras, Adaptadores, Composicin, Broker.
Patrones elementales (idiomas)
Un patrn de idiomas, es un patrn de bajo nivel, especfico a un lenguaje de

programacin. Un patrn de idiomas describe cmo llevar a cabo aspectos particulares

de componentes o las relaciones entre ellos, usando las caractersticas de lenguaje de
programacin utilizado.

Por ejemplo: Modularidad, Interfaces mnimas,

Encapsulacin, Objetos, Acciones y Eventos, Concurrencia.

Lenguaje de Patrones

Los patrones se pueden agrupar formando colecciones que constituyen un

vocabulario para comprender y comunicar ideas. Cuando estas colecciones se
conforman con habilidad para formar un todo cohesionado que revele las estructuras y
las relaciones de sus componentes para cumplir un objetivo compartido, entonces se
esta hablando de lo que Alexander (1977) en el urbanismo bautiza como lenguaje de
patrones. Un lenguaje de patrones define una coleccin de patrones, reglas y pautas
para combinarlos con un estilo que se podra denominar arquitectnico, pues define

una forma de construir estructuras a todos los niveles de escala y en todos los grados
de diversidad. En realidad, un lenguaje de patrones se compone de un lxico de

patrones y una gramtica que establece cmo unirlos para formar estructuras
sintcticas. Idealmente, los buenos lenguajes de patrones son generativos, es decir,

23

capaces de generar todas las posibles frases a partir de un vocabulario de patrones rico
y expresivo.

Lenguaje de Patrones para Aplicaciones Empresariales

Fowler(2003) hace una recopilacin muy completa de un conjunto de patrones de

Arquitectura y Diseo que pueden emplearse en la construccin de aplicaciones

empresariales, estos se pueden enlazar de manera coherente en la forma de lenguaje
de patrones, para que el arquitecto establezca un contrato de comportamiento para los
componentes de la Arquitectura y la forma en que se comunican.

Para el desarrollo del presente trabajo el autor selecciono un conjunto de patrones

de esta coleccin y la agrupo para generar un esquema de funcionamiento que puede

aplicarse a cualquier aplicacin empresarial, incluyendo la abordada en el presente

trabajo, esto puede verificarse en la Figura 4.

24

Figura 4. Lenguaje de Patrones para Aplicaciones Empresariales.

Fuente: El Autor.

En este sentido se puede decir que una aplicacin debe estar marcada por una

divisin en capaz, estas son:

Presentacin. Ofrece los servicios necesarios para la presentacin de

informacin.

Lgica del Negocio. Encapsula la lgica relacionada a la situacin del mundo

real que modela la aplicacin.

Fuente de Datos. Proporciona la comunicacin con Bases de Datos, Sistemas

de Mensajera, Archivos XML y Otros Sistemas.

La transferencia de los datos entre las Capas de la Aplicacin se har usando el

patrn Data Transfer Object.

25

La Capa de Lgica de Negocio estar dividida en una Capa construida bajo el

Patrn Service Layer y otra que usa el patrn Domain Model, as mismo se desarrollo
una capa entre ambas direccionada por el patrn Data Access Object.

En la Capa de fuente de Datos se empleara el Patrn Data Mapper (Data Mapper).

La Capa de Presentacin usa los servicios proporcionados por la Lgica de

Negocio enviando mensajes a la implementacin de Service Layer. En la Capa de

Presentacin se emplean los siguientes patrones:

Composite View.
Application Controller.
Two Step View.
Template View.
View Helper.
Transform View.
Front Controller.

Con miras a garantizar que la Lgica del Negocio pueda reusarse desde otros

nodos u aplicaciones, se incorporara el patrn Remote Facade, esto es particularmente

importante ahora que se piensa en una plataforma interoperable para que la lgica de
negocio de la aplicacin sea reusada por otras aplicaciones.

Hay patrones complementarios que servirn para direccionar el diseo de la Capa

Lgica de Negocio, estos son:

Gateway Layer
Supertype.

Separated Interface.
Service Stub

26

27

DESARROLLO DE LA PROPUESTA

Los problemas detectados en las sesiones JAD realizadas en conjunto con el

personal responsable de los distintos Registros Acadmicos de la UCLA y un trabajo
de anlisis documental sobre software para control de estudio y registro acadmico
disponible en el mercado, permitieron establecer los requerimientos funcionales y no
funcionales del sistema que requiere UCLA para mejorar su desempeo en los
procesos de gestin acadmica y docente actuales, esto como un paso previo a la
construccin de la arquitectura que soportara el software con el que se puede dar una
solucin automatizada a la situacin.

Requisitos Funcionales

La UCLA est constituida por Decanatos, los cuales son rganos administrativos

y acadmicos a travs de los cuales, la Universidad realiza sus funciones de docencia,

investigacin y extensin. Para que en los Decanato se puedan llevar a cabo estas
actividades, se requiere de la administracin de recursos tanto fsicos (aulas,

laboratorios, equipos, etc.), humanos (profesores, auxiliares docente, personal

administrativo, obreros) como de tiempo. Es importante acotar que tanto a Nivel
universitario como a nivel de cada Decanato existe un marco legal que controla el
desarrollo de las actividades acadmicas, docentes y de investigacin. (Ver Figura 5)

28

Figura 5. Esquema Universidad, Decanatos y Marco Legal.

Fuente: El Autor.

Los Decanatos a su vez estn conformados por Programas, Departamentos y

dems dependencias de carcter acadmico y administrativo. Las labores docentes de

cada Decanato, sern realizadas a travs de los Programas que la integran. Por su

especial naturaleza a cada Programa le corresponde ensear e investigar un grupo de

disciplinas fundamentales y afines, dentro de una rama de la ciencia y la cultura.
El ingreso de los estudiantes a UCLA es controlado por la Direccin de Admisin
y Control de Estudio y es la primera instancia que se visita para que cualquier persona
interesada en cursar algunos de los programas acadmicos aperture su expediente, en
este proceso se recoge un grupo de informacin de gran importancia e inters para
otras direcciones de la Universidad, para corporando respectivamente informacin
personal, datos socioeconmicos, entre otros.
Este grupo de disciplinas conforman lo que se llama Plan de Estudios y es el que
debe ser cursado y aprobado por un estudiante, para as cumplir con los requisitos

acadmicos y obtener el ttulo conferido por dicha carrera universitaria. A su vez el

plan de estudios es dictado durante un lapso acadmico, que viene a ser el perodo

29

educativo cuya duracin puede ser semestral, anual o de 5 semanas para un perodo

Extraordinario o Intensivo. Existen decanatos cuya duracin es mixta, por lo que

manejan tanto el rgimen semestral como anual. Asimismo, en algunos decanatos

puede haber varios planes de estudios abiertos a la vez. (Ver Figura 6)

Cualquiera que sea el caso, semestral, anual o mixto, se realizan una serie de
actividades o procesos que pueden ser agrupados por etapas, estas son: Planificacin,
Ejecucin y Finalizacin. Por lo tanto el funcionamiento del Sistema de Gestin
Acadmica CUM LAUDE, girar en torno al desarrollo de un Lapso Acadmico.

Figura 6. Esquema sobre Universidad, Decanatos y Reglamentos.

Fuente: El Autor.

La planificacin de un lapso acadmico se inicia con la Creacin del Lapso

Acadmico, en donde se definir el lapso acadmico, el tipo de lapso y la fecha de

inicio del mismo.

Dependiendo del tipo de lapso seleccionado, se generarn las

actividades que se llevarn a cabo durante el mismo. Una vez definido el Lapso

30

Acadmico, se puede consultar como queda estructurado el Calendario Acadmico

con todas sus actividades, tales como: el inicio de clases, inclusin y retiro de
asignatura, cancelacin de semestre, inscripcin a la prueba extraordinaria,

presentacin de prueba extraordinaria, finalizacin de semestre, as como cualquier

otra actividad que sea aprobada por el Consejo de Decanato. El sistema permitir
realizar la Reprogramacin de un Lapso Acadmico previa aprobacin de Consejo de
Decanato y Consejo Universitario. Con est informacin se establece el Calendario
Acadmico para un Lapso determinado.

Otro de los procesos que se lleva a cabo en esta etapa es la Creacin de la Oferta

Acadmica, esta opcin permitir establecer el nmero de secciones que se ofertarn

en el lapso acadmico que est por iniciar, as como tambin permitir realizar

consultas sobre la oferta acadmica realizada en los lapsos anteriores, lo que ayudar

al usuario en la toma de decisiones para el lapso que va a iniciar. En esta opcin el

usuario podr estimar el nmero de secciones que se van abrir para el lapso
acadmico, una vez que haya sido aprobada la Oferta Acadmica.

Una vez aprobada la oferta acadmica, se llevar acabo el proceso de

Administracin de Secciones, esta opcin permitir al usuario actualizar y distribuir las

asignaturas por seccin para un Plan de Estudios

en un Lapso Acadmico

determinado.
En esta etapa del sistema se llevar a cabo la asignacin de la Carga Acadmica

del Docente para el Lapso Acadmico que est por iniciar.

La Configuracin de Horarios consiste en distribuir las asignaturas ofertadas por

secciones, en un da y hora determinada junto con los recursos necesarios de acuerdo

a la naturaleza de la asignatura, estos pueden ser fsicos, humanos y de tiempo.

31

Otra de las actividades que se ejecutan en esta etapa de Planificacin es la

Configuracin de Grupos de Inscripcin, Esta opcin permite crear los grupos a los
que le sern asignados los criterios de inscripcin, a cada grupo se le establece la
fecha, hora de inicio y finalizacin que le corresponde para la inscripcin, una vez que

se han definido los grupos, se realiza el Manejo de Grupos de Inscripcin a travs del
cual se le cambia el estatus a cada uno de los grupos de inscripcin, es decir en espera,
inscribiendo o cerrado.
Una vez culminada la etapa de planificacin, el sistema da inicio a una nueva

etapa, la cual llamaremos Etapa de Ejecucin. En esta etapa encontramos el proceso

Inscribir Alumnos que permitir a un estudiante registrar la carga acadmica que le

corresponde para ese lapso acadmico de acuerdo al plan de estudios que este
asociado a l.

Concluido el proceso de inscripcin e iniciada las clases, comienzan otros

procesos, entre los que se encuentra la Inclusin y Retiro de Asignaturas, los cuales
permitirn modificar la carga acadmica de un estudiante, ya sea agregando una nueva
asignatura a su carga acadmica o eliminando alguna de las asignaturas ya inscritas.

El estudiante tambin podr realizar la Cancelacin de Matrcula que no es ms

que anular su carga acadmica para el lapso que se encuentra activo.

Otro de los procesos que se lleva a cabo durante la etapa Ejecucin es el Cambio
de Secciones, se puede realizar de dos formas, el cambio mutuo de secciones, que
consiste en realizar el cambio de mutuo acuerdo entre los estudiantes en la misma
asignatura pero en secciones diferentes, o cambiar al estudiante a otra seccin pero
con la misma asignatura, este proceso se llevar a cabo previa autorizacin.

El sistema tambin permitir llevar a cabo el registro de los estudiantes para

presentar las Pruebas Extraordinarias, en aquellas asignaturas que hayan inscrito

32

previamente o Cursar asignatura bajo Rgimen Especial, en ambos procesos se

facilitar el envo de la informacin requerida a los departamentos correspondientes y

el registro de las calificaciones obtenidas por los estudiantes.
De igual manera, en esta etapa encontramos la opcin Actividades de

Coordinacin de Asignaturas, en la cual se planificarn y registrarn las actividades

que llevarn a cabo los docentes durante el lapso acadmico, tales como la realizacin
de evaluaciones, registro de las calificaciones para cada parcial, entrega de proyectos,
entre otras.

A medida que se vayan cumpliendo las actividades

de evaluacin a los

estudiantes, el docente tendr la oportunidad de registrar las calificaciones obtenidas

de las evaluaciones realizadas, esto se har en base a la planificacin definida por la
Coordinacin de Asignatura, el proceso se llevar a cabo a travs de la opcin de
Trascribir Calificaciones por Seccin. Igualmente el docente podr Modificar la Nota
Final de un estudiante en una asignatura una vez concluido el lapso acadmico.
Tambin a travs del sistema se podr verificar aquellos estudiantes que realicen

solicitud de reingreso, el sistema emitir informacin acerca de si le corresponde o no

al estudiante reingresar para su activacin en el prximo lapso acadmico.

Una vez concluidas las actividades planificadas en el Calendario Acadmico se

procede a dar inicio a la etapa de finalizacin, en la que se encuentra el proceso Cierre

de Lapso, que a su vez est conformado por una serie de actividades, entre las que
tenemos Generar Boletines. Una vez cerrado el proceso de Transcribir Calificaciones
por Seccin, se pueden generar los boletines ya sea en lote o individual, los boletines
contendrn la actuacin acadmica del estudiante de acuerdo a la carga acadmica que
curso en el lapso.

33

Una vez que se ejecuta el Cierre de Lapso se realiza la Emisin de Boletines, que

consistir en mostrar la informacin acadmica de cada estudiante, su ndice

acadmico, prioridad de inscripcin, asignaturas que puede cursar el prximo lapso
acadmico y mostrar informacin en caso de que no este solvente por Biblioteca o

Librera Rental, la informacin podr ser consultada a travs de Internet o enviada

va web a los correos de los estudiantes o imprimiendo el boletn.

Al finalizar el proceso de Generar Boletines, el sistema producir los listados de:

Posibles estudiantes que sern sancionados por RR o RP en el prximo lapso

acadmico.

Los estudiantes que fueron sancionados por RR o RP para el prximo lapso

acadmico.

Los estudiantes que solicitaron reingreso para el prximo lapso acadmico

luego de cumplir sancin por RR o RP.

Una vez concluidos los procesos de la etapa de Finalizacin, se iniciarn una serie

de actividades que se llevan a cabo entre la etapa de finalizacin y la etapa de inicio del
nuevo lapso acadmico, esta etapa la llamaremos Inter-Lapso.

Durante esta etapa se realiza la Apelacin por parte del estudiante ante la

Comisin Sustanciadora. Una vez que el estudiante ha sido sancionado por RR o RP,
puede recurrir ante la Comisin Sustanciadora para que le sea suspendida la sancin.

El sistema permitir registrar la solicitud de apelacin de la sancin y el veredicto que

se emita, asimismo se podr consultar el nmero de apelaciones realizadas por el

estudiante y las respuestas emitidas por la Comisin.

Otro de los procesos que se realizan en la etapa de Inter-Lapso es la

Preinscripcin de los estudiantes para el prximo Lapso Acadmico, ya sea para un
lapso normal o intensivo, esto permitir conocer la demanda que tendrn las
asignaturas, en el perodo acadmico a iniciar.
34

El Sistema de Informacin para la Gestin Acadmica CUM LAUDE, adems de

realizar el conjunto de procesos expuestos anteriormente, podr llevar a cabo una serie

de actividades que estarn disponibles para ser ejecutados cuando sea requerido por el
usuario. Entre estas actividades se encuentra Generar Plan de Estudios que consiste
en registrar los nuevos planes de estudios que son aprobados para un programa de un
Decanato, all se registrarn las asignaturas que conformarn el nuevo plan de
estudios, el cdigo de la asignatura, el semestre o ao al que corresponde, la densidad
horaria, las unidades de crdito y las prelaciones.

Del mismo modo, el sistema permitir registrar las Equivalencias, estas pueden
ser: Equivalencias Internas o Externas, este proceso consiste en registrar el veredicto
que otorga el Consejo Universitario de la UCLA, previa revisin y anlisis de los entes
correspondiente, en este veredicto se indican las asignaturas que le fueron aprobadas
al solicitante.
Equivalencias entre Planes de Estudios o Cambio de Pensum, est se da cuando
en un mismo programa hay varios planes de estudios abiertos y se quiere realizar el
proceso de transicin de un plan de estudios a otro, ya sea porque se va a cerrar uno
de los planes de estudios o porque el estudiante decide realizar la transicin al nuevo
plan de estudios.
El sistema ofrecer una serie de servicios los cuales pueden ser solicitados en

cualquier momento de la ejecucin del lapso acadmico, alguno de los servicio

ofrecidos son: Constancias de Estudios, inscripcin, de Notas, historial, de

culminacin de carrera, de solicitud de anteproyecto del trabajo especial de grado, de
buena conducta, retiro definitivo, de estar incurso en el articulo 35 literal (a) o (b),
Carta de culminacin, entre otras. Tambin emitir estadsticas: Alumnos inscritos
(matrcula), regulares y repitientes por asignatura, rendimiento acadmico por lapso,

35

lista de carga acadmica, inscritos por semestre, matrcula por edad y sexo, entre
otras.
Otra de las opciones que puede realizarse, es la Admisin de los estudiantes

Nuevo Ingreso, est se ejecutar desde la Direccin de Admisin y Control de

Estudios de la UCLA, el estudiante deber estar preinscrito previamente por medio de

la pgina Web de la UCLA. En la opcin de Admisin, se completarn los datos del

estudiante que ha sido aceptado para ingresar a cursar alguno de los programas
dictados en la Universidad y se registrarn los documentos que fueron consignados al
momento de su admisin.
El sistema tambin permitir llevar un Registro de los Recursos Fsicos y

Humanos que sern necesarios durante la Configuracin de Horarios. Se registrar la

capacidad, caractersticas y descripcin de los recursos fsicos y se podr consultar la

disponibilidad de los mismos durante un lapso acadmico. Del personal se registrar

sus datos bsicos y laborales as como poder consultar su disponibilidad durante un

lapso acadmico.
Asimismo, el sistema manejar la opcin Gestin Estudiante que permitir
actualizar y consultar los datos del estudiante, realizar el Retiro Definitivo de un
estudiante de la Universidad, cancelando las asignaturas que se encontraba cursando
para el momento de la solicitud y retirndolo del programa para el que estaba inscrito.

Tambin se podrn Registrar las Equivalencias de aquellos estudiantes que ingresen

bajo esta modalidad, primero es registrado como un estudiante nuevo ingreso y previo
a la generacin de su carga acadmica, se registran las asignaturas que fueron
aprobadas por la Comisin de Equivalencia. Si el estudiante incurre en alguna falta,

de acuerdo a las establecidas en los Reglamentos de la UCLA, se registrar por

sistema la Sancin Disciplinaria aplicada al estudiante, el tipo de falta y la sancin que

deber cumplir el estudiante.

36

Se podr realizar la Configuracin de los Decanatos esta opcin permite al

usuario registrar las Autoridades de un Decanato, tales como: Decano, Directores de
Programa, Jefes de Departamento, y Coordinadores existentes. El sistema ofrecer un
asistente de configuracin, que le facilitar al usuario llevar a cabo el registro de la
informacin.

Requisitos no Funcionales

El anlisis de necesidades recogidas en los diversos registros acadmicos de la

UCLA, arrojo que existe una variedad de dinmicas de trabajo entre los distintos
decanatos, incluyendo importantes diferencias en interpretacin del reglamento,
organizacin de los procesos de inscripcin, inclusin y retiro de asignatura,

transcripcin de notas parciales y finales, entre otros, as mismo existen diversos

perfiles de usuarios, con variadas expectativas de informacin. Todos estos elementos
condicionan las caractersticas no funcionales del software que se requiere, en este
sentido el software debe sugiere que este sea primordialmente:

Mantenible, Para que pueda adaptarse fcilmente y en el menor tiempo posible

Confiable, Dada lo critico y sensible de la informacin que maneja es

a la dinmica que cada decanato maneja.

importante ofrecer al usuario la sensacin de que se est manejando procesos

confiables en funcionamiento y coherencia.

Usable, Dada la gran cantidad de usuario que podr utilizarlo es necesario que

su filosofa de trabajo tanto para los administradores como para usuarios

finales sea de fcil aprendizaje y manejo.

Interoperable, La universidad incluye polos de trabajo relacionados a la gestin

administrativa a los que debe integrarse el sistema, de manera rpida y sencilla.

37

Lista de Funcionalidades

Mediante un proceso de inspeccin de los requisitos podemos establecer la

siguiente lista de funcionalidades. (Ver Tabla 2)

Nombre de la Funcionalidad

Gestin de Lapso Acadmico.

Definir Tipos de Lapso Acadmico.

Definir Lapso Acadmico y Calendario Acadmico Correspondiente.

Definicin de Oferta Acadmica.

Estimar Oferta Acadmica (Indicadores, Proyeccin del Lapso anterior,

cantidad y capacidad de las secciones, tomar en cuenta la cantidad de
grupos que tendr la seccin y su capacidad).

Aprobar Oferta Acadmica.

Conformacin de Secciones.

Crear o cerrar secciones (se realizar despus de aprobada la oferta

acadmica, durante el proceso de inscripcin o inclusin).
Asignacin Carga Acadmica Docente.
Configuracin Horarios para los Recursos Fsicos y Humanos.

Aprobar horarios.
Configuracin de Proceso de Inscripcin.

Grupos de Inscripcin.

Criterios de Inscripcin.
Inscripcin de Estudiante. Casos: Nuevo Ingreso, Regulares, Intensivos.

Parmetros: Reglamentos Generales, Criterios de Prosecucin,

Solvencia de Biblioteca.

Validaciones: Chequeo de horarios, Carga Mxima.

Disponibilidad de la seccin.

Censo de la demanda no satisfecha.

Inclusin y Retiro de Asignatura.

Excepciones: Cuando la solicitud se efecta fuera de lo planificado.

Cancelacin de Matrcula.

Excepciones: Cuando la solicitud se efecta fuera de lo planificado.

Retiro Definitivo de Estudiante.
Servicios (Constancias, Solvencias, Records Acadmicos).
Transcripcin Notas por Seccin.

Registrar resultados de evaluaciones planificadas.

Generar cortes parciales (estadsticas).

Finalizar proceso de trascripcin.

Manejo de trascripciones sin cortes parciales.

Correccin de Nota Final.
Gestin de Prueba Extraordinaria y Otro Rgimen.

Registrar Solicitud.

Transcripcin de Calificacin (Resultado del Rgimen podr afectar el

Record Acadmico).
Tesis de Grado.
Pasantas.
Trabajo Comunitario.
Solicitud de Reingreso/Reincorporacin.
Actividades de Coordinacin de Asignaturas.

Definir Coordinaciones.

Planificar Actividades (Evaluaciones).

Registrar Calificacin por Coordinacin.

Definir Escala de Evaluacin.

38

Usuario Responsable
Director de Programa

Director de Programa

Director de Programa
Jefe de Departamento
Director de Programas/ Jefes de
Departamentos
Administrador del Sistema

Estudiante y / o Registro Acadmico

Estudiante y / o Registro Acadmico

Registro Acadmico
Registro Acadmico
Estudiante, Profesor, Registro Acadmico

Profesor

Profesor
Jefe de Departamento, Registro Acadmico
Registro Acadmico
Registro Acadmico
Registro Acadmico
Registro Acadmico / Estudiante
Jefe de Departamento / Coordinador de
Area

Cierre de Lapso Acadmico.

Generar Boletines.

Generar Listado de Estudiantes que reingresan por RR o RP.

Asignar Prioridades de Inscripcin.

Generar posibles Sanciones RR y RP.

Generara Sancionados RR y RP.

Estadsticas.
Comisin Sustanciadora.

Registrar Apelaciones.

Registrar Veredicto de Apelacin.

Preinscripcin Lapso Acadmico.
Gestin de Estudiantes.

Ficha del Estudiante.

Retiro Definitivo.

Registrar Equivalencias del Estudiante.

Sanciones.
o
Acadmicas.
o
Disciplinarias.
Gestin de Recursos.

Recursos Fsicos

Espacio Fsico

Recursos

Asignacin de un Recurso a un Espacio Fsico.

Gestin Docente.

Ficha Docente.

Contrataciones.

Ascensos.

Cambios de Dedicacin.

Planificacin de Actividades.
Gestin de Programas.

Definir Plan de Estudios.

Asignaturas.

Equivalencias entre Planes de Estudios.

o
Equivalencias Internas.
o
Cambio de Pensum.
o
Equivalencias Externas.
Configuracin Decanatos.

Departamentos.

Autoridades.
Apertura de Expediente Estudiante
Proceso de Ingreso a la Universidad

Administrador del Sistema

Registro Acadmico
Estudiante
Registro Acadmico

Administrador del Sistema / Registro

Acadmico

Administrador del Sistema/Docente

Director de Programa / Registro Acadmico

Administrador del Sistema

Direccin de Admisin y Control de
Estudio
Direccin de Admisin y Control de
Estudio

Tabla 2. Funcionalidades Software de Control de Estudio y Registro Acadmico.

Fuente: El Autor.

39

Modelo de Requisitos

A continuacin se presenta un conjunto de diagramas de actores y casos de uso,

mostrando los requisitos relacionados al sistema de Control de Estudio y Registro
Acadmico necesitado en UCLA. (Ver Figuras 7,8,9,10 y 11)

Estudiante

Registro Academico

Director de Programa

Jefe Departamento

Administrador del Sistema

Direccin de Admisin y Control de Estudio

Profesor

Coordinador de Area

Desarrollo Estudiantil

Figura 7. Diagrama de Actores

Fuente: El Autor.

Gestionar Prueba Extraordinaria

Planificar Actividades de Evaluacin

Gestionar Coordinaciones de Area

Jefe Departamento

Asignar Carga Academica

Coordinador de Area

Configurar Horario Recurso Fisico : 2

Figura 8. Diagrama de Casos de Uso

Fuente: El Autor.

40

Solicitar Documento : 2

Corregi r Cali ficaci n Fi nal

Profesor
Transcri bi r Cali ficaci ones de Asignatura

Confi gurar Seccion

Configurar Horario Recurso Fisico : 1

Director de Programa
Gesti onar Program a : 2

Definir Oferta Academica

Gesti onar Lapso Academi co

Figura 9. Diagrama de Casos de Uso

Fuente: El Autor.

41

Solicitar Documento : 2

Corregi r Cali ficaci n Fi nal

Profesor
Transcri bi r Cali ficaci ones de Asignatura

Confi gurar Seccion

Configurar Horario Recurso Fisico : 1

Director de Programa
Gesti onar Program a : 2

Definir Oferta Academica

Gesti onar Lapso Academi co

Figura 10. Diagrama de Casos de Uso

Fuente: El Autor.

42

Solicitar Documento : 1

Gestionar Estudiante

Procesar Retiro Definitivo

Gestionar T rabajo de Grado

Gestionar Recurso Fisico

Gestionar Pasantia

Gestionar T rabajo Comunitario

Registro Academico

Gestionar Programa : 1

Cambiar Seccion a Estudiante

Gestionar Reingreso y Reincorporacin

Cancelar Matricula

Gestionar Comisin Sustanciadora

Gestionar Inscripcin y Retiro de Asignatura

Gestionar Inscripcin

Figura 11. Diagrama de Casos de Uso

Fuente: El Autor.

43

Propuesta de Arquitectura de Software

Para definir la arquitectura de software correspondiente al sistema de Control de

Estudio y Registro Acadmico en UCLA, se emplearan algunas de las vistas propuesta
por Garland(2003), en especifico aquellas que para este caso de estudio resulten de
valor y relevancia para alcanzar los objetivos propuestos.
En este caso el autor se propone a dar una visin general de cmo el sistema est

ubicado dentro de la organizacin y con qu dependencias o actores trabaja, debe

darse prioridad a la incorporacin de patrones de diseo que direccionen un desarrollo
orientado a servicios para garantizar su interoperabilidad y acceso a la informacin.

Es indispensable

igualmente dar un panorama de todos los componentes que

conformaran el sistema, como ellos se conectan y se despliegan en la infraestructura de

hardware, con el fin de:

Establecer la divisin de responsabilidades y roles dentro del equipo.

Marcar puntos de discusin acerca de la pertinencia desde el punto de vista

arquitectnico de la ubicacin fsica de los componentes de software.

Establecer los equipos y la infraestructura de red necesaria para el desarrollo e

implementacin de la solucin de software.

Desde el punto de vista conceptual se considerara representar una visin de las

entidades y conceptos involucrados en el dominio del problema, como un insumo que
pueda completarse en futuras iteraciones del proceso de desarrollo.

A partir de este momento el autor se referir al software de Control de Estudio y

Registros Academico como CUM LAUDE, con el fin de darle vida al proyecto que

44

servir para dinamizar la toma de decisiones en el rea acadmica y docente en la

UCLA.

La Figura 12 muestra un diagrama de contexto para entender que actores,

entidades y sistemas externos, interactuaran con el sistema CUM LAUDE.

Administrador del Sistema

Registro Academico
Jefe Departamento

Coordinador de Area

Estudiante

Director de Programa

Direccin de Admisin y Control de Estudio

Sistema para Registro

Academico y Control de
Estudio en la Universidad
Centroccidental "Lisandro
Alvarado"

Profesor

Direccin de Deporte

Desarrollo Estudiantil
Direccin de Biblioteca

Planificacin Universitaria Vicerrectorado Administrativo

Direccin de Cultura

Figura 12. Diagrama de Contexto Sistema CUM LAUDE

Fuente: El Autor.
Sobre la base del anlisis de los distintos casos de uso y funcionalidades

presentados anteriormente en relacin a CUM LAUDE, se puede indicar que el

45

software debe estar formado por dos componentes fundamentales, esto se puede
evidenciar en la Figura 13.

CUM LAUDE - Registro Academico Decanato

CUM LAUDE - DACE

Figura 13. Diagrama de Componentes Sistema CUM LAUDE

Fuente: El Autor.

Estos componentes se desplegaran en forma de distribuida en dos localidades

distintas, uno en la propia Direccin de Admisin y Control de Estudio y otro en cada
uno de los decanatos que conforman la UCLA. (Ver Figura 14).

Registro Academico - Decanato

Direccin de Admisin y Control de Estudio

CumLaude - Registro Academico

CumLaude - DACE

Figura 14. Diagrama de Despliegue - Sistema CUM LAUDE

Fuente: El Autor.

Esta arquitectura distribuida estar formada por:

Un Componente que residir en los Registros Acadmicos de cada uno de los

Decanato de la UCLA, capaz para gestionar los procesos acadmicos que se
llevan a cabo en esa localidad, empleando polticas de seguridad, auditoria,

respaldo y tolerancia a fallos, de tal manera que se garantice la exactitud y

46

correctitud de los datos que sern consumidos posteriormente por DACE. As

mismo debe ser lo suficientemente configurable para adaptarse a las
necesidades particulares de cada decanato y administrar estudiantes, docentes,
programas acadmicos y recursos administrativos.

Un componente de software que residir en la DACE que se encargara de

consolidar la informacin producida en los distintos decanatos, usando para
ellos mecanismos abiertos y estandarizados de intercambio de datos. El sistema
de informacin debe estar en capacidad de dar informacin de un estudiante
desde su ingreso hasta la culminacin de su plan de estudios, entregando la
informacin pertinente a las diferentes unidades y la requerida para la
Acreditacin y Auto Evaluacin de la UCLA.

La Figura 15 muestra un diseo ms detallado de la arquitectura propuesta para

CUM LAUDE, all se puede evidenciar que componentes integran los dos grandes
elementos de la aplicacin.

47

CUM LAUDE - DACE

Gestionar Plan de Estudio

CUM LAUDE - Registro Academico Decanato

Gestionar Coordinacion de Area

Gestionar Profesor

Gestionar Recursos Fisicos

Gestionar Proceso de Ingreso

Gestionar Decanato y Programas
Gestionar Oferta Academica

Gestionar Estudiante

Gestionar Lapso Academico

Gestionar Matricula

Gestionar Pasantias

Gestionar T rabajo de Grado

Gestionar Proceso de Evaluacin

Figura 15. Diagrama de Componentes Detallado - Sistema CUM LAUDE

Fuente: El Autor.

48

Gestionar T rabajo Comunitario

Con la idea de proporcionar una idea de cmo en trminos de Clases y Objetos se

va a manejar la implementacin de cada uno de los componentes de la arquitectura, se

har referencia a lo que propone el Lenguaje de Patrones expuesto en las Bases
Tericas, este adems de direccionar la organizacin y comunicacin de las clases de
cualquier componente en el sistema, incorpora buenas prcticas aplicadas al desarrollo
de aplicaciones empresariales. La Figura 16 muestra como se sugiere abordar el
desarrollo de cada componente en la arquitectura.

Figura 16. Esquema de Implementacin - Componente Sistema CUM LAUDE

Fuente: El Autor.

Como se puede observar la arquitectura desarrollada presenta un disposicin por

capaz, esto implica que la comunicacin entre ellas se hacen al estilo de llamadaretorno, as las capas superiores usan los servicios proporcionadas por las inferiores,
49

en este caso existe una transferencia de datos en ambos sentidos, es decir entre la capa
que solicita y la que procesa, para ello es muy importante estandarizar la
comunicacin, empleando significados compartidos, all es donde el modelo de
dominio se convierte en una herramienta eficaz, puesto que muestra las entidades que
forman el dominio de problema y sus relaciones. En la Figura 17 se puede ver un
extracto del modelo de dominio construido para CUM LAUDE.

tipocargaacadem ica
tipoprograma
+
+
+
+

idtipoprogram a
nom bre
descripcion
estado

:
:
:
:

+
+
+
+
+

int4
java.lang.String
java.lang.String
java.lang.String

idtipocargaacadem ica
nom bre
descripcion
regla
estado

:
:
:
:
:

int4
java.lang.String
java.lang.String
java.lang.String
java.lang.String

1..1

1..1
0..*
0..*

planestudio
program a
+
+
+
+
+
+
+

0..1

0..*

idprogram a
nom bre
nom brecorto
abreviacion
descripcion
fechainiciodirector
estado

:
:
:
:
:
:
:

int4
java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.util.Date
java.lang.String

1..1
0..*

autoridad
+
+
+
+

idautoridad
fechainicio
fechafin
estado

:
:
:
:

0..*

int4
java.util.Date
java.util.Date
java.lang.String

1..1

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

idplanestudio
fechavigencia
num erom emorando
num eroperiodos
descripcion
cargam inim a
cargam axim a
nom brebean
estatus
m inim anota
tieneelectivas
tieneautodesarrollo
cargaacadem icatotal
m inim anotaextraordinaria
estado
nom bre

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

escalaevaluacion
int4
java.util.Date
java.lang.String
int4
java.lang.String
int4
int4
java.lang.String
java.lang.String
float4
java.lang.String
java.lang.String
int4
float4
java.lang.String
java.lang.String

0..*
1..1

0..*

0..1

+
+
+
+
+
+
+
+

iddecanato
nom bre
nom brecorto
direccion
telefono
param etros
logo
estado

:
:
:
:
:
:
:
:

int4
java.lang.String
java.lang.String
java.lang.String
java.lang.String
bytea
bytea
java.lang.String

cargoautoridad

1..1

+
+
+
+

idcargoautoridad
nom bre
descripcion
estado

:
:
:
:

int4
java.lang.String
java.lang.String
java.lang.String

idescalaevaluacion
descripcion
valorm inim o
valorm axim o
estado

:
:
:
:
:

int4
java.lang.String
int4
int4
java.lang.String

0..*
1..1
tiporegim en
+
+
+
+

1..1

decanato
0..*

+
+
+
+
+

idtiporegim en
nom bre
descripcion
estado

:
:
:
:

int4
java.lang.String
java.lang.String
java.lang.String

0..*
1..1
periodo

asignaturaperiodo
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

codigoasignatura
valorcargaacadem ica
posicion
naturaleza
grupoelectiva
horaspracticas
horasteoricas
horasteoricopracticas
tipocalificacion
valorcargaprereq
grupoautodesarrollo
extraordinaria
estado
densidadhoraria
nrocreditos
grupostp

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

int4
int4
int4
java.lang.String
java.lang.String
int4
int4
int4
java.lang.String
int4
java.lang.String
java.lang.String
java.lang.String
int4
int4
java.lang.String

+ num ero : int4

+ estado : java.lang.String

0..*

1..1
0..*

Figura 17. Extracto del Modelo de Dominio - Sistema CUM LAUDE

Fuente: El Autor.

Como se puede ver la lgica de negocio de la aplicacin no est acoplada a la

presentacin, esto trae como beneficio que puede exponerse a otras aplicaciones para

que pueda usarse con tecnologas estandarizadas y abiertas como los Web Service, si
estas prcticas de diseo se extendieran al desarrollo de aplicaciones de la UCLA se
50

pudiera generar un ambiente de interoperabilidad, en la bsqueda del reso de lgicas

de negocio disponible en otras aplicaciones, as como tambin lograr integracin de
datos, esto puede verse en la Figura 18.

Figura 18. Esquema de Integracin en UCLA

Fuente: El Autor.
Se sugiere al momento de desarrollar la aplicacin, trabajar en la procura de
componentes estandarizados que renan el comn denominador de las distintas

variantes de procesos acadmicos llevados a cabo en los diversos Decanatos de la

UCLA, de tal manera que al llegar el momento de su implementacin en la localidad

correspondiente pueda adaptarse con facilidad y rapidez. (Ver Figura 19).

51

Figura 19. Esquema de Integracin en UCLA

Fuente: El Autor.

52

CONCLUSIONES

Desde el punto de vista funcional CUM LAUDE, presenta una arquitectura que
permitir a cada uno de los decanatos:

Distribuir automticamente la informacin requerida por cada una de los

departamentos, unidades o cualquier ente que la requiera en cada Decanato.

Facilitar mediante el uso de informacin la toma de decisiones responsable,

Proveer informacin de calidad: precisa, confiable, detallada, oportuna,

fundamentada, gil, acertada y oportuna.

accesible, integrada y segura.

Optimizacin de los procesos y procedimientos de gestin acadmica y

docente a travs de la estandarizacin, agilizacin, integracin y depuracin de
los mismos.

CUM LAUDE como software de gestin acadmica nico permitir la

estandarizacin de los procesos y del flujo de informacin entre los Registros

Acadmicos y la Direccin de Admisin y Control de Estudios para mejorar el servicio
prestado a la comunidad universitaria.
Dado que la Direccin de Admisin y Control de Estudios necesita de

informacin acerca del desenvolvimiento de los Registros Acadmicos, CUM LAUDE

establece una plataforma tecnolgica que facilitar la obtencin de informacin

oportuna, eliminando las barreras de incompatibilidad en el formato y de
estructuracin de los datos.

53

Se presento una arquitectura de software que permite un desarrollo de

mantenible, soportado por experiencias exitosas de diseo, esto garantiza calidad en el
producto final y permite al equipo desarrollador desenvolverse de manera eficaz en un
dominio de problema muy dinmico, cifrado por necesidades muy cambiantes.
La implementacin de esta arquitectura de solucin permitir sentar las bases

para construir dentro de la UCLA software interoperable que rompera con los
problemas de consistencia de datos e integracin.
El proceso de diseo de la arquitectura se sustento sobre un proceso gil para

generar documentacin de valor que pueda ser contundente para resolver los
problemas asociados a los procesos de control de estudio y registro acadmico.

54

REFERENCIAS BIBLIOGRAFICA

Beck, K. & Fowler, M. (2000). Planning Extreme Programming. Addison Wesley.

Yatco, M. (1999). Joint Application Design/Development. University of Missouri-St.
Louis. [Internet] <http://www.umsl.edu/~sauterv/analysis/JAD.html>
Bass, Clements y Kazman. (1998). Software Architecture in Practice. AddisonWesley.
Clements, P. (1996). A Survey of Architecture Description Languages. International
Workshop on Software Specification and Design, Alemania.
David Garlan. (2000). Software Architecture: A Roadmap. ACM Press.
Garlan, D. y Shaw, M. (1994). An introduction to software architecture. CMU
Software Engineering Institute Technical Report.
Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software.
Garland, J. y Richard, A. (2005). Large Scale Software Architecture. Wiley & Sons.
IEEE 1471-2000 (2000) [Internet] <http://www.techstreet.com/cgibin/detail?product_id=879737
Zambrano, N & Acosta, A. (2001). Patrones en Interaccin Humano-Computador:
Fundamentos Tericos. Caracas. Venezuela. Universidad Central de Venezuela.
Facultad de Ciencias. Escuela de Computacin.
Buschmann, F. (1996). Pattern Oriented Software Architecture, Volume 1: A System
of Patterns. Willey & Sons.
Christopher ,A. (1977). A pattern language. Oxford University Press.
Fowler, M. (2003). Pattern of Enterprise Application Architecture. Addison Wesley.
2003

55