sábado, 1 de diciembre de 2012

RMM (Metodología de Administración de Relaciones).


La RMM o Relationship Management Methodology se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodología fue creada 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). Por ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a entornos estáticos.

El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegación hipermedia de la aplicación. Los objetos del dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de modelizar los aspectos unidos a la presentación de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada. La navegación se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegación entre slices, y visita guiada condicional, índice condicional y agrupación, que permiten especificar la navegación entre entidades. El esquema completo del dominio y de la navegación de la aplicación se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del método. Las etapas son:

 Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relación ampliado con relaciones asociativas (aquéllas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de análisis).

 Segunda etapa: determinar la presentación del contenido de las entidades de la aplicación así como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relación en el que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad está constituido por nodos (los trozos o slides) unidos por relaciones estructurales.

 Tercera etapa: definir los caminos de navegación inducidos por las relaciones asociativas del esquema E-R+. A continuación, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de accesos jerárquicos a niveles diferentes de los trozos de información. El esquema RMDM resultante se obtiene añadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa.

Las cuatro etapas restantes consisten en:

 Definición del protocolo de conversión de elementos del diagrama RMDM en objetos de la plataforma de desarrollo.

 Concepción del interfaz usuario.

 Concepción del comportamiento en ejecución.

 Construcción del sistema y test.

Muestra de un diagrama entidad-relación (las entidades se representan con un recuadro y las relaciones mediante un símbolo en forma de tridente).


Veamos con más detalle algunos ejemplos del modelo de datos RMDM (Relationship Management Data Model), que se genera a partir de un diagrama entidad-relación. Con él se describirá no sólo la información referente a las clases de objetos, sino también a la navegación entre ellos. Así, hay definidas unas primitivas para modelar los dominios o datos (clases de objetos) y otras para el acceso a tales objetos. De entre las primeras, la más típica es la entidad (se representa mediante un recuadro y su nombre). Como en la teoría relacional una entidad está compuesta por varios atributos. Además, en RMDM se incorpora una nueva primitiva denominada "slice", que define conjuntos de atributos de una entidad que se agrupan de forma lógica.

Estos diagramas especifican la navegación en el sistema:

 

De acuerdo con HDM, RMM define correspondencias tipo. Propone el modelo Entidad-Relación para especificar el dominio y lo enriquece introduciendo los conceptos de slice ( trozo) y de relación estructural para los cuales se preestablece una metáfora hipermedia. Los slices y las entidades se asocian con nodos y las relaciones asociativas (entre entidades) y las relaciones estructurales (entre trozos) se asocian con enlaces.

El modelo del dominio se enriquece, por lo tanto, con dos tipos de elementos preestablecidos que tienen una correspondencia clara en términos hipermedia.

En RMM, el modelo hipermedia retoma los elementos enlace, índice y visitas guiadas de HDM enriqueciéndolos con capacidades condicionales. Sin embargo, el método no permite al diseñador definir elementos hipermedia propios que tengan capacidades específicas ya que impone la utilización de metáforas preestablecidas.

Ante las limitaciones que ofrecía RMM, sus autores Balasubramanian, Bieber e Isakowitz, analizaron la estructura de navegación en RMM y propusieron añadir 2 nuevos tipos de slices: los slices híbridos (que permiten combinar atributos de diferentes entidades y estructuras de acceso), los slices mínimos (la mínima parte de una entidad que es necesaria para identificar uno de sus elementos y que se utilizará como ancla) y los m-slices (que permiten combinar primitivas de acceso con otros slices de otras entidades para crear un m-slice).  Se propone crear la estructura de la navegación no en base a las entidades sino a los slices, es decir a conjuntos de atributos.

A partir de las carencias de RMM e incorporando la novedad de los slices mínimos e híbridos, Lopistéguy, Losada y Dagorret analizan el modelo RMM y encuentran algunas carencias, por lo que proponen la creación de unas nuevas estructuras de navegación que doten de una mayor flexibilidad al modelo RMM, a la vez que crean unas serie de primitivas de acceso nuevas.

Estas son las estructuras que introducen:

 Navegación jerárquica: al tener varias relaciones 1:N encadenadas, se permite navegar desde cualquier entidad a otra que esté por debajo de ella en la jerarquía. Estos enlaces inferidos, no extraídos directamente de una relación 1:N, se representarán con trazo discontinuo.

 Navegación en relaciones N:M: se permite navegar de un extremo al otro de la relación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberán incluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidad intermedia.

 Navegación múltiple: se crean unas nuevas primitivas que permiten el acceso múltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de la que la entidad destino es parte. En el enlace quedará especificado qué entidad es la origen, cuál la destino y cuál la tercera. Recordar que esta navegación es especialmente apropiada en estructuras todo-parte.

 Acceso aleatorio: permite acceder a un elemento de forma aleatoria, sin saber exactamente a cuál.

 Acceso simultáneo: permite representar el acceso a todos los elementos de una entidad a la vez. Por ejemplo, si estamos en un Seminario, con esta primitiva accedemos a todos sus ponentes simultáneamente, todos a la vez, y no mediante un índice o uno tras otro en una visita guiada

Y así quedará la lista de primitivas con la inclusión de las nuevas primitivas de acceso:



La metodología RMM permite hacer explícita la navegación al hacer el análisis, lo que permite, teóricamente, obtener una navegación más estructurada e intuitiva, y lo hace de una forma muy sencilla, como es  añadir unas primitivas a un modelo entidad-relación tradicional. El concepto de slice es muy útil, ya que permite agrupar datos de una entidad en diferentes pantallas. Se utilizaría, por ejemplo, para mostrar dos vídeos en dos pantallas diferentes sobre un mismo fenómeno. También es interesante la primitiva de grupo, que permite mostrar la jerarquía de menús.

RMM representa el primer caso en el que se crea una metodología completa definiendo las distintas fases y no únicamente un modelo de datos. Además,  se basa en un modelo de datos relacional, ajustándose así a la gran mayoría de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la información son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran número de ellas.

Diagrama Entidad-Relación

Jerarquía de menús con detalle

Metodología del software educativo por Álvaro Galvis.

Metodología del software educativo por Álvaro Galvis (ISE) 

Es una metodología de desarrollo de software que contempla una serie de fases o etapas de un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y ajuste, y por último implementación. 

Etapas:


Etapa 1: Análisis
Características de la población objetivo: edad (física y mental), sexo, características físicas y mentales (si son relevantes), experiencias previas, expectativas, actitudes, aptitudes, intereses o motivadores por aprender. 
Conducta de entrada y campo vital: nivel escolar, desarrollo mental, físico o psicológico, entorno familiar y escolar, etc. 

Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los mecanismos de análisis de necesidades educativas en. Estos mecanismos usan entrevistas, análisis de resultados académicos, etc. para detectar los problemas o posibles necesidades que deben ser atendidas. El problema o necesidad no tiene que estar necesariamente relacionado con el sistema educativo formal, pueden ser necesidades sentidas, económicas, sociales, normativas, etc. 

Principios pedagógicos y didácticos aplicables: se debe analizar cómo se ha llevado a cabo el proceso de enseñanza-aprendizaje para establecer cómo debe enfocarse el ambiente, qué factores tomar en cuenta, qué objetivos debe cumplir. 

Justificación de uso de los medios interactivos: Para cada problema o necesidad encontrada se debe establecer una estrategia de solución contemplando diferentes posibilidades. El apoyo informático debe ser tomado en cuenta siempre y cuando no exista un mecanismo mejor para resolver el problema: soluciones administrativas, ver si el problema se soluciona al tomar decisiones de tipo administrativo; soluciones académicas, cambios en metodologías de clase; mejoras a los medios y materiales de enseñanza contemplando el uso de medios informáticos. Una vez que se han analizado todas las alternativas se puede decir por qué el uso de medios informáticos es una buena solución. La justificación se puede basar en la no existencia de otro medio mejor y en la relación costo-beneficio para la institución pues puede ser que exista una mejor solución pero que demande mayor tiempo y esfuerzo o un mayor costo económico, etc. 

Diagramas de interacción: Permiten ver secuencias de interacción entre el usuario y la aplicación, representando lo que se espera del diálogo y dando más detalle a la descripción textual de la descripción de la aplicación. Los diagramas de interacción son un formalismo que permite ver la secuencia de acciones entre diferentes partes de la aplicación involucrada en llevar a cabo determinada actividad. Es importante ver la secuencia de acciones para cada escenario de interacción. Con base en estos diagramas se pueden ver cuáles pueden ser las necesidades de información en cada escenario de interacción y se puede ir pensando en cuáles pueden ser los algoritmos que serán usados. 


Etapa 2: Diseño 
Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y tratamiento que debe ser capaz de apoyar el Sistema Educativo). 

Comunicacional (es donde se maneja la interacción entre usuario y máquina, se denomina interfaz). 

Computacional (con base a las necesidades se establece qué funciones es deseable que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los estudiantes). 


Etapa 3: Desarrollo 
En esta fase se implementa la aplicación usando la información obtenida anteriormente. Tomando en cuenta las restricciones que se tengan. 


Etapa 4: Prueba Piloto 
En esta etapa se pretende ayudar a la depuración del Sistema Educativo a partir de su utilización por una muestra representativa de los tipos de destinatarios para los que se hizo y la consiguiente evaluación formativa. Es imprescindible realizar ciertas validaciones (efectuadas por expertos) de los prototipos durante las etapas de diseño y prueba en uno a uno de los módulos desarrollados, a medida que estos están funcionales. 


Etapa 5: Prueba de Campo La prueba de campo de un Sistema Educativo es mucho más que usarlo con toda la población objeto.
Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de desarrollo hay que buscar la oportunidad de comprobar, en la vida real, que aquello que a nivel experimental parecía tener sentido, lo sigue teniendo, es decir, si efectivamente la aplicación satisface las necesidades y cumple la funcionalidad requerida.

Metodología de James Martin y UML.


Metodología de James Martin
Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones,   y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.

Fases o Etapas de Metodología RAD de James Martin.

Esta metodología consta de 4 etapas a saber:

  1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución.

  2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.

  3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.

  4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.



Ventajas y Desventajas de la Metodología RAD

Ventajas             |             Desventajas

Ahorro dramático de tiempo durante el desarrollo del sistema.            Mayor velocidad y menores costos pueden repercutir en la calidad del sistema (p.e., debido a falta de atención en controles internos).
Puede ahorrarse tiempo, dinero y esfuerzo humano. Peligrosa incoherencia entre el sistema desarrollado y el negocio, debido a la falta de información o a procesos del negocio sobreentendidos.
Estrecha correspondencia entre los requerimientos del usuario y las especificaciones del sistema.
Pueden producirse inconsistencias entre diseños internos y entre sistemas.
Trabaja muy bien cuando la velocidad de desarrollo es importante (cambios rápidos de las condiciones del negocio), o cuando lo sistemas pueden capitalizarse en oportunidades estratégicas. Posibles violaciones de estándares de programación relacionadas con nomenclaturas inconsistentes e insuficiente documentación.
Permite cambiar rápidamente el diseño de los sistemas cuando los usuarios lo demandan Dificultades con el reuso de módulos para futuros sistemas.
Los sistemas son optimizados por los usuarios involucrados en el proceso del RAD. Carencia de un diseño escalable dentro del sistema.
Se concentra en los elementos esenciales del sistema, desde el punto de vista del usuario. Falta de atención de la futura administración del sistema dentro de los sistemas existentes (p.e., falta de integración con el modelo de datos organizacional y facilidades de recuperación del sistema)        . El usuario se compromete y se hace propietario del sistema. Altos costos de compromiso por parte del personal clave.


UML

Concepto:
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

Fases en el desarrollo basado en UML

En la versión definitiva de la metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta las siguientes fases o etapas:

· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.

Cuadro Estructural UMl
El lenguaje UML se expresa con símbolos y/o agrupaciones de estos llamadas diagramas. Nos sirve fundamentalmente para crear diferentes tipos de ellos permitiéndonos ver desde diferentes perspectivas un sistema software.

 
Existe un tipo primordial que es “Diagrama UML” del cual heredan “Diagrama Estructural” y “Diagrama Comportamiento”, de estos a su vez heredan los trece diferentes tipos de diagramas más comunes, existiendo un tipo intermedio que serían los “Diagrama de Interacción”.

Diagramas Utilizados en UML:

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
  * Diagrama de clases
  * Diagrama de componentes
  * Diagrama de objetos
  * Diagrama de estructura compuesta (UML 2.0)
  * Diagrama de despliegue
  * Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
  * Diagrama de actividades
  * Diagrama de casos de uso
  * Diagrama de estados
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
  * Diagrama de secuencia
  * Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x)
  * Diagrama de tiempos (UML 2.0)
  * Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)

Clases y Objetos.
Un objeto es una representación de una entidad, ya sea real o conceptual, con límites bien definidos y con significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su estado, su comportamiento y su identidad.
El estado de un objeto es una de las posibles condiciones bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y está definido por un conjunto de propiedades (atributos), por los valores de esas propiedades y por las relaciones que dicho objeto puede tener con otros objetos.

El comportamiento de un objeto determina la forma en que responde ante peticiones de otros objetos, y tipifica todo lo que el objeto puede hacer. El comportamiento de un objeto se materializa en el conjunto de operaciones definidas para dicho objeto.

La identidad implica que cada objeto es único, incluso si su estado es idéntico al de otro objeto.
En UML una clase es una descripción de un grupo de objetos con propiedades comunes (atributos), comportamiento común (operaciones), relaciones comunes y semántica común. Por tanto, una clase es una plantilla (template) para la creación de objetos, donde cada objeto de dicha clase será una instancia de ella (no pudiendo ser instancia de más de una clase).

Antes de describir los distintos elementos que forman parte de un diagrama de clases, es importante aclarar la forma en que dichos diagramas pueden ser utilizados durante el proceso software. A la hora de confeccionar o interpretar un diagrama de clases pueden considerarse tres perspectivas:

Conceptual: Permite representar los conceptos del dominio. Aunque dichos conceptos suelen llevar, de una forma natural, a las clases que los implementan, puede que no exista una correspondencia directa.

Especificación: Cuando se trata de representar las interfaces del software y no el software en sí.

Implementación: Es en esta perspectiva donde realmente tenemos clases, siendo ésta la perspectiva más utilizada.

Un diagrama de clases UML puede ser utilizado desde cualquiera de estas perspectivas, resulta en este caso conveniente el indicar la perspectiva de la que se trata por medio de estereotipos.

Diagrama de clases.

Los diagramas de clases son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido. El diagrama de clases de más alto nivel (main class diagram), será lógicamente un dibujo de los paquetes que componen el sistema. A su vez cada paquete tendrá un main class diagram que muestra las clases del paquete Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, su cardinalidad (cuantos objetos intervienen en la relación) y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación). La descripción de clases complejas se puede documentar con diagramas de estados.
 

Reloj