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: