Resumen Grupo 5.

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 (<<uses>>) o de Herencia (<<extends>>). 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-auno.
 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:
o Modelo de Composición: Describe las páginas que componen el
hipertexto, así como de las unidades de contenido que constituyen una
página.
o 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.