Fases del proceso racional unificado



Descargar 33.99 Kb.
Fecha de conversión19.03.2019
Tamaño33.99 Kb.

PROCESO RACIONAL UNIFICADO

El Proceso Racional Unificado (RUP), es un proceso de desarrollo de software y, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Su principal herramienta es el UML.


FASES DEL PROCESO RACIONAL UNIFICADO

  • Fase De Inicio: En esta fase se determina las principales funciones del sistema para sus usuarios más importantes, se establece un modelo de la arquitectura del sistema y establece el plan de proyecto y cuanto será su costo.




  • Fase De Elaboración: Durante esta fase, se especifica, en detalle, la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema.




  • Fase De Construcción: Desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de análisis y diseño iniciados durante la fase de elaboración se completen para reflejar la versión final del incremento del software.




  • Fase De Transición: El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentación del usuario reporta tanto defectos como cambios necesarios. Además el equipo de software crea la información de soporte necesaria (manuales de usuario, procedimientos de instalación) para el lanzamiento.


CARACTERÍSTICAS DEL PROCESO RACIONAL UNIFICADO

  • Iterativo E Incremental: RUP es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.




  • Dirigido Por Los Casos De Uso: Los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el RUP.




  • Centrado En La Arquitectura: Asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema.




  • Enfocado En Los Riesgos: Requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

FLUJOS DE TRABAJOS

Un flujo de trabajo muestra la secuencia de actividades que se desarrollan dentro de uno o varios Casos de Uso, como una pieza de funcionalidad concreta que satisface los requerimientos de un Actor.



  • Flujos de requisitos

  • Flujos de análisis

  • Flujos de diseño

  • Flujos de implementación

  • Flujos de Pruebas


INTRODUCCION AL UML

El Lenguaje Unificado de Modelado (UML), es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.


Un modelo UML esta compuesto por tres clases de bloques de construcción:

  • Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)

  • Relaciones: relacionan los elementos entre sí.

  • Diagramas: Son colecciones de elementos con sus relaciones.


LA CONCEPCIÓN DEL UML

El UML es la creación de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos, trabajaban en empresas distintas durante la década de los años ochenta y principios de los noventa y cada uno diseñó su propia metodología para el análisis y diseño orientado a objetos. Sus metodologías predominaron sobre las de sus competidores. A mediados de los años noventa empezaron a intercambiar ideas entre sí y decidieron desarrollar su trabajo en conjunto.


Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Se conformó un consorcio del UML. Entre los miembros se encuentran DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versión 1.O del UML y lo puso a consideración del OMG (Grupo de administración de objetos) como respuesta a su propuesta para un lenguaje de modelado estándar.
El UML ha llegado a ser el estándar de factor en la industria del software, y su evolución aún continúa.
DIAGRAMAS DEL UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Es importante destacar que un modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.




  • Diagrama De Clases: Es un diagrama que modela la estructura de las clases del sistema. Muestra las entidades en un sistema o dominio y la forma en que tales entidades se relacionan entre si. Representan un conjunto de elementos que son estáticos, como las clases y los tipos, sus contenidos, y las relaciones que se establecen entre ellos.




  • Diagrama De Objetos: Un diagrama de objetos está relacionado de cerca con un diagrama de Clases, con la diferencia de que éste describe las instancias de los objetos de clases en un punto en el tiempo. Son muy útiles en la comprensión de diagramas de clases complejos, al crear diferentes casos en los que se aplican las relaciones y las clases.




  • Diagrama De Casos De Uso: Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente.

Los casos de uso cuentas con varios elementos básicos:




  • Actores: Representa al usuario del sistema. Es una entidad externa al sistema que se modela y que puede interactuar con el.




  • Caso de uso: Es una operación / tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.




  • Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema para llevar a cabo el caso de uso. Pueden ser de tres tipos:




  1. Include: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar comportamiento común en dos o más casos de uso.

  2. Extend: Es decir, esta relación implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias.

  3. Generalizaciones: Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>). Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).




  • Limites del sistema: Resulta útil dibujar los límites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.




  • Diagrama De Estados: Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones.

Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.




  • Diagrama De Secuencias: Es uno de los más utilizados para identificar el comportamiento de un sistema, por representar los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por una transacción del sistema. Además, se utiliza con frecuencia para validar los casos de uso y apreciarla lógica del diseño de forma dinámica.




  • Diagrama De Actividades: Representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general. El propósito del diagrama de actividad es: modelar el flujo de tareas y modelar las operaciones




  • Diagrama De Colaboraciones: Es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. También son llamados diagramas de comunicación.




  • Diagrama De Componentes: Representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.




  • Diagrama De Clases De Análisis: Son una abstracción de una o varias clases y/o subsistemas del diseño del sistema en un nivel más alto y menos formal. Existen tres estereotipos que permiten distinguir el ámbito de las diferentes clases, como son:




  • Clases de Entidad: se utilizan para modelar información que posee una larga vida y que es a menudo persistente, son las típicas entidades de los modelos entidad-relación tradicionales, accedidos normalmente por varios casos de uso y suelen asociárseles una base de datos.

  • Clases de Interfaz: se utilizan para modelar las interacciones entre el sistema y sus actores, es decir usuarios y sistemas externos. Esta interacción a menudo implica recibir (y presentar) información y peticiones de (y hacia) los usuarios y los sistemas externos.

  • Clases de Control: representan coordinación, secuencia, transacciones y control de objetos y se usan con frecuencia para encapsular el control de un caso de uso en concreto.



WEBML (THE WEB MODELING LANGUAGE, 2010)

Web Modeling Language (WebML), es una notación visual para especificar el contenido, la composición y funciones de navegación de los sitios Web complejos en el plano conceptual. WebML permite el alto nivel de descripción de un sitio Web con arreglo a distintas abstracciones ortogonales, cada uno capturado por un modelo distinto.
Los principales objetivos del proceso de diseño WebML son los siguientes:


  • Expresar la estructura de una aplicación Web con una descripción de alto nivel, que se puede utilizar para realizar consultas, evolución y mantenimiento.

  • Presentar múltiples vistas de un mismo contenido.

  • Separar el contenido de la información de su composición en las páginas, la navegación y la presentación, el cual puede ser definido y desarrollado de forma independiente.

  • Almacenar la meta-información recopilada durante el proceso de diseño en un repositorio o librería, el cual se puede utilizar durante la vida útil de la aplicación para generar páginas Web de forma dinámica.

  • Modelar de manera explícita usuarios y comunidades, para permitir la especificación de las políticas de personalización y aplicaciones uno-a-uno.

  • Permitir la especificación de las operaciones de manipulación de datos para actualizar el contenido del sitio o la interacción con servicios externos.


MODELOS DE WEB UML

La especificación de un sitio en WebML consta de 5 perspectivas ortogonales:




  • Modelo De Datos: Expresa el contenido de los datos del sitio, en términos de las entidades y las relaciones relevantes. Este modelo es compatible con notaciones clásicas, como el modelo Entidad-Relación utilizada en el diseño conceptual de base de datos, y los diagramas de clases UML, usado en el modelado orientado a objetos.

Los elementos fundamentales del modelo de datos son entidades, que se definen como contenedores de elementos de datos, y las relaciones, definidas como conexiones semánticas entre entidades. Las entidades poseen propiedades, llamadas atributos, las cuales tienen un tipo asociado. Las entidades pueden ser organizadas jerárquicamente y sus relaciones pueden ser restringidas por medio de restricciones de cardinalidad.




  • Modelo De Hipertexto: Especifica la composición y la navegación del sitio Web. Esto se describe en dos (2) sub-modelos:




    • Modelo de Composición: Describe las páginas que componen el hipertexto, así como de las unidades de contenido que constituyen una página.




    • Modelo de navegación: Expresa la forma como las páginas y las unidades de contenido están vinculadas para formar el hipertexto. Los enlaces pueden ser o no de contexto; es no contextual, cuando se conectan semánticamente páginas independientes (por ejemplo, la página de un artista a la página de inicio del sitio), o contextual, cuando el contenido de la unidad de destino de la relación depende del contenido de la unidad fuente.




  • Modelo de Gestión de Contenido:

Las aplicaciones Web con frecuencia realizan operaciones sobre los datos. Algunos ejemplos son el llenado de formularios de información de perfil personal, la adición de elementos en un carrito de compras, por medio de aplicaciones de manejo de contenido. En todos estos casos, las acciones realizadas a través de las interfaces Web tienen efectos secundarios, por ejemplo, cambian el contenido de algunos datos fuentes conectadas al sitio Web.
La introducción de las operaciones en WebML no afecta al modelo de datos, y requiere dos (2) extensiones del modelo de hipertexto.
WebML incluye unidades operacionales predefinidas, que ofrecen las primitivas más comúnmente utilizadas para actualizar las instancias de las entidades y relaciones de la aplicación, al crear, modificar y eliminar objetos, y la conexión y desconexión a través de las relaciones, además de algunas operaciones útiles, como el inicio de sesión, cierre de sesión, y operaciones de envío de correo electrónico. Las operaciones de manejo de contenido predefinidas pueden ser agrupadas en transacciones, las cuales constituyen secuencias de actualizaciones ejecutadas atómicamente; cuando una transacción es especificada, o toda la secuencia de operaciones individuales que la constituyen se ejecuta con éxito, o la secuencia entera se deshace.
Además de las operaciones incorporadas mencionadas anteriormente, servicios dependientes de aplicaciones y componentes de negocio, como servicios de pago electrónico, se puede representar utilizando el concepto general de operación genérica. Una operación genérica es una "caja negra", cuyos detalles internos no están explícitos en WebML, los cuales pueden ser vinculados a las unidades WebML o páginas.


  • Modelo de Presentación: Expresa la disposición y el aspecto gráfico de las páginas, independientemente del dispositivo de salida y el lenguaje, por medio de un resumen de sintaxis XML. Las especificaciones de presentación son o bien la página específica o genérica.




  • Modelo de Personalización: Los usuarios y grupos de usuarios están explícitamente modelados en la estructura del esquema en forma de entidades predefinidas llamado usuario y grupo de usuarios. Las características de estas entidades se pueden utilizar para almacenar un grupo específico o contenido individual, como sugerencias de compras, lista de favoritos, y los recursos para la personalización gráfica. Luego, OQL como expresiones declarativas similares se puede agregar a la estructura del esquema, que definen los contenidos derivados basado en el perfil de datos almacenados en los usuarios y entidades de grupo. Este contenido personalizado se puede utilizar tanto en la composición de las unidades o en la definición de las especificaciones de presentación.


Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal