Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Metodologia Rup
Metodologia Rup
Alejandra Barbosa
Natalia Manjarres
German Velasco
Brigieth Vasquez
Bogotá DC
Servicio Nacional de Aprendizaje – SENA
Centro de gestión de mercados logística y tecnologías de información
2056283
Metodologia Rup
Introducción
Características principales
Según Kruchten Philippe (2000), “los Casos de Uso son una técnica de captura de requisitos
que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de
funciones que sería bueno contemplar.
Se define un caso de uso como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del
sistema”.
Los casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino
que también guían su diseño, implementación y prueba. Los casos de uso constituyen un
elemento integrador y una guía del trabajo.
Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego la
implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente
adecuadamente cada caso de uso.
En el caso de RUP, además de utilizar los casos de uso para guiar el proceso, se presta
especial atención al establecimiento temprano de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.
Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar
en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos, actualmente y en el futuro.
La arquitectura dentro de RUP se representa en varias vistas. Todas las vistas juntas forman
el llamado modelo 4+1 de la arquitectura. Según Kruchten Philippe (1998) “el cual recibe
este nombre porque lo forman las vistas lógica, de implementación, de proceso y de
despliegue, más la de casos de uso que es la que da cohesión a todas”.
Al final de la fase de elaboración se obtiene una “baseline” (base de referencia) de la
arquitectura donde fueron seleccionados una serie de casos de uso arquitectónicamente
relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los
más importantes para el usuario y aquellos que cubran las funcionalidades significativas).
Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando se termina.
Durante la planificación de los detalles de la siguiente iteración, el equipo también examina
cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de
la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa
con esta dinámica hasta que se haya finalizado por completo con la versión actual del
producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones (que
son una cantidad variable) según el proyecto, y en las que se hace un mayor o menor hincapié
en los distintas actividades.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una “baseline” (base de referencia)
de la arquitectura.
Para cada iteración se escogen algunos casos de uso, se refina su análisis y diseño, y se
procede a su implementación y pruebas. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.
Fases
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales. En cada
extremo de una fase se realiza una evaluación para determinar si los objetivos de la fase se
han cumplido. Una vez que la evaluación obtiene los resultados deseados, se procede a la
siguiente fase.
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva
versión del producto, cada ciclo está compuesto por fases y cada fase está compuesta por un
número de iteraciones.
2.- Elaboración
4.- Transición
Conforme un proyecto avanza y se intenta mejorar, llega un momento en que el ciclo (las
cuatro fases) debe repetirse. Estos ciclos subsecuentes se llaman los ciclos de la evolución.
Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones.
Disciplinas
Las disciplinas son los flujos del trabajo, los cuales son una secuencia de pasos para la
culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las
de apoyo. Las primarias son las necesarias para la realización de un proyecto de software,
aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:
modelado del negocio, requerimientos, análisis y diseño, implementación, pruebas y
despliegue. Las de apoyo son las que complementan y brindan mejoras a las primarias y
especifican otras características en la realización de un proyecto de software; entre estas se
tienen: entorno, gestión del proyecto, gestión de configuración y cambios.
Requerimientos
Sus objetivos son: establecer lo que el sistema debe hacer, se definen los límites del sistema,
y una interfaz de usuario. También realiza una estimación del costo y tiempo de desarrollo.
Análisis y diseño
Define la arquitectura del sistema y tiene como objetivos trasladar requisitos en
especificaciones de implementación, al decir análisis se refiere a transformar CU (casos de
uso) en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los
diagramas de clases de análisis de cada CU, los diagramas de colaboración de cada CU, el de
clases de diseño de cada CU, el de secuencia de diseño de CU, el de estados de las clases, etc.
Implementación
Tiene como objetivos implementar las clases de diseño como componentes, asignar los
componentes a los nodos, probar los componentes individualmente (pruebas unitarias) e
integrar los componentes en un sistema ejecutable.
Pruebas
Verificar la integración de los componentes (prueba de integración), verificar que todos los
requisitos han sido implementados (pruebas del sistema), asegurar que los defectos
detectados han sido resueltos antes de la distribución.
Despliegue
Sus objetivos son asegurar que el producto está preparado para el cliente, para proceder a su
entrega y recepción por el cliente. En esta disciplina se realizan las actividades de probar el
software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la
tarea de enseñar al usuario.
Éste es esencial para controlar el número de artefactos producidos por la cantidad de personal
que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha
ayuda ya que evitan confusiones costosas, como la compostura de algo que ya se había
arreglado.
Entorno
Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que
engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo
de las pautas que apoyan un proyecto.
Su propósito es proveer a la organización que desarrollará el software, un ambiente en el cual
basarse, el cual provee procesos y herramientas para poder desarrollar el software.
Ya conociendo varias partes del RUP nos concentramos ahora en los elementos que lo
componen, entre estos se tienen: flujos de trabajo, detalle de los flujos de trabajo, actores,
actividades (o acciones) y artefactos.
Actores o roles
Son los personajes encargados de la realización de las actividades definidas dentro de los
flujos de trabajo de cada una de las disciplinas del RUP
Analistas
Desarrolladores
- Arquitecto.
- Revisor de la Arquitectura.
- Diseñador de Cápsulas.
- Revisor del Código y Revisor del Diseño.
- Diseñador de la Base de Datos.
- Diseñador.
- Implementador y un Integrador.
Probadores Profesionales
- Diseñador de Pruebas.
- Probador.
Encargados
Otros
- Cualquier trabajador.
- Artista Gráfico.
- Stakeholder.
- Administrador del Sistema.
- Escritor técnico.
- Especialista de Herramientas.
Artefactos
Los artefactos son el resultado parcial o final que es producido y usado por los actores
durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores,
los cuales utilizan y van produciendo estos artefactos para tener guías. Un artefacto puede ser
un documento, un modelo o un elemento de modelo.
Conjunto de artefactos:
Capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del
negocio sirven como entrada y como referencia para los requisitos del sistema.
2.- Requerimientos
Capturan y presentan la información usada en definir las capacidades requeridas del sistema.
4.- Implementación
5.- Pruebas
Los artefactos desarrollados como productos de las actividades de prueba y de la evaluación
son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de
información sobre las pruebas realizadas y las metodologías de pruebas aplicadas.
6.- Despliegue
Presenta los artefactos que se utilizan como dirección a través del desarrollo del sistema para
asegurar la consistencia de todos los artefactos producidos.
Con grado de finalización nos referimos a cuántos de esos lineamientos del artefacto hemos
completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se. En la
fase de concepción, en la disciplina de implementación del sistema los artefactos tienen una
poca finalización y van aumentando progresivamente en cada fase hasta llegar a su
culminación en la fase de transición.
Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la
fase dada, teniendo una idea un poco más amplia sobre el desenvolvimiento del proyecto
hablando en términos de sus artefactos.
Desventajas de la metodología:
La falta de especificaciones en los requisitos por parte del usuario puede causar ciertas
discrepancias.
Se requiere mucho personal (dependiendo del proyecto).
Ventajas de la metodología:
Es el proceso de desarrollo más general de los existentes actualmente.
Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo
(quién hace qué, cuándo y cómo).
Reutilización
Conclusión
INTRODUCCIÓN
Una metodología Orientada a objetos es un proceso para producir software de una manera
organizada, usando convenciones y técnicas de notación predefinidas. Desde que la
comunidad de programación orientada a objetos tuvo la noción de incorporar el pensamiento
de que los objetos son entidades coherentes con identidad estado y conducta, estos objetos
pueden ser organizados por sus similitudes y sus diferencias, puestas en uso en herencia y
polimorfismo, las metodologías orientadas a objetos incorporan estos conceptos para definir
sus reglas, normas, procedimientos, guías y notaciones para alcanzar un producto de calidad
que satisfaga las necesidades del cliente.
UML El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar
y documentar esquemas de sistemas de software orientado a objetos. UML no es un método
de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo
diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más
accesible para otros. UML está controlado por el grupo de administración de objetos y es el
estándar de descripción de esquemas de software.
UML está diseñado para su uso con software orientado a objetos, y tiene un uso limitado en
otro tipo de cuestiones de programación.
Se define a un objeto como "una entidad tangible que muestra alguna conducta
bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual
almacenamos datos y los métodos que controlan dichos datos".
Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En
particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar
en relación con otros objetos de manera apropiada a este objeto.
Una clase es una plantilla para objetos múltiples con características similares. Las
clases comprenden todas esas características de un conjunto particular de objetos. Cuando
se escribe un programa en lenguaje orientado a objetos, no se definen objetos verdaderos
sino se definen clases de objetos.
Una instancia de una clase es otro término para un objeto real. Si la clase es la
representación general de un objeto, una instancia es su representación concreta. A
menudo se utiliza indistintamente la palabra objeto o instancia para referirse,
precisamente, a un objeto.
● Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir
de componentes probados, que han sido verificados y pulidos varias veces.
● Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con
métodos específicos. Esto tiene particular importancia en los sistemas cliente-
servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían
intentar el acceso al sistema.
● Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una
interfaz de usuario gráfica de modo que el usuario apunte a iconos o elementos de
un menú desplegado, relacionados con los objetos. En determinadas ocasiones, el
usuario puede ver un objeto en la pantalla. Ver y apuntar es más fácil que recordar
y escribir.
● Independencia del diseño. Las clases están diseñadas para ser independientes del
ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas
con formato estándar. Esto les permite ser utilizadas en múltiples sistemas
operativos, controladores de bases de datos, controladores de red, interfaces de
usuario gráficas, etc. El creador del software no tiene que preocuparse por el
ambiente o esperar a que éste se especifique.
Existen cuatro principios básicos, estos principios son fruto de la experiencia en todas las
ramas de la ingeniería.
HISTORIA
Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue
organizado un consorcio internacional llamado UML Partners en 1996 para completar
las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo
como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML
Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML
Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y
administrada por Ed Reykholt, para finalizar las semánticas de la especificación y para
integrar con otros esfuerzos de estandarización. El resultado de este trabajo, el UML
1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en
noviembre de 1997.
UML 1.x
UML 2.x
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones
2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3
fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en
agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En
proceso" y todavía tiene que ser formalmente liberada.
Nos proporciona una serie de herramientas que permiten mostrar el programa en sus
diferentes etapas o procesos, delimitarlos y organizarlos de tal forma que sean
entendibles por la persona que va a desarrollar el sistema.
1. DESVENTAJAS
OBJETIVOS
- El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de
sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a
objetos (OO).
- Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los
métodos más utilizados sigan evolucionando en conjunto y no por separado. Y
además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software,
sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los
requerimientos de análisis, el diseño, la implementación y los conceptos internos de
la OO.
Los puntos más importantes para esta metodología son los siguientes:
Poner énfasis en el análisis y no en el desarrollo.
Poner énfasis en los datos más que en las funciones, lo que proporciona estabilidad al
proceso de desarrollo.
Utilizar una notación común en todas las fases a través de tres modelos que capturan los
aspectos estáticos, dinámicos y funcionales que combinados proveen una descripción
completa del software. La Metodología OMT divide el proceso de desarrollo en tres
partes aisladas: análisis, diseño e implantación.
Análisis:
Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se
expresa en términos de objetos y de relaciones entre ellos, flujo dinámico de control y las
transformaciones funcionales.
Diseño:
Es la estrategia de alto nivel para resolver el problema y cómo construir una solución. Se
define la arquitectura del sistema y se toman las decisiones estratégicas.
Implementación:
En esta fase se convierte finalmente el diseño de objetos en código. A su vez, cada una
de estas fases se divide en su tareas, como son: modelos de objetos, dinámico y
funcional; análisis y del sistema, y objetos del sistema.
Modelo de Objetos:
En esta primera parte del análisis se forma una primera imagen del modelo de clases del
sistema con sus atributos y lasrelaciones entre ellas, usando para ello un diagrama
entidad relación modificada en el que además de las clases y sus relaciones se pueden
representar también los métodos.
Modelo Dinámico:
El modelo dinámico usa un grafo para representar el comportamiento dinámico de cada
clase, es decir, el comportamiento de estas ante cada evento que se produce en el sistema.
Un evento desencadenará en un cambio de estado en la clase que se traducirá en una
modificación de los atributos o relaciones de ésta.
Modelo Funcional:
Muestra que es lo que el sistema ha de hacer mediante un diagrama de flujo de datos, sin
entrar en la secuencia temporal en la que los procesos se ejecutan. El modelo funcional
puede revelar nuevos objetos y métodos que se pueden incorporar en los dos modelos
anteriores. Por eso se dice que el método OMT es iterativo.
Diseño del Sistema:
Se centra en la parte física del sistema como la descomposición de éste en subsistemas, el
tipo de entorno en el que se va a ejecutar, el manejo de recursos y el almacenamiento de
datos.
Diseño de los objetos:
Determina qué operaciones van a realizar los métodos y profundiza incluso los
algoritmos que va a usar. Se escogen los distintos tipos de representación de datos y se
subdivide en módulos que pasarán a formar parte de la implementación.
Metodología BOOCH
Diagramas de clase:
Es una variación de los diagramas de entidad relación en los que se añaden
nuevos tipos de relaciones como la herencia, instanciación y uso. Además
permite agrupar las clases y relaciones en categorías para diagramas
demasiado complejos.
El gráfico correspondiente a una clase en la notación de Booch es una especie
de nube a trazos en cuyo interior se escribe el nombre de la misma, separado
por una linea de sus atributos (estado) y métodos (comportamiento). Cada
clase lleva asociado un nombre que en general debe ser único. No se
especifican todos los métodos y atributos siempre, sino solamente aquellos que
son relevantes para la parte del diseño que tratamos de describir.
Diagramas de objetos:
Diagramas temporales:
Permiten definir como las instancias de las clases pasan de un estado a otro a
causa de ciertos eventos y que acciones se desencadenan de esos cambios de
estado.
Definición de DTE.
Casos de Uso:
Los casos de uso representan los requisitos funcionales de la aplicación a ser
desarrollada; en otras palabras, qué es lo que debe hacer el sistema.
PROCESO UNIFICADO
Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un
marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso,
centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más
conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o
simplemente RUP.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye
aquellos elementos que son comunes a la mayoría de los refinamientos existentes.
OOram
Método de Fusión
Fusión proporciona un método de desarrollo de software orientado al objeto, que
abarca desde la definición de requisitos a la implementación en un lenguaje de
programación.
Es considerada como una metodología de segunda generación, porque proviene de:
Análisis
El análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace.
Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la
de la máquina. El análisis casa con el dominio del problema y se preocupa por el
comportamiento visible externamente.
La meta de la fase de análisis es capturar tantos requisitos del sistema como sea
posible. Se producen los siguientes modelos del sistema:
● Modelo de objetos
● Modelo de la interfaz
● Modelo del funcionamiento,
● Modelo del ciclo de vida.
Modelo de objetos
La finalidad del modelo de objetos en Fusión es: capturar los conceptos que existen en
el dominio del problema y las relaciones entre ellos, mostrar clases y sus relaciones,
(no mostrar objetos)
El modelo de objetos representa: la estructura estática de la información en el sistema,
las clases y relaciones entre ellas
Especifica el orden en el que deben hacerse las cosas dentro de cada fase. También
proporciona criterios de cuándo pasar a la siguiente fase.
En la fase del análisis de Fusión, sólo los atributos de una clase son considerados. Los
métodos son considerados en la fase de diseño. Por consiguiente, en la fase del
análisis, los objetos son similares a las entidades en el tradicional modelo entidad
relación. Atributos de clases, agregación, especialización/generalización.
Conclusiones
Gracias a UML se puede estudiar las distintas partes que conforman al sistema y cómo
interactúan estas. Reflejando las interfaces, protocolos e intercambio de señales. Para tal fin
nos podemos apoyar de los diagramas de clases, estructura compuesta y comunicación.
El lenguaje de Modelado UML cumple con varios requerimientos para elaborar un sistema
orientado a objetos, ya que cuenta con una notación estándar y anotaciones semánticas que
son esenciales para elaborar este tipo de software.