República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación

Instituto Universitario de Tecnología y Administración Industrial
Altos Mirándonos IUTA
Materia: Diseño de sistema
Carrera: Informática

LA METODOLOGÍA UML. RUP Y ÁGIL

Docente: Alumno:
Damarys Linares Harold Méndez
 INTRODUCCION

El lenguaje unificado de modelado …………………………………….1

Tipos de diagramas en UML…………………………………………… 2
Diagrama Estructurales …………………………………………………2
Diagrama de clases ……………………………………………………..3
Diagrama de componentes …………………………………………….4
Diagrama de despliegue ………………………………………………..4
Diagrama de objetos ……………………………………………………5
Diagrama de perfiles ……………………………………………………5
Diagrama de estructura compuesta …………………………………..6
Diagrama de comportamiento …………………………………………6
Diagrama de actividades ………………………………………………6
Diagrama de casos de uso……………………………………………. 7
Diagrama de estados …………………………………………………..7
Diagrama de interacción ………………………………………………8
Diagrama de comunicación …………………………………………...8
Diagrama de tiempos …………………………………………………..9
Diagrama global de interacciones …………………………………….9
Metodología RUP ………………………………………………………10
¿Qué es la metodología ágil? …………………………………………11
Los valores de la metodología ágil..…………………………………. 11
¿Dónde se originó el enfoque ágil? …………………………………..12
Conclusiones …………………………………………………………….13
Bibliografía ……………………………………………………………….14
El lenguaje unificado de modelado
(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 Object Management Group (OMG).
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, funciones del sistema,
y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
Es importante remarcar 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 gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional, Rational Unified Process 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,
la programación orientada a objetos viene siendo un complemento perfecto de
UML, pero no por eso se toma UML solo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
Tipos de diagramas en UML
Existen dos clases principales de tipos de diagramas: diagramas estructurales y
diagramas de comportamiento. Estos últimos incluyen varios que representan
diferentes aspectos de las interacciones. Estos diagramas pueden ser
categorizados jerárquicamente como se muestra en el siguiente diagrama de
clases:

Diagrama Estructurales
Los diagramas estructurales muestran la estructura estática del sistema y sus
partes en diferentes niveles de abstracción. Existen un total de siete tipos de
diagramas de estructura:
Diagrama de clases
Los diagramas de clase son, sin duda, el tipo de diagrama UML más utilizado.
Es el bloque de construcción principal de cualquier solución orientada a objetos.
Muestra las clases en un sistema, atributos y operaciones de cada clase y la
relación entre cada clase. En la mayoría de las herramientas de modelado, una
clase tiene tres partes, nombre en la parte superior, atributos en el centro y
operaciones o métodos en la parte inferior. En sistemas grandes con muchas
clases relacionadas, las clases se agrupan para crear diagramas de clases. Las
diferentes relaciones entre las clases se muestran por diferentes tipos de flechas.
Diagrama de componentes
Un diagrama de componentes muestra la relación estructural de los
componentes de un sistema de software. Estos se utilizan principalmente cuando
se trabaja con sistemas complejos que tienen muchos componentes. Los
componentes se comunican entre sí mediante interfaces. Las interfaces se
enlazan mediante conectores.

Diagrama de despliegue
Un diagrama de despliegue muestra el hardware de su sistema y el software de
ese hardware. Los diagramas de implementación son útiles cuando la solución
de software se despliega en varios equipos, cada uno con una configuración
única.
Diagrama de objetos
Los diagramas de objetos, a veces denominados diagramas de instancia, son
muy similares a los diagramas de clases. Al igual que los diagramas de clases,
también muestran la relación entre los objetos, pero usan ejemplos del mundo
real. Se utilizan para mostrar cómo se verá un sistema en un momento dado.
Debido a que hay datos disponibles en los objetos, a menudo se utilizan para
explicar relaciones complejas entre objetos.

Diagrama de perfiles
Diagrama de perfil es un nuevo tipo de diagrama introducido en UML 2. Este es
un tipo de diagrama que se utiliza muy raramente en cualquier especificación.
Diagrama de estructura compuesta
Los diagramas de estructura compuesta se utilizan para mostrar la estructura
interna de una clase.

De comportamiento
Muestran el comportamiento dinámico de los objetos en el sistema.

Diagrama de actividades
Los diagramas de actividad representan los flujos de trabajo de forma gráfica.
Pueden utilizarse para describir el flujo de trabajo empresarial o el flujo de trabajo
operativo de cualquier componente de un sistema. A veces, los diagramas de
actividad se utilizan como una alternativa a los diagramas de máquina del estado.
Diagrama de casos de uso
Como el tipo de diagrama de diagramas UML más conocido, los diagramas de
casos de uso ofrecen una visión general de los actores involucrados en un
sistema, las diferentes funciones que necesitan esos actores y cómo interactúan
estas diferentes funciones. Es un gran punto de partida para cualquier discusión
del proyecto, ya que se pueden identificar fácilmente los principales actores
involucrados y los principales procesos del sistema.

Diagrama de estados
Los diagramas de máquina de estado son similares a los diagramas de actividad,
aunque las anotaciones y el uso cambian un poco. En algún momento se
conocen como diagramas de estados o diagramas de diagramas de estado
también. Estos son muy útiles para describir el comportamiento de los objetos
que actúan de manera diferente de acuerdo con el estado en que se encuentran
en el momento.
Diagrama de interacción
Los diagramas de interacción incluyen distintos tipos de diagramas:
Diagrama de secuencia
Los diagramas de secuencia en UML muestran cómo los objetos interactúan
entre sí y el orden en que se producen esas interacciones. Es importante tener
en cuenta que muestran las interacciones para un escenario en particular. Los
procesos se representan verticalmente y las interacciones se muestran como
flechas. Los diagramas de secuencia de UML forman parte de un modelo UML y
solo existen dentro de los proyectos de modelado UML.

Diagrama de comunicación
El diagrama de comunicación se llamó diagrama de colaboración en UML 1. Es
similar a los diagramas de secuencia, pero el foco está en los mensajes pasados
entre objetos.
Diagrama de tiempos
Los diagramas de sincronización son muy similares a los diagramas de
secuencia. Representan el comportamiento de los objetos en un marco de
tiempo dado. Si es solo un objeto, el diagrama es directo, pero si hay más de un
objeto involucrado, también se pueden usar para mostrar interacciones de
objetos durante ese período de tiempo.

Diagrama global de interacciones

Los diagramas generales o globales de interacción son muy similares a los
diagramas de actividad. Mientras que los diagramas de actividad muestran una
secuencia de procesos, los diagramas de interacción muestran una secuencia
de diagramas de interacción. En términos simples, pueden llamarse una
colección de diagramas de interacción y el orden en que suceden. Como se
mencionó anteriormente, hay siete tipos de diagramas de interacción, por lo que
cualquiera de ellos puede ser un nodo en un diagrama de vista general de
interacción.
Metodología RUP
La metodología RUP, abreviatura de Rational Unified Process (o Proceso
Unificado Racional), es un proceso propietario de la ingeniería de software
creado por Rational Software, adquirida por IBM , ganando un nuevo nombre
Irup que ahora es una abreviatura Rational Unified Process y lo que es una
marca en el área de software, proporcionando técnicas que deben seguir los
miembros del equipo de desarrollo de software con el fin de aumentar su
productividad en el proceso de desarrollo.

utiliza el enfoque de la orientación a objetos en su diseño y está diseñado y

documentado el uso de la notación UML (Unified Modeling Language) para
ilustrar los procesos en acción. Utiliza técnicas y prácticas probadas
comercialmente. Es un proceso considerado pesado y preferentemente aplicable
a grandes equipos de desarrollo y grandes proyectos, pero el hecho de que es
ampliamente personalizable que permite adaptarse a proyectos de cualquier
escala. Para la gestión del proyecto, la metodología RUP proporciona una
solución disciplinada como las tareas y responsabilidades señaladas dentro de
una organización de desarrollo de software. RUP es, en sí, un producto de
software. Es modular y automatizado, y toda su metodología se apoya en varias
herramientas de desarrollo integradas y vendidos por IBM a través de sus
«Suites racional.»
¿Qué es la metodología ágil?
El enfoque ágil para el desarrollo de software busca distribuir de forma
permanente sistemas de software en funcionamiento diseñados con iteraciones
rápidas. Sin embargo, la frase "metodología ágil" es engañosa porque implica
que el enfoque ágil es la única forma de abordar el desarrollo de software. La
metodología ágil no hace referencia a una serie de indicaciones sobre qué hacer
exactamente durante el desarrollo de software. Se trata más bien de una forma
de pensar en la colaboración y los flujos de trabajo, y define un conjunto de
valores que guían nuestras decisiones con respecto a lo que hacemos y a la
manera en que lo hacemos.
En concreto, las metodologías ágiles de desarrollo de software buscan
proporcionar en poco tiempo piezas pequeñas de sistemas de software en
funcionamiento para mejorar la satisfacción del cliente. Estas metodologías
utilizan enfoques flexibles y el trabajo en equipo para ofrecer mejoras constantes.
Por lo general, el desarrollo ágil de software implica que pequeños equipos auto
organizados de desarrolladores de software y representantes empresariales se
reúnan regularmente en persona durante el ciclo de vida del desarrollo de
software. La metodología ágil favorece un enfoque sencillo de la documentación
de software, y acepta los cambios que puedan surgir en las diferentes etapas del
ciclo de vida, en lugar de resistirse a ellos.

Los valores de la metodología ágil

La metodología ágil como la conocemos en la actualidad nació en el año 2001.
En respuesta a los enfoques en cascada de la gestión de proyectos, en que estos
se organizan como series de secuencias lineales, un grupo de desarrolladores
de software redactó el Manifiesto para el Desarrollo Ágil de Software. En este
documento, los programadores propusieron un nuevo enfoque de desarrollo de
software y describieron cuatro características fundamentales que se deberían
priorizar por encima de otras cuestiones. De acuerdo con lo que establecieron,
los equipos de desarrollo ágil de software deberían valorar:
 Las personas y las interacciones antes que los procesos y las
herramientas
 El software en funcionamiento antes que la documentación exhaustiva
 La colaboración con el cliente antes que la negociación contractual
 La respuesta ante el cambio antes que el apego a un plan
Los autores aclaran que todos los puntos de la lista anterior tienen cierto valor
inherente. Sin embargo, proponen que valorar los puntos de la izquierda (en
negrita) antes que los de la derecha puede dar lugar a mejores resultados en el
desarrollo del producto. El manifiesto no busca imponer un conjunto de prácticas,
sino ser una guía que permita pensar en el desarrollo de software de otra
manera.
Gracias a este manifiesto, se han obtenido varios resultados prácticos. Por
ejemplo, en lugar de desarrollar sistemas de software en una secuencia que va
de una fase a la siguiente (que es como el método cascada garantiza la calidad
de un producto), el método ágil promueve que los procesos de desarrollo y
prueba sean simultáneos y constantes. Dicho de otra forma, en el desarrollo en
cascada, una fase debe finalizarse por completo antes de poder pasar a la
siguiente; el desarrollo ágil, por otro lado, permite que varias secuencias sucedan
al mismo tiempo.

¿Dónde se originó el enfoque ágil?

Los enfoques ágiles de trabajo se crearon para abordar las limitaciones del
método en cascada, que se derivaba del sistema de cadena de montaje de 1913
que utilizó Henry Ford como método de fabricación, y que luego se aplicó al
desarrollo de software. Desde su origen en 2001, el desarrollo ágil pisa fuerte en
el sector de los sistemas de software y la gestión de proyectos, a pesar de sus
múltiples variantes.
 CONCLUSIONES
Se puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software, pero no especifica en sí
mismo qué metodología o proceso usar. Sin embargo, la frase «metodología
ágil» es engañosa porque implica que el enfoque ágil es la única forma de
abordar el desarrollo de software. La metodología ágil no hace referencia a una
serie de indicaciones sobre qué hacer exactamente durante el desarrollo de
software. La metodología ágil como la conocemos en la actualidad nació en el
año 2001.

En respuesta a los enfoques en cascada de la gestión de proyectos, en que estos

se organizan como series de secuencias lineales, un grupo de desarrolladores
de software redactó el Manifiesto para el Desarrollo Ágil de Software. En este
documento, los programadores propusieron un nuevo enfoque de desarrollo de
software y describieron cuatro características fundamentales que se deberían
priorizar por encima de otras cuestiones. De acuerdo con lo que
establecieron, los equipos de desarrollo ágil de software deberían valorar.
 BIBLIOGRAFIA

1) IBM Acquires Rational

2) "The Unified Software Development Process (ISBN 0-201-57169-2)" El
Proceso Unificado de Desarrollo de Software (ISBN 0-201-57169-2), publicado
en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh.
3) «Copia archivada». Archivado desde el original el 6 de enero de 2014.
Consultado el 18 de octubre de 2015.
4) Wikimedia Commons alberga una galería multimedia sobre Lenguaje
unificado de modelado.
5) Grupo Oficial del lenguaje Modelado (en inglés)
6) Especificación oficial (en inglés)
7) Especificación oficial (última versión disponible) (en inglés)
8) Introducción a UML 2.0, partes uno y dos
9) Listados de herramientas
10) Problemas de consistencia en software basado en UML (en inglés)
11) UMLZone (en inglés)