Desarrollo de un Sistema Informático para la Administración de Expedientes de la Universidad José Carlos Mariátegui (página 3)

Son diagramas de interacción, muestran un conjunto
de objetos y sus relaciones, así como los mensajes que se intercambian
entre ellos. Cubren la vista dinámica del sistema. El diagrama
de secuencia resalta la ordenación temporal de los mensajes,
mientras que el de colaboración resalta la organización
estructural de los objetos, ambos siendo equivalentes o isomorfos. En
el diagrama de colaboración de la figura de la izquierda, se
puede ver que los elementos gráficos no son cajas rectangulares,
como cabría esperar, y en su lugar encontramos sus versiones
adornadas. Estas versiones tienen como finalidad evidenciar un rol específico
del objeto siendo modelado. En la figura encontramos de izquierda a
derecha y de arriba abajo un Actor, una Interfaz, un Control.

Colaboración

Fig. II. 2.18 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.4. Diagramas de Estados

Muestran una maquina de estados compuesta por estados, transiciones,
eventos y actividades. Estos diagramas cubren la vista dinámica de un
sistema y son muy importantes a la hora de modelar el comportamiento de una
interfaz, clase o colaboración.

Fig. II. 2.19 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.5. Diagramas de Actividades

Son un tipo especial de diagramas de estados que se centra en mostrar
el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren
la parte dinámica de un sistema y se utilizan para modelar el funcionamiento
de un sistema resaltando el flujo de control entre objetos.

Fig. II. 2.20 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.6. Diagramas de Componentes

Muestra la organización y las dependencias entre un conjunto de
componentes. Cubren la vista de la implementación estática y se
relacionan con los diagramas de clases ya que en un componente suele tener una
o más clases, interfaces o colaboraciones

Fig. II. 2.21 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.5.7. Diagramas de Despliegue

Representan la configuración de los nodos de procesamiento en
tiempo de ejecución y los componentes que residen en ellos. Muestran
la vista de despliegue estática de una arquitectura y se relacionan con
los componentes ya que, por lo común, los nodos contienen uno o más
componentes.

Fig. II. 2.22 Fuente: http://es.wikipedia.org/wiki/Diagramas_uml

2.7.6. Arquitectura

El desarrollo de un sistema con gran cantidad de software requiere que
este sea visto desde diferentes perspectivas. Diferentes usuarios (usuario final,
analistas, desarrolladores, integradores, jefes de proyecto…) siguen diferentes
actividades en diferentes momentos del ciclo de vida del proyecto, lo que da
lugar a las diferentes vistas del proyecto, dependiendo de qué interese
más en cada instante de tiempo.

La arquitectura es el conjunto de decisiones significativas sobre:

• La organización del sistema
• Selección de elementos estructurales y sus interfaces a través
  de los cuales se constituye el sistema.
• El Comportamiento, como se especifica las colaboraciones entre esos
  componentes.
• Composición de los elementos estructurales y de comportamiento
  en subsistemas.

Progresivamente más grandes.

• El estilo arquitectónico que guía esta organización:
  elementos estáticos y dinámicos y sus interfaces, sus colaboraciones
  y su composición.

La una arquitectura que no debe centrarse únicamente en la estructura
y en el comportamiento, sino que abarque temas como el uso, funcionalidad, rendimiento,
capacidad de adaptación, reutilización, capacidad para ser comprendida,
restricciones, compromisos entre alternativas, así como aspectos estéticos.
Para ello se sugiere una arquitectura que permita describir mejor los sistemas
desde diferentes vistas, donde cada una de ellas es una proyección de
la organización y la estructura centrada en un aspecto particular del
sistema.

La vista de casos de uso comprende la descripción del comportamiento
del sistema tal y como es percibido por los usuarios finales, analistas y encargados
de las pruebas y se utilizan los diagramas de casos de uso para capturar los
aspectos estáticos mientras que los dinámicos son representados
por diagramas de interacción, estados y actividades.

La vista de diseño comprende las clases, interfaces y colaboraciones
que forman el vocabulario del problema y de la solución. Esta vista soporta
principalmente los requisitos funcionales del sistema, o sea, los servicios
que el sistema debe proporcionar. Los aspectos estáticos se representan
mediante diagramas de clases y objetos y los aspectos dinámicos con diagramas
de interacción, estados y actividades.

2.8. OOHDM

Es un Método de Diseño de Desarrollo en Hipermedia Orientado
a Objetos (Object-Oriented Hypermedia Design Method) y abarca las cuatro actividades:

• El Modelo Conceptual
• Diseño de la Navegación
• Diseño Interfaz Abstracta
• Implementación

Estas actividades se realizan en una mezcla de estilo incremental, iterativo
y basado en prototipos de desarrollo.

En el dominio de la hypermedia hay requerimientos contradictorios que
deben ser satisfechos en una estructura unificada. En el manual, de la aplicación
final, la navegación y la conducta funcional debe integrarse transparentemente.
Por otro lado, durante el proceso del diseño se debe ser capaz al desacoplar
decisiones de diseño relacionadas con la estructura de navegación
de aplicación de aquéllas relacionados con el propio modelo del
dominio. Desde que la mayoría al que los ambientes de implementación
no dan apoyo completo al soporte de conceptos orientados a objetos, los modelos
de diseño deben traducirse fácilmente en las plataformas existentes.

Según OOHDM, el desarrollo de aplicaciones de hypermedia ocurre
cuando cuatro actividades se procesan:

Que se realiza en una mezcla de estilos de desarrollo iterativo e incremental;
en cada paso un modelo será construido o mejorado.

Los principios básicos del método de OOHDM son:

1. Contempla los objetos que representan la navegación como
vistas de los objetos detallados en el modelo conceptual.

2. El uso de abstracciones apropiadas para organizar el espacio
de la navegación, con la introducción de contextos de navegación.

3. La separación de las características de interfaz
de las características de la navegación.

4. Una identificación explícita que hay en las decisiones
de diseño que sólo necesitan ser hechos en el momento de la
implementación.

OOHDM es una mezcla de estilos de desarrollo basado en prototipos, en
desarrollo interactivo y de desarrollo incremental. En cada fase se elabora
un modelo orientado a objetos conceptual que recoge las características
a resaltar en la misma incrementando los resaltados de la fase o fases anteriores.

El punto de partida es la elaboración de modelo del dominio de
la aplicación, qué determina el universo de discurso. Esto se
hace durante la fase del Modelo Conceptual y usa principios modelados orientado
a objetos bien conocidos [Wirfs-Brock 90, Rumbaugh 91] aumentó con algunas
primitivas como perspectivas del atributo y sub- sistemas.

2.8.1. MODELO CONCEPTUAL

Durante esta actividad, se construye un esquema conceptual que representa
objetos, sus relaciones y colaboraciones que existen en el dominio designado.
En aplicaciones de hypermedia convencionales, es decir, aquellos en los que
los componentes de la hypermedia no serán modificados durante su ejecución,
se podría usar un modelo semántico estructural [Banerjee87], sin
embargo, cuando la base de información puede cambiar dinámicamente
o si se piensa realizar cómputos complejos o consultas en los objetos
o el esquema, se necesita una abundante conducta del modelo orientado a objetos.

En OOHDM, el esquema conceptual es construido en las clases, relaciones
y sub-sistemas. Las clases son descritas como de costumbre en el modelo orientado
a objetos, sin embargo, pueden multi-digitar atributos representando perspectivas
diferentes de la misma entidad del mundo. Se usa una notación que es
similar a UML [OMG 00], la Clase y Tarjetas de las relaciones, similar a las
tarjetas de CRC [Wirfs-Brock 90] son usadas como una ayuda de la documentación,
ayudando remontar decisiones de diseño enviados y al revés.

Procesos diferentes de modelo de objeto o modelo Conceptual y el diseño
son pensados y discutidos por:

Las metodologías orientadas a objetos y bibliografía en
el área. Sin embargo hay algunas decisiones modeladas que aparecen en
cualquier proceso en el que puede impactar en la estructura navegacional de
aplicaciones de la hypermedia. En este papel, se enfoca en las decisiones de
diseño que afectan tal estructura.

Se describe un modelo de primitivas brevemente en los párrafos
siguientes.

Como la mayoría de ellos son variaciones ligeras de su equivalente
modelo orientado a objetos y métodos de diseño, no se elaboran
más allá. En cambio, se enfoca adelante esos problemas que afectan
la actividad del diseño de navegación.

En OOHDM el esquema de la clase consiste en una colección de clases
conectado por relaciones. Los objetos son instancias de clases, y de esa manera,
cuando una relación se mantiene entre las clases. Las Clases se usarán
después, durante el Diseño de navegación para derivar Nodos,
y las Relaciones que serán usadas para derivar Enlaces (Links).

Se observa un modelo conceptual simplificado de un almacén de
discos compactos. Los objetos de clase del Cliente serán responsables
procesar las peticiones relacionadas con arreglos para requisitos particulares
individuales como. El modelo conceptual en OOHDM incluye el modelo de la clase
en métodos orientados al objeto tradicionales. Siendo basado en UML,
puede ser complementado obviamente con otros modelos de UML usando casos de
uso, diagramas de secuencia, el etc.

Fig. II.2 Modelo Conceptual para una Tienda de CD's.
Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html

Decidiendo así para expresar una relación como un atributo,
un método o una combinación de ambos es un problema de diseño
que ha sido principalmente discutido en el objeto de comunidad. Como una alternativa,
situacional se acerca como responsabilidad de Wirfs-Brockos manejo de diseño
[Wirfs-Brock 90] servicio que usa diagramas de la colaboración en lugar
de relaciones en el estilo de UML.

Desde el punto de vista diseño de hypermedia las relaciones expresan
un aspecto importante del dominio de la aplicación y ellos no deben esconderse
en clase atributos (por lo menos hasta que se necesita llevar a cabo esas clases).
Esto significa que una relación debe especificarse siempre que un atributo
represente una entidad conceptual compleja intentada para ser explorada en la
hypermedia final. De hecho, cuando la implementación de aplicaciones
usa una arquitectura orientada a objetos proporcionando acceso a las relaciones
será una responsabilidad de la clase fuente y será implementado
como un método y quizá accede a una variable del caso. En [Lange94],
una extensión a la clase diagrama de OMT [Rumbaugh91] se presenta para
reforzar relaciones.

En esta aproximación de diseño, se proporcionan tres construcciones
de abstracciones: Agregación, Generalización / Especialización
y un concepto del empaquetamiento de Sub-sistemas. El primero es útil
para describir clases complejas como agregación es más simple
y el segundo para construir Jerarquías de la Clase y la herencia usando
como un mecanismo compartido. Los sub-sistemas son un mecanismo del empaquetamiento
por abstracciones de modelo de dominios enteros.

Escogiendo usar objetos, agregado, atributos complejos o relaciones son
una decisión de modelo que puede variar de la aplicación a aplicación.
Dado que la agregación es una relación estructural importante,
se sugiere descomponer un objeto en partes cada tiempo se supone que estas partes
son exploradas en la aplicación de la hypermedia como no-atómico.
Existiendo heurísticas en el dominio del modelo orientado a objetos puede
usarse para identificar estructuras de agregación.

Se usa la misma semántica de herencia como en [Rumbaugh 91] es
decir las clases heredan los atributos, parte-estructura, relaciones y conducta
de super-clase.

Fig. II.3 Modelo Conceptual de ejemplo Fuente: http://es.wikipedia.org/wiki/OOHDM

Usando la conducta del modelo orientado a objeto para describir aspectos
diferentes de una aplicación de hipermedia permite expresar una gran
variedad de actividades de la informática como preguntas dinámicas
a una base objeto, las modificaciones del objeto on-líne, búsquedas
basadas en heurísticas, etc. El tipo de funcionamiento requerido en el
modelo conceptual depende en los aspectos deseados de la aplicación.
Para muchas aplicaciones, en particular, aquélla implementación
que llevan a cabo un Browser (es decir sólo leer) la funcionalidad, comportamiento
de la clase, más allá de la funcionalidad de conectarse puede
parecer innecesario. En este caso, el comportamiento llega a acceder una base
de información de multimedia navegando encima de las relaciones, y podría
ser "integrado" en el propio modelo.

En contraste, en aplicaciones en las que la base de información
subyacente puede que cambie dinámicamente como el efecto de acciones
del usuario, o cuando la red de hipermedia es simplemente un componente de una
aplicación corporativa más grande, se puede necesitar definir
métodos que implemente ese comportamiento en clases conceptuales. Durante
el diseño Navegacional y el Diseño de Interfaz, se especifica
la manera en que la interfaz de objetos activa el comportamiento de ambos en
el modelo de navegación y conceptual.

Desde que OOHDM es un método de Diseño y no un armazón
de aplicación, se asume que los métodos para lograr el valor de
atributos de un objeto son automáticamente generados. Cuando deben hacerse
otros cómputos y deben corresponderse deben especificarse métodos.
Usando la terminología de métodos orientado a objetos se puede
decir que el Modelo Conceptual contendrá aspectos de Modelos de Análisis
y Diseño.

Cuando la aplicación se ejecute en un ambiente de soporte (distribuido)
de objetos, las clases en el modelo conceptual serán implementadas directamente
como están definidos, que especifican perspectivas múltiples como
atributos separados. Si no, ellos servirán como especificaciones de diseño
para el de navegación y actividades de diseño de interfaz.

2.8.2. Diseño Navegacional

La primera generación de aplicaciones de multimedia intentaba
realizar la navegación a través de un espacio de información
usando un solo modelo de datos de hipermedia. A pesar de estos problemas que
son bien conocidos en la comunidad de la hipermedia, ellos raramente han sido
tomados en cuenta por los diseñadores de Multimedia y Web Sites.

El mayor esfuerzo de diseño normalmente se ha puesto en aspectos
de interfaz del usuario y la estructura de la navegación se construye
en jerarquías simples. Ahora que los navegadores (Browser) de Web son
la interfaz, y a veces el Host, para los tipos diferentes de aplicaciones, hay
un riesgo en la navegación a ser considerada simplemente otro tipo de
de comportamiento de aplicación.

En OOHDM, la navegación es considerada un paso crítico
en el diseño de una aplicación de hipermedia. Un Modelo de navegación
se construye como una vista más de un modelo conceptual y permite la
construcción de modelos diferentes según los perfiles diferentes
de los usuarios. Cada modelo de navegación proporciona una vista "Subjetiva"
del modelo conceptual.

Mientras se diseña la estructura de navegación de una aplicación
Web, se tiene en cuenta varios aspectos como:

¿Que objetos serán navegados, que atributos poseen, y que
son las relaciones entre estos objetos y los mismos definidos en el esquema
conceptual? Se hará esto definiendo nodos y enlaces (Links) como vistas
orientadas a objetos de objetos conceptuales y relaciones.

¿Qué tipo de estructuras de composición existe entre
los objetos de navegación y cómo son relacionados?

¿Cuál es la estructura fundamental de navegación?

¿En qué contexto el usuario navegará?

Se introducirá el concepto de contextos de navegación,
una arquitectura primitiva para organizar el espacio de la navegación.
Se necesita decidir los objetos navegados que pueden parecer diferentes según
el contexto en el que ellos son visitados, y se debe especificar esas diferencias
claramente.

¿Cuales conexiones y estructuras de acceso existen entre objetos
que serán navegados (enlaces, trayecto de búsqueda, camino o trayecto,
índices, etc.)? ¿Cómo procede la navegación cuando
el usuario salta "Jump" de un objeto a otro, es decir, lo que es el
efecto de navegación en la fuente "source" y en el destino
"target object" y posiblemente en otro objeto relacionado también?

El diseño de navegación se expresa en dos esquemas, el
esquema de la Clase De navegación, y el Esquema del Contexto De navegación.
Los objetos navegables de una hipermedia en la aplicación es definida
por un esquema de la clase navegacional cuyas clases reflejan la vista escogida
sobre del dominio de la aplicación. En OOHDM, hay un juego de tipos pre-definidos
de clases de navegación: nodos, links o enlaces, y estructuras de acceso.
La semántica de nodos y enlaces es el usual en aplicaciones de hipermedia,
y estructuras de acceso, como índices y recorridos guiados, que represente
posibles maneras de acceso a los nodos.

Se introducirá el concepto de contextos de navegación,
una arquitectura primitiva para organizar el espacio de la navegación.
Se necesita decidir los objetos navegados que pueden parecer diferentes según
el contexto en el que ellos son visitados, y se debe especificar esas diferencias
claramente.

¿Cuales conexiones y estructuras de acceso existen entre objetos
que serán navegados (enlaces, trayecto de búsqueda, camino o trayecto,
índices, etc.)? ¿Cómo procede la navegación cuando
el usuario salta "Jump" de un objeto a otro, es decir, lo que es el
efecto de navegación en la fuente "source" y en el destino
"target object" y posiblemente en otro objeto relacionado también?

El diseño de navegación se expresa en dos esquemas, el
esquema de la Clase De navegación, y el Esquema del Contexto De navegación.
Los objetos navegables de una hypermedia en la aplicación es definida
por un esquema de la clase navegacional cuyas clases reflejan la vista escogida
sobre del dominio de la aplicación. En OOHDM, hay un juego de tipos pre-definidos
de clases de navegación: nodos, links o enlaces, y estructuras de acceso.
La semántica de nodos y enlaces es el usual en aplicaciones de hipermedia,
y estructuras de acceso, como índices y recorridos guiados, que represente
posibles maneras de acceso a los nodos.

2.8.2.1. Nodos: Los nodos son contenedores básicos de información
de las aplicaciones hipermedia. Se definen como vistas orientadas a objeto de
las clases definidas durante el diseño conceptual usando un lenguaje
basado en query, permitiendo así que un nodo sea definido mediante la
combinación de atributos de clases diferentes relacionadas en el modelo
de diseño conceptual. Los nodos contendrán tanto atributos de
tipos básicos (donde se pueden encontrar tipos como imágenes o
sonidos) y enlaces.

2.8.2.2. Enlaces: Los enlaces reflejan la relación de navegación
que puede explorar el usuario. Ya se sabe que para un mismo esquema conceptual
puede haber diferentes esquemas navegacionales y los enlaces van a ser imprescindibles
para poder crear esas vistas diferentes. Las clases enlaces sirven para especificar
los atributos de enlaces y estos a su vez para representar enlaces entre clases
nodos o incluso entre otros enlaces. En cualquier caso, el enlace puede actuar
como un objeto intermedio en un proceso de navegación o como un puente
de conexión entre dos nodos.

2.8.2.3. Estructuras de Acceso: Las estructuras de acceso actúan
como índices o diccionarios que permiten al usuario encontrar de forma
rápida y eficiente la información deseada. Los menús, los
índices o las guías de ruta son ejemplos de estas estructuras.
Las estructuras de acceso también se modelan como clases, compuestas
por un conjunto de referencias a objetos que son accesibles desde ella y una
serie de criterios de clasificación de las mismas.

2.8.2.4. Contexto Navegacional: Para diseñar bien una aplicación
hipermedia, hay que prever los caminos que el usuario puede seguir, así
es como únicamente se podrá evitar información redundante
o que el usuario se pierda en la navegación. En OOHDM un contexto navegacional
está compuesto por un conjunto de nodos, de enlaces de clases de contexto
y de otros contextos navegacionales. Estos son introducidos desde clases de
navegación (enlaces, nodos o estructuras de acceso), pudiendo ser definidas
por extensión o de forma implícita.

2.8.2.5. Clase de Contexto: Es otra clase especial que sirve para
complementar la definición de una clase de navegación. Por ejemplo,
sirve para indicar qué información está accesible desde
un enlace y desde dónde se puede llegar a él.

La especificación de las Transformaciones de Navegación
describe la dinámica de la aplicación, mostrando los cambios espaciales
de navegación cuando el usuario navega, es decir, qué nodos se
activan y qué nodos son desactivados cuando un enlace es continuado (Notese
en la Figura 4). La semántica de navegación predefinida en OOHDM
es que cuando un enlace es continuado, el nodo de la fuente se deja desactivado
y el nodo objetivo activado. Esta interpretación normalmente es el valor
por defecto encontrado en los navegadores (Browsers) de Web.

De una manera análoga, los enlaces reflejan que las relaciones
pretenden ser exploradas por el usuario final y también se define como
vistas en relaciones en el esquema conceptual. Los enlaces conectan objetos
de navegación y pueden ser uno-a-uno o uno-a-muchos.

Fig. II.4 Esquema básico navegacional para
my.yahoo.com. Fuente: Designing Personalized Web Applications http://www10.org/cdrom/papers/395/index.html

El resultado de atravesar un enlace es expresado por cualquier definición
de semántica navegacional proceduralmente como resultado de la conducta
del enlace o usando una máquina de transición de estado orientada
a objeto similar a Statecharts, las estructuras de Acceso (índices) son
también definidos como clases y maneras alternativas presentes para la
navegación en la aplicación de la hipermedia. En términos
Orientado a Objetos, las relaciones entre los nodos y los objetos conceptuales,
y entre los enlaces y relaciones en el esquema, son expresados como instancias
del patrón o modelo de diseño del Observador. La sintaxis general
para definir los atributos del nodo se muestran debajo (la sintaxis para los
enlaces es similar).

Donde: El name, es el nombre de la clase de nodos que se está
creando. El className, es el nombre de una Clase Conceptual (donde el nodo está
trazándose). El nodeClass, es el nombre de la súper-clase Los
attri, son los nombres de atributos para esa clase, typei los tipos del atributos.
Los namei de 砳on los asuntos para la expresión de la pregunta y los

Si se toma en cuenta el ejemplo anterior, sobre producirá la definición
del Nodo siguiente:

Note que el valor del atributo del toAuthor es un enlace que es el parámetro
con la clase de Enlace Is Author of. Al definir la apariencia de la interfaz
del Nodo Clase Historia se puede, por ejemplo, hacer aparecer el enlace como
un botón invisible sobre del nombre del autor (autor del atributo). Aunque
puede que parezca que ambos atributos tienen la misma conducta, sólo
el enlace actúa en contestación a un evento de la interfaz.

Fig. II.5 Información de Nodos
Fuente: http://es.wikipedia.org/wiki/OOHDM

Las aplicaciones hypermedia bien diseñadas deben tomar en cuenta
la manera qué el usuario explora el espacio de la hypermedia. La información
redundante debe ser juiciosamente usada y se debe poder ayudar que el usuario
pueda escoger la manera en que él navega de una manera consecuente y
controlada. Desgraciadamente, los nodos y enlaces no son suficientes para cumplir
este objetivo. Aunque la solución usual a este problema es llevar a cabo
herramientas de orientación, también se piensa que nivel más
alto que deben ser usados por primitivas de navegación arquitectónicos.

Este es el punto donde los contextos de navegación aparecen.

En OOHDM, la estructuración principal primitiva del espacio de
navegación es el concepto de Contexto de Navegación. Un contexto
de navegación es un conjunto de nodos, enlaces, contexto, clases y otros
contextos de navegación (anidados).

Clase basados en Objetos, en este tipo de contexto pertenecen a la misma
clase C y son seleccionados por dar una propiedad P, por el que debe satisfacerse
a una propiedad todos los elementos: Contexto = {e | P(e), e ? C}. Un caso común
es cuando incluye todas las instancias de una clase (P es idénticamente
verdad).

2.8.3. Diseño de Interfaz Abstracta

Una vez que las aplicaciones de estructura navegacional han sido definidos,
se debe especificar ahora aspectos de la interfaz. Esto significa definir la
manera en que diferentes objetos de navegación aparecerán, qué
objetos de navegación de la interfaz se activara y otra funcionalidad
de aplicación, y qué transformaciones de la interfaz tendrán
lugar y cuando.

Una separación ordenada entre ambas preocupaciones, de navegación
y diseño de interfaz abstracta, permite construir interfaces diferentes
para el mismo modelo de navegación, llevando a un grado más alto
de independencia de tecnología de la interfaz de usuario. En suma, esta
separación permite entender mejor la aplicación global de la estructura
para indicar qué transformaciones claramente en la interfaz serán
transformaciones navegacionales.

Aunque se ha discutido que el aspecto de la interfaz de usuario de aplicaciones
interactivas (en particular las aplicaciones de la web) es un componente crítico,
moderno, las metodologías tienden a descuidar este aspecto. Ellos relegan
la especificación para herramientas de implementación-dependientes,
y por consiguiente las decisiones de diseño en este nivel raramente se
documentan. Es más, como llevar a cabo la interfaz de la Web normalmente
se hacen aplicaciones por medio de los editores de HTML especializados, muchos
críticos pueden ignorar aspectos de la interfaz.

En OOHDM, se usa un acercamiento del Diseño de Datos de Vista
Abstractos (ADVs), para describir la interfaz del usuario de una aplicación
de hypermedia [Cowan 95]. ADVs son objetos en los que tienen un estado y una
interfaz, donde la interfaz puede ser ejercido a través de mensajes (en
particular, eventos externos generados por el usuario). Las ADVs son abstractas
en el sentido de que ellos sólo representan la interfaz y el estado,
y no la aplicación. Las ADVs han sido usados para representar interfaces
entre dos medios de comunicación diferentes como un usuario, una red
o un dispositivo (un cronómetro, por ejemplo) o como una interfaz entre
dos u mas Objetos de Datos Abstractos (ADOs). Los ADOs son objetos que no soportan
externamente eventos generados por el usuario [Cowan 95]. Desde un punto de
vista arquitectónico, las ADVs son observadores para ADOss, para que
el protocolo de comunicación entre la interfaz y los objetos de aplicación
siga las reglas descritas en el Modelo de Diseño de Observador [Gamma
95].

En la Figura 4 se observan los datos abstractos jerarquizados, "cuadro",
"descripción", "interfaz del contexto", "descripción
de la demostración" y las "referencias de la demostración"
exhiben un comportamiento usuario-perceptible. Por ejemplo cuando el usuario
corre la "descripción de la demostración" en los ADV
se exhibe la "descripción". la "interfaz del contexto"
alternadamente se compone de las anclas que ponen en ejecución jerarquizadas
de ADVs para la navegación del contexto, básicamente una vision
simple del diseño final de las pantallas.

Fig. II.6 Diagrama de Configuración para los nodos ADV.
Fuente: OOHDM's Design Process http://www-di.inf.puc-rio.br/schwabe/HT96WWW/section3.html

Un ADV usado en el diseño de aplicaciones Web puede verse como
un objeto de interfaz. Comprende un conjunto de atributos (y objetos de interfaz
anidado) qué define sus propiedades de percepción, y el conjunto
de eventos que puede manejar, como eventos generados por el usuario. Los ejemplos
de eventos generados por el usuario son MouseClick, MouseDoubleClick, MouseOn,
etc. Las ADVs pueden ser fácilmente implementadas en ambientes orientados
a objetos para el Web o puede traducirse a documentos HTML. Pueden definirse
valores del atributo como constantes y pueden definirse estilos particulares
de apariencia como posición, color, o sonido. Los modelos de interfaz
ADV unen al modelo que permite tratar estos rasgos de una manera abstracta y
los relega al paso de la aplicación. En general, los ADVs especifican
la organización y el comportamiento de la interfaz, pero la apariencia
física real o de los atributos, y el diseño de la ADV en la pantalla
real se hace en la fase de la implementación.

En el contexto de OOHDM, los objetos de navegación como nodos,
e índices actuarán como ADOs, y su ADVs asociados se usará
para especificar su apariencia al usuario. A continuación se usará
el término ADV para referirse a clases de interfaz y objetos. Cuando
sea necesario se hablará sobre las clases de ADV. Las abstracciones diferentes
y mecanismos de la composición son usados en el diseño de ADV;
primero las ADVs pueden ser compuestas por agregación o composición
de ADVs de nivel más bajo, permitiendo la construcción de usuarios
de interfaces así con objetos perceptibles anidados. Por ejemplo, supóngase
que se tiene una aplicación sobre pinturas. Figura 9 muestras cómo
un ADV que describe una pintura pudiera hacerse fuera de tres ADVs, conteniendo
una imagen, texto, y un botón. Además, ADVs pueden ser organizados
en jerarquías del generalización/especialización que proporcionan
un poderoso armazón conceptual por definir jerarquías de objetos
de la interfaz.

Fig. II.7 Nodo ADV referente a la página de
Descargas del CMS ASOAJEDRENEFuente: http://es.wikipedia.org/wiki/OOHDM

En Figura 5, "Texto Buscar" es un Objeto de la Interfaz que
envía un conjunto de anclas o enlaces al TextField (Campo de texto) más
general. Entretanto el "Botón Buscar" especializado agregando
una conducta más personalizada (no mostrado en la Figura). Cuando se
implementa esta aplicación Web usando un ambiente de soporte de ciertos
tipos de objetos de interfaz, se puede usar como ADVs primitivos para producir
esta especificación de diseño.

En resumen, ADVs:

La manera en que se estructuran objetos de la interfaz usando agregación
y generalización/especialización como mecanismos de abstracción.
ADVs expresan la estructura del esquema estático que lleva a cabo la
metáfora de la interfaz [Hannemann 93]. Las ADVs permiten definir la
apariencia de la interfaz de objetos de navegación y otros objetos de
la interfaz útiles (como barras del menú, botones y menús).

Se muestra un ADV correspondiente al Diseño del sitio Web Portinari
(http://www.portinari.org.br /) un aplicación de hypermedia que contiene
parte del trabajo y documentos relacionados de Candido Portinari, pintor brasileño
famoso.

El ADV Painting contiene algunos atributos que describen ciertos aspectos
del cuadro y muchos ADVs anidados como Picture (Cuadro), References y People
(Referencias y Personas). En la notación de Figura 8 Referencias y las
Personas no se intentan ser mostradas al mismo tiempo y para que sus ADVs son
sobrepuestas. ADVs ShowPeople (Mostrar personas), ShowReferences (Mostrar personas)
son mandos activos que permiten mostrar uno de los ADVs previamente mencionado.
El ADV de THeme InContext implementa la interfaz de la Clase de InContext Theme
y proporciona mandos de la navegación dentro del Contexto De navegación:
Cuadros de un Tema. Las ADVs similares deben ser especificados por otros Contextos
navegacionales como Picture (Cuadros) de una estrategia. Mientras los diagramas
de arriba o anteriores muestra la naturaleza estática de interfaces de
Pictures (Cuadros), las dinámicas son descritas usando ADV-mapas, se
especifica que cuando ShowPeople es clicked (pulsar el botón), envía
la lista al despliegue del mensaje de las personas asociadas con la pintura,
y lo mismo ocurre para ShowReference. Nota que éste es una interfaz pura
de efecto no involucra navegar a otro nodo.

Entretanto, cuando el objeto de la interfaz Anterior "Previous"
es clicked (hacer click), envía el mensaje anchorSelected (anterior)
a la DIFICULTAD correspondiente, en este caso un Objeto de InContext para que
se comunique con el ancla (etiqueta, enlace) correspondiente y así se
navega a otra pintura. Aún cuando la aplicación no es orientada
a objetos, este modelo de comunicación es fácil de implementar
en la mayoría de las plataformas. Para acabar esta sección se
muestra la interfaz real del sitio Web Portinari y como los objetos de la interfaz
están relacionados con sus partes equivalentes implementados.

2.8.4. Implementación.

En esta fase, el diseñador realmente implementará el diseño.
Hasta ahora, todos los modelos fueron deliberadamente construidos de semejante
manera en lo que se refiere a ser independiente de la plataforma de implementación;
en esta fase el ambiente particular de (tiempo de ejecución) runtime
se toma el derecho de acceso a un servidor o a la red internet. A continuación
se fijará cómo los diseños de OOHDM pueden ser implementados
en el WWW, tener cuidado para no arreglar una sola alternativa, desde que hay
muchos acercamientos posibles a través de los cuales esto puede ser logrado.
Cuando la fase de implementación se alcanza, el diseñador ya tiene
definido los artículos de información que son parte del dominio
del problema. También tiene identificado cómo estos artículos
deben ser organizados según el perfil del Usuario y asignaciones; ya
que se ha decidido lo que la interfaz se parecerá, y cómo se comportará.
En orden para implementar todos esto en el ambiente de WWW y aplicaciones de
multimedia, el diseñador tiene que decidir cómo los artículos
de información (ambos conceptual y objeto de navegación) será
almacenada. También debe decidir cómo se comprenderán la
apariencia de la interfaz y el comportamiento serán realizados usando
HTML y posiblemente use algunas extensiones. En general, note que la apariencia
actual será definida por un profesional de diseño gráfico
que será parte el equipo de Diseño. Aunque OOHDM es un método
en términos de modelos de OO orientados a objetos, no requiere un ambiente
de aplicación OO; (pero no en la Web) se describe en [Milet 96]; las
aplicaciones basadas en Java son de baja tendencia. Tabla 4 obsérvese
un resumen de esta fase.

Fase Implementación Productos Aplicación ejecutable. Herramientas
El entorno del lenguaje de programación. Mecanismos Los ofrecidos por
el lenguaje. Objetivo de diseño Obtener la aplicación ejecutable.
Tabla 4: Fase de Implementación de OOHDM

Mapeo de Información de Artículos

Los artículos de información (qué corresponde a
los ADOs en el modelo de interfaz abstracta) puede guardarse en archivos o en
una base de datos. Debido a la naturaleza y la complejidad de los tipos de aplicaciones
para las que en OOHDM sea más conveniente, recuérdese usar una
base de datos para guardar los objetos Conceptuales y de Navegación.

Desde la mayoría de los DBMSs disponibles en el mercado hoy son
relacionales, un mapeo de modelos OO hacia los modelos relacionales equivalentes
deben ser hechos. Hay varias técnicas y heurísticas para hacer
esto. Los métodos asociados con las clases son implementados como un
conjunto de procedimientos que acceden a la base de datos para ejecutar sus
cómputos.

Para ilustrar el tipo de decisiones de diseño, se discutirá
brevemente una alternativa de mapeo. Cada clase en el modelo de OO para ser
implementado es enviar hacia una tabla, donde cada columna guarda un atributo,
y cada fila corresponde a un objeto de esa clase. Un atributo distinguido puede
usarse como una llave de la base de datos, o un identificador interno que corresponden
a un puntero (que le permite al programa acceder a un recurso como una función)
del objeto y pueden usarse como una llave.

Para atributos cuyo tipo no se apoya directamente en el DBMS (ej. datos
de multimedia), una tabla auxiliar separada debe ser implementada, y los atributos
de objetos almacenan el atributo Identificador ID de una fila en la tabla auxiliar
correspondiente. Alternativamente, almacenar el nombre de un archivo en el sistema
operativo que contiene el valor actual. Ambas alternativas tienen limitaciones;
por ejemplo, el primero requiere asociación extra, y segundo es vulnerable
a los cambios fuera del control del DBMS. Desgraciadamente, esto sólo
puede evitarse si el DBMS ofrece soporte para tipos de datos complejos, como
es adecuado lo más común en la última generación
de productos que llegan al mercado. En sección se declaró que
el Modelo de la Navegación ha terminado una vista del Modelo conceptual.
El diseñador tiene la opción de reflejar esta organización
en la base de datos que corresponden a cada modelo. En otras palabras, él
puede definir la base de datos conteniendo los objetos de Navegación
(nodos, links, etc…) como una vista, soportada por el DBMS, de la base de
datos que corresponde al modelo Conceptual. En el caso donde el DBMS no soporta
el mecanismo de vista directamente, o por las razones de eficacia, el diseñador
tiene la opción a la mano la vista de informática. En este caso,
solo quiere llevar a cabo al modelo de la Navegación, desde que es el
primero que el usuario estará accediendo. Evidentemente, esta alternativa
tiene limitaciones o anomalías en términos de evolución
del esquema el cuál puede llegar a ser evidente cuando el mismo banco
de datos Conceptual se usa como la base para varios aplicaciones. Éste
es el caso, por ejemplo, cuando las compañías tienen sitios en
su intranets, y la parte de estos sitios es visible (normalmente con una interfaz
diferente) en el WWW. Además de trazar definiciones de la clase en el
modelo del banco de datos cualquier (correlativo, OO, etc…) usándose,
también es necesario llevar a cabo clase "InContext" que funcionan
como decoradores para los objetos dentro de los contextos particulares. Típicamente,
esto implica enriquecer al modelo de los datos usado en la base de datos para
adicionar atributos, y definiendo funciones de control en las que hacen estos
atributos accesible en los contextos apropiados. Si la implementación
esta directamente basada en el sistema del archivo, éstos controlan las
funciones que accederán a archivos adicionales que contienen la información
contextual.

Una vez que las bases de datos son definidos, ellos deben ser integrados
en el WWW. Hay muchas maneras en las que esto puede hacerse, y no se elaborará
este extenso; basta decir que cualquiera de estas técnicas puede emplearse.
En este respeto, el criterio para escoger el método de la integración
será igual que otras aplicaciones, como se discutió en la teoría.

2.8.5. Usando OOHDM

Los modelos usados en las cuatro fases abordadas en la sección
anterior son suficientes para permitir el plan de sistemas de información
basados en la Web. No obstante, como con cualquier método, hay conocimiento
adicional en el que es recogido por diseñadores en prácticas,
que no es parte del propio método. La investigación acerca de
OOHDM incluye varios desarrollos en esta dirección fuera de la que está
llevándose, a continuación se dará un cuadro global brevemente
de OOHDM y la investigación relacionada.

Fig. II.8 Ambiente OOHDM-Web. Fuente: Ribeiro
M. OOHDM-Web Manual do Usuário

Un método que ha sido usado recientemente captura conocimiento
del diseño, sobre todo en el campo de OO orientado a objetos, es el uso
de Modelos de Diseño los cuales se nombran sistemáticamente, explique
y evalúe diseños importantes y recurrentes en sistemas del software.
Ellos describen problemas que ocurren repetidamente, y describen el centro de
la solución a ese problema, de semejante manera se puede usar esta solución
muchas veces en diferentes contextos y aplicaciones. Mirando usos conocidos
de un modelo del diseño particular, se puede ver cómo un diseñador
exitoso resuelve problemas recurrentes. De esta manera, se exige esto usando
a diseñadores de prototipos de diseño pueden ganar desde conocimiento
del diseño en el que existe varias comunidades, como hypermedia o diseño
de interfase de usuario. Se ha estado coleccionando modelos de diseño
conveniente para la aplicación del diseño de hypermedia [Rossi
97]. El objetivo es desarrollar un sistema de modelos inter-relacionados bastante
compactos para poder expresar diseños completos como la aplicación
sucesiva de modelos en este sistema. Se ha estructurado estos modelos en tres
sub-grupos, particularmente arquitectónico, navegación y modelos
de la interface. Los modelos arquitectónicos dan pautas para implementar
substrates del software para las aplicaciones de hypermedia. Estos modelos son
bastante similares a los modelos en [la Gamma 95], desde que ellos se dirigen
problemas como navegación de desacoplar de otros tipos de conductas,
organizando jerarquías de links y fin tipos de nodos, desacoplar link
de activación del proceso de determinar el punto extremo del link. Más
detalles pueden encontrarse en [Rossi96a, Garrido 97].

Modelos en la ayuda de categoría de navegación la organización
de la estructura navegacional de una aplicación de hypermedia para lograr
aclarar y significativo para los lectores deseados. Ellos dirigen problemas
recurrentes cuya solución determina el grado de éxito de aplicaciones
de hypermedia. Un ejemplo interesante de una navegación el modelo es
el modelo de "Referencia Activa" cuya meta es proporcionar una referencia
perceptible y permanente sobre el estado actual de navegación. Combina
herramientas de orientación con una manera fácil de navegar a
un juego de nodos relacionados, al mismo o posición más alta en
la estructura de la navegación. Este modelo ayuda construir un camino
simple para espectadores actualmente no con tal de que por browsers de WWW actual.

El modelo de "Referencia Activa" ha sido usado en muchos sitios
Webs para mejorar la navegación. Por ejemplo, en http://city.net/countries
/ brazil/rio_de_janeiro, hay una barra con una representación del camino
lógico de la raíz al nodo corriente. El lector tiene una manera
simple de entender donde él esta, donde él puede ir luego mientras
accede a datos sobre una ciudad, en este caso Río de Janeiro. Vea [Rossi
97] para una descripción completa de este modelo.

Modelos de la interfase significa para diseñadores de GUI de Hipermedia.
Ellos son abstractos y por consiguiente independientes del ambiente usado para
la implementación.

El diseño de la interfase gráfica es una tarea compleja,
relacionada principalmente con encontrar el combinación correcta de elementos
(ambos en cantidad y en sus relaciones espaciales), de tal manera que esos elementos
actúan recíprocamente para una presentación eficaz de la
información.

También pueden aplicarse modelos en este grupo fuera del área
de aplicaciones de hypermedia, en el contexto más extenso de diseño
de GUI. Por ejemplo el diseño de patrones "Desacoplar Información/Interacción"
modelo de diseño es apuntar a resolver el problema de cómo hacer
la interacción entre la aplicación y el usuario, a la interfase
gráfica de un nodo. Este modelo es particularmente útil en sitios
Web cuando se generan páginas dinámicamente y no se puede definir
etiquetas de links como hotwords empotrado en el texto.

El modelo "Information/Interaction Decoupling" da pautas claras
con respecto a la colocación física de links de la navegación.
El diseño de patrones de "Behavioral Grouping" ayuda al diseñador
a construir una interfase de semejante manera que el usuario puede fácilmente
entender el tipo de funcionamientos que le permiten realizar en la interfase.

Este modelo resuelve el problema de organizar la interfase cuando muchos
tipos diferentes de transacción, deben proporcionarse navegación
y funcionalidades de la interfase simultáneamente. Una descripción
más profunda de modelos de la interfase puede encontrarse en [Garrido
97].

Aunque se ha declarado que ese Diseño de la Navegación
debería hacerse tomando en cuenta a los perfiles de usuario y tareas,
el propio OOHDM no proporciona, hasta ahora, cualquier indicación en
cómo esto realmente debe hacerse. Se ha estado investigando [Barroso
98] el uso de escenarios de usuarios-centrados para ayudar identifica a la clase
de usuario y tareas típicas para ser apoyado por la aplicación.

El método pensado empieza con un modelo conceptual preliminar
dibujado por el diseñador desde su comprensión del dominio. Observando
escenarios descritos por clases diferentes de usuarios, el diseñador
construye la navegación parcial, y esquemas de Clase de navegación
parcial. Después de que todos los guiones se han analizado, el diseñador
empieza un proceso de anexar los senderos parciales y esquemas con los que culminan
un Diagrama de Contexto de navegación y un esquema de Clase de Navegación
actualizado.

En el curso de esta investigación, se ha extendido OOHDM para
incorporar un modelo de seguridad para permitir acceso controlado a los objetos.
Este modelo toma en cuenta a la clase de usuario y contextos, y define mecanismos
para especificar ciertos tipos de contextos dinámicos que se construyen
como resultado de acciones del usuario especificadas.

Otro problema importante está construyendo ambientes del software
para dar soporte al método; ha seguido dos acercamientos diferentes:

Se ha construido un ambiente de un CASO que le permite a un diseñador
describir el concepto de navegación y modelos de la interfase que usan
la notación de OOHDM y le proporciona la documentación automatizada
sobre esos modelos. Él puede luego generar plantillas de implementación
para las escenas diferentes, como Asymetrixs, Toolbook o HTML.

Se ha diseñado e implementado un prototipo orientado a objetos
(OONavigator) para reforzar sistemas de información orientados a objetos,
mejorando el acceso a sus recursos de información agregando un frontal
"navigational", transparentemente, integrando esta funcionalidad de
la navegación con sus propias aplicaciones computacionales.

En OONavigator, conceptos del hipermedia (nodos, links, índices,
y contextos) son modelados como componentes que se entrelazan con objetos de
la aplicación. La clase de aplicación presenta el papel de clases
conceptuales de OOHDM, mientras los objetos de prototipo (nodos y links) comprendan
el componente de navegación de la aplicación. Se ha enriquecido
los MVC estándar paradigma de interfase [Krasner 88] con fijar medios
de semejante manera que el apoyo a la metáfora de interfaces de nodos
"point y click" del hipertexto. La interfase puede publicarse en los
browsers de la Web que usa herramientas como VisualWave. Usando Navegador orientado
a objetos, un diseñador puede enriquecer la aplicación -orientada
a objetos con características de hypertext siguiendo pautas de OOHDM.
En este caso la hipermedia de "instantiates" de diseñador y
clases de la interfase (usando una herramienta visual) y conectarlos a sus clases
de la aplicación para permitir navegación a través del
espacio de información de aplicaciones[22]

CAPÍTULO III

Material y método utilizado en las prácticas pre profesionales

3.1 MATERIALES

3.1.1. Recursos Humanos.

Tabla III.1: Todos los roles son asumidos por el
bachiller Orlando Jimmy Mamani Poma.

Fuente: Elaboración propia.

Recursos de Software

Tabla III.2: Software Utilizado en el Desarrollo del
Informe de Prácticas Pre Profesionales

Fuente: Elaboración propia

Recursos de Hardware

Tabla III.3: Equipos y materiales Utilizados en el Desarrollo del
Informe de Prácticas Pre Profesionales

Fuente: Elaboración propia.

3.2 ANÁLISIS

3.2.1. IDENTIFICACIÓN DEL PROYECTO:

TITULO: Desarrollo de un Sistema Informático para la Administración
de Expedientes de la Universidad José Carlos Mariátegui.

DESCRIPCIÓN: Es un sistema Web que mediante sus módulos
se puede administrar los expedientes de los alumnos de la UJCM.

AUTOR: Orlando Jimmy Mamani Poma

VERSIÓN: 1.0

FECHA: 20/03/08

3.2.2. DOCUMENTACIÓN DEL ANÁLISIS

La Universidad José Carlos Mariátegui es una Institución
Educativa que agrupa varios Modalidades de Estudio.(Carreras a Distancia, Pregrado,
Auxiliares de Educación, Complementación Académica, Otros
)

La oficina de mantener los documentos académicos de cada alumno está
a cargo de OSAERC (Oficina de Servicios Académicos Evaluación
y Registro Central), todos los documentos están almacenados en la Oficina
Cercana o también llamada Archivo, que está a cargo de la OSAERC.

Todos los alumnos de la Universidad José Carlos Mariátegui Tienen
documentos (Certificados de Estudio, partida de Nacimiento, Copia de DNI, Constancia
de Ingreso a la UJCM entre otros), los cuales están clasificados en un
expediente. Se genera un expediente por cada alumno, en donde además
de los documentos antes descritos; también se almacenan otros documentos
generados a partir de tramites Universitarios (Resoluciones, Dictámenes,
Futs, Constancias de Biblioteca, Conformidad de documentos).Todos los expedientes
están clasificados según facultad, Especialidad, y año
de ingreso.

En el transcurso del año académico se trasladan los expedientes
a diferentes oficinas por razones de trámites, los expedientes son solicitados
a OSAERC, para evaluación. La forma de búsqueda es manual no se
tiene un registro exacto de donde se encuentre un expediente, dado a que no
se cuenta con un sistema que tenga registrado el estado del expediente; generando
muchas veces demora en la búsqueda con lo cual se genera demora en la
atención del trámite.

3.2.3. DOCUMENTACIÓN DE DESARROLLO

En primer lugar identificamos los actores que interactúan con
el sistema.

Fig. III.1 Diagrama General del Sistema. Fuente:
Propia

3.2.3.1 DIAGRAMA DE PAQUETES:

Fig. III.2 Diagrama de Paquetes

Fuente: Propia

Podemos dividir el Sistema en 4 Sub-sistemas:

Sub – Sistema Expedientes

Sub – Sistema Administración

Sub – Sistema Oficinas

Sub – Sistema de Alumnos

3.2.3.2 DIAGRAMAS DE CASOS DE USO – DESCRIPCIÓN

A) SUB – SISTEMA DE OFICINAS

Fig. III.3 Diagrama de Gestión de Actores

Fuente: Propia

Fig. III.4 Diagrama de Gestión de usuarios

Fuente: Propia

DESCRIPCIÓN DE CASO DE USO: