Análisis y Diseño de Sistema

      La metodología utilizada para desarrollar la aplicación es la RMM ext. (Relationship Management Methodology) ha sido ideada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases).
     RMM ext está basado en un modelo de datos relacional, lo cual se ajusta perfectamente a la gran mayoría de las aplicaciones.
     RMM Ext. Establece una metodología para el desarrollo de aplicaciones multimedia, y que está especialmente indicada para aplicaciones basadas en bases de datos relacionales; no obstante, presenta una serie de carencias en la formas de navegación, a pesar de la introducción de los nuevos slices.

MODELAMIENTO CONCEPTUAL
El Modelamiento Conceptual de la metodología RMM ext consta de dos etapas: el tradicional Modelo Entidad-Relación, donde se modela el dominio de información a considerar; y el Diseño de M-Slices, estructuras conceptuales que permiten modelar las unidades de presentación de la aplicación. En la primera etapa, se diseña un Esquema Entidad-Relación del problema, que representa un estudio de las entidades e interrelaciones relevantes del dominio de aplicación; Tales elementos forman la base de la aplicación hipermedial y muchos de ellos se manifestarán, en el producto final, como nodos y links. En la segunda etapa, se realiza el diseño de m-slices, estructuras que permiten encapsular información proveniente de varios orígenes:
Atributos de la entidad propietaria.
Atributos de otras entidades.
Estructuras de acceso (índices, circuitos guiados, circuitos guiados indexados).

     Modelo Entidad-Interrelación
     La Metodología RMM ext considera en su etapa de Diseño como primer modelo de datos al Modelo Entidad-Relación, que permite caracterizar el dominio de información y sus interrelaciones.
     Las m-slice son usadas para agrupar información en unidades significativas de información; pueden ser agrupadas y anidadas, formando m-slices de más ato nivel. La m-slice, que permite agrupar atributos de varias entidades.

     Diseño de Slices
     El slice mínimo (minimal slice), Representa el conjunto de atributos de una entidad que permite que el usuario pueda identificar claramente las diferentes instancias de tal entidad. Este slice mínimo se utilizará como ancla a instancias concretas de una entidad.
     Los slices híbridos (hybrid slices) Permiten combinar atributos de diferentes entidades y estructuras de acceso. En la definición original de RMM, los slices estaban formados únicamente por atributos de una misma entidad, con este añadido se permite que en una pantalla aparezcan informaciones de más de una entidad.

     ETAPAS DE LA METODOLOGÍA
     Etapa 0
     Como toda metodología debe comenzar con un estudio de factibilidad y un análisis de los requerimientos (tanto de la información como de la navegación). También debe hacerse una selección del hardware y software que se necesitará.

Etapa 1: Diseño Entidad-Relación
En esta etapa se confecciona un diagrama entidad-relación típico, desglosando las relaciones N:M en dos relaciones 1:N. El objetivo de dicha etapa es explicitar todos los futuros enlaces.

     Etapa 2: Diseño de Slices
     Esta etapa consiste en dividir una entidad en fragmentos significativos y organizarlos en la red de navegación.
     Cada slice agrupará uno o más atributos de una entidad, de tipos muy diferentes. Cada entidad tendrá su head, o slice principal, que se marca con un asterisco y que es slice al que, por defecto, se accede a través de los mecanismos de navegación.

Etapa 3: Diseño de la Navegación
Cada relación del diagrama entidad-relación da lugar a un enlace de navegación, en esta fase sustituimos las relaciones por primitivas de acceso. En general, preferiremos una visita guiada a un índice cuando el número de instancias sea pequeño (menor de 10) y no exista un campo índice que pueda ayudar a los usuarios. Por contrario, si el número es grande, usaremos índices.

Etapa 4: Diseño de Protocolos de Conversión
En esta etapa se escriben unos protocolos por los cuales se transforma cada elemento del RMDM (Modelo de Datos de Administración de Relaciones) en un objeto en la plataforma elegida.

     Etapa 5: Diseño de la Interfaz de Usuario
     Diseño gráfico de todas las pantallas correspondientes a cada uno de los slices que hemos obtenido en la etapa 2.
      Propondremos una interfaz coherente con la estructura, basada en frames o tablas, en la Web o en la división de la pantalla en general.
      Identificar la metáfora.
      Los nuevos usuarios de un sistema pueden utilizarlo más fácilmente si pueden extenderlo metafóricamente a algún conjunto de objetos entidades reales.

Etapa 6: Diseño del Comportamiento en Tiempo de Ejecución
Se decide qué mecanismos se utilizarán para guardar la historia, hacer backtrackings, permitir enlaces transversales.

Etapa 7: Construcción y Tests
Construcción de la aplicación y pruebas, testeando cuidadosamente todos los paths de la navegación.

     CASO PRÁCTICO
     Proyecto:
     Desarrollo de una aplicación Web para el manejo de reclamos derivados del servicio prestado por la compañía SENECA (Sistema Eléctrico del estado Nueva Esparta C.A.)

Objetivo:
Desarrollar una aplicación Web para la realización de reclamos en forma online, con la finalidad de brindar al cliente mayor comodidad al momento de exponer sus inconformidades o quejas por el servicio (entrega de factura, atención en las oficinas comerciales, atención de las cuadrilla en la calle, corrección de facturas); de igual forma el cliente podrá consultar el status en el cual se encuentra su solicitud.

     Descripción:
     Los procesos que se ejecutaran con el desarrollo de esta nueva aplicación son los siguientes:
     Alta de reclamo: el cliente inicia el proceso de reclamo vía Web.
     Consulta: el cliente podrá verificar el estado del reclamo en caso que el mismo exista.
     Aprobación de reclamo: este proceso será realizado por los usuarios dentro de la empresa siguiendo los lineameamientos actualmente establecidos en la aplicación OPEN SGC.
     Impresión del reclamo: el cliente podrá imprimir el soporte del reclamo realizado.

	Volver
Caso Práctico
	La metodología utilizada para desarrollar la aplicación es la RMM ext. (Relationship Management Methodology) ha sido ideada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). RMM ext está basado en un modelo de datos relacional, lo cual se ajusta perfectamente a la gran mayoría de las aplicaciones. RMM Ext. Establece una metodología para el desarrollo de aplicaciones multimedia, y que está especialmente indicada para aplicaciones basadas en bases de datos relacionales; no obstante, presenta una serie de carencias en la formas de navegación, a pesar de la introducción de los nuevos slices. MODELAMIENTO CONCEPTUAL El Modelamiento Conceptual de la metodología RMM ext consta de dos etapas: el tradicional Modelo Entidad-Relación, donde se modela el dominio de información a considerar; y el Diseño de M-Slices, estructuras conceptuales que permiten modelar las unidades de presentación de la aplicación. En la primera etapa, se diseña un Esquema Entidad-Relación del problema, que representa un estudio de las entidades e interrelaciones relevantes del dominio de aplicación; Tales elementos forman la base de la aplicación hipermedial y muchos de ellos se manifestarán, en el producto final, como nodos y links. En la segunda etapa, se realiza el diseño de m-slices, estructuras que permiten encapsular información proveniente de varios orígenes: Atributos de la entidad propietaria. Atributos de otras entidades. Estructuras de acceso (índices, circuitos guiados, circuitos guiados indexados). Modelo Entidad-Interrelación La Metodología RMM ext considera en su etapa de Diseño como primer modelo de datos al Modelo Entidad-Relación, que permite caracterizar el dominio de información y sus interrelaciones. Las m-slice son usadas para agrupar información en unidades significativas de información; pueden ser agrupadas y anidadas, formando m-slices de más ato nivel. La m-slice, que permite agrupar atributos de varias entidades. Diseño de Slices El slice mínimo (minimal slice), Representa el conjunto de atributos de una entidad que permite que el usuario pueda identificar claramente las diferentes instancias de tal entidad. Este slice mínimo se utilizará como ancla a instancias concretas de una entidad. Los slices híbridos (hybrid slices) Permiten combinar atributos de diferentes entidades y estructuras de acceso. En la definición original de RMM, los slices estaban formados únicamente por atributos de una misma entidad, con este añadido se permite que en una pantalla aparezcan informaciones de más de una entidad. ETAPAS DE LA METODOLOGÍA Etapa 0 Como toda metodología debe comenzar con un estudio de factibilidad y un análisis de los requerimientos (tanto de la información como de la navegación). También debe hacerse una selección del hardware y software que se necesitará. Etapa 1: Diseño Entidad-Relación En esta etapa se confecciona un diagrama entidad-relación típico, desglosando las relaciones N:M en dos relaciones 1:N. El objetivo de dicha etapa es explicitar todos los futuros enlaces. Etapa 2: Diseño de Slices Esta etapa consiste en dividir una entidad en fragmentos significativos y organizarlos en la red de navegación. Cada slice agrupará uno o más atributos de una entidad, de tipos muy diferentes. Cada entidad tendrá su head, o slice principal, que se marca con un asterisco y que es slice al que, por defecto, se accede a través de los mecanismos de navegación. Etapa 3: Diseño de la Navegación Cada relación del diagrama entidad-relación da lugar a un enlace de navegación, en esta fase sustituimos las relaciones por primitivas de acceso. En general, preferiremos una visita guiada a un índice cuando el número de instancias sea pequeño (menor de 10) y no exista un campo índice que pueda ayudar a los usuarios. Por contrario, si el número es grande, usaremos índices. Etapa 4: Diseño de Protocolos de Conversión En esta etapa se escriben unos protocolos por los cuales se transforma cada elemento del RMDM (Modelo de Datos de Administración de Relaciones) en un objeto en la plataforma elegida. Etapa 5: Diseño de la Interfaz de Usuario Diseño gráfico de todas las pantallas correspondientes a cada uno de los slices que hemos obtenido en la etapa 2. Propondremos una interfaz coherente con la estructura, basada en frames o tablas, en la Web o en la división de la pantalla en general. Identificar la metáfora. Los nuevos usuarios de un sistema pueden utilizarlo más fácilmente si pueden extenderlo metafóricamente a algún conjunto de objetos entidades reales. Etapa 6: Diseño del Comportamiento en Tiempo de Ejecución Se decide qué mecanismos se utilizarán para guardar la historia, hacer backtrackings, permitir enlaces transversales. Etapa 7: Construcción y Tests Construcción de la aplicación y pruebas, testeando cuidadosamente todos los paths de la navegación. CASO PRÁCTICO Proyecto: Desarrollo de una aplicación Web para el manejo de reclamos derivados del servicio prestado por la compañía SENECA (Sistema Eléctrico del estado Nueva Esparta C.A.) Objetivo: Desarrollar una aplicación Web para la realización de reclamos en forma online, con la finalidad de brindar al cliente mayor comodidad al momento de exponer sus inconformidades o quejas por el servicio (entrega de factura, atención en las oficinas comerciales, atención de las cuadrilla en la calle, corrección de facturas); de igual forma el cliente podrá consultar el status en el cual se encuentra su solicitud. Descripción: Los procesos que se ejecutaran con el desarrollo de esta nueva aplicación son los siguientes: Alta de reclamo: el cliente inicia el proceso de reclamo vía Web. Consulta: el cliente podrá verificar el estado del reclamo en caso que el mismo exista. Aprobación de reclamo: este proceso será realizado por los usuarios dentro de la empresa siguiendo los lineameamientos actualmente establecidos en la aplicación OPEN SGC. Impresión del reclamo: el cliente podrá imprimir el soporte del reclamo realizado.

Caso Práctico