Alumnos:

Jacqueline Borbón Torres

David Esteban Contreras Loreto

José Alberto De La Rosa De La Fuente

Jorge Isaac Flores López

Manuel Antonio Higuera Campaña

Rosa Belem Molina Ramírez

Francisco Guadalupe Moreno Romero

Ernesto Alejandro Orozco Rodríguez

Carrera:

Ing. En Sistemas Computacionales

Materia:

Planificación y Modelado

Docente:

Héctor David López Páez

INTRODUCCIÓN

Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho

tiempo la representación de los diseños de forma gráfica. Desde los inicios de la

informática se han estado utilizando distintas formas de representar los diseños de

una forma más bien personal o con algún modelo gráfico. La falta de estandarización

en la manera de representar gráficamente un modelo impedía que los diseños

gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores.

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros

desarrolladores sino también para servir de apoyo en los procesos de análisis de un

problema. Con este objetivo se creó el proceso de desarrollo de software, RUP

(Rational Unified Process), que junto con el Lenguaje Unificado de Modelado

(Unified Modeling Language), constituye la metodología estándar más utilizada para

el análisis, implementación y documentación de sistemas orientados a objetos. UML

se ha convertido en ese estándar tan ansiado para representar y modelar la

información con la que se trabaja en las fases de análisis y, especialmente, de

diseño.

El lenguaje UML tiene una notación gráfica muy expresiva que permite representar

en mayor o menor medida todas las fases de un proyecto informático: desde el

análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc.,

hasta la implementación y configuración con los diagramas de despliegue.

2

JUSTIFICACIÓN

Con la introducción de los lenguajes orientados a objetos, surge la necesidad de

implementar nuevas técnicas de diseño y análisis. Es aquí donde entran en uso el

lenguaje UML y RUP.

OBJETIVO

Dar a conocer las características y utilidad del lenguaje UML y su metodología RUP,

desde sus orígenes hasta el día de hoy.

FUNDAMENTO TEÓRICO

¿CÓMO Y POR QUÉ SURGE UML?

Tras la aparición de los lenguajes orientados a objetos se buscaron nuevas

metodologías que permitiesen el análisis y diseño de aplicaciones bajo dichos

lenguajes; estas metodologías fueron los primeros lenguajes de modelado orientados

a objetos. Al no poder cubrir éstos todas las necesidades de los desarrolladores,

surgió una nueva generación de lenguajes más potentes, liderados por el método de

Booch, el método OOSE de Jacobson y el método OMT de Rumbaugh; cada uno de

estos métodos destacaba en algunos puntos pero fallaba en otros.

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando James Rumbaugh

se unió a la compañía Rational fundada por Grady Booch (dos reputados

investigadores en el área de metodología del software). El objetivo de ambos era

3

unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object

Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma

época otro reputado investigador, Ivar Jacobson, se unió a Rational y se incluyeron

ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además,

este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus

ideas. Todas estas colaboraciones condujeron a la definición de la primera versión

de UML. La versión 1.0 de UML surgió en 1997 con la contribución de IBM, HP,

Oracle, Microsoft y otras organizaciones.

El desarrollo de UML continúa actualmente bajo el control de IBM (que adquirió

Rational); la última versión de UML es la 2.0.

MODELADO VISUAL

Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una

simplificación de la realidad. El objetivo del modelado de un sistema es capturar las

partes esenciales del sistema. Para facilitar este modelado, se realiza una

abstracción y se plasma en una notación gráfica. Esto se conoce como modelado

visual.

El modelado visual permite manejar la complejidad de los sistemas a analizar o

diseñar. De la misma forma que para construir una choza no hace falta un modelo,

cuando se intenta construir un sistema complejo como un rascacielos, es necesario

abstraer la complejidad en modelos que el ser humano pueda entender.

4

UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de

los sistemas de software como para la arquitectura hardware donde se ejecuten.

Otro objetivo de este modelado visual es que sea independiente del lenguaje de

implementación, de tal forma que los diseños realizados usando UML se puedan

implementar en cualquier lenguaje que soporte las posibilidades de UML

(principalmente lenguajes orientados a objetos).

UML es además un método formal de modelado. Esto aporta las siguientes ventajas:

Mayor rigor en la especificación.

Permite realizar una verificación y validación del modelo realizado.

Se pueden automatizar determinados procesos y permite generar código a

partir de los modelos y a la inversa (a partir del código fuente generar los

modelos). Esto permite que el modelo y el código estén actualizados, con lo

que siempre se puede mantener la visión en el diseño, de más alto nivel, de la

estructura de un proyecto.

¿QUÉ ES UML?

UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas

para permitir una comunicación. En este caso, este lenguaje se centra en la

representación gráfica de un sistema.

Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos.

Esto último es el objetivo de las metodologías de desarrollo.

5

Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

Visualizar: UML permite expresar de una forma gráfica un sistema de forma

que otro lo puede entender.

Especificar: UML permite especificar cuáles son las características de un

sistema antes de su construcción.

Construir: A partir de los modelos especificados se pueden construir los

sistemas diseñados.

Documentar: Los propios elementos gráficos sirven como documentación del

sistema desarrollado que pueden servir para su futura revisión.

Aunque UML está pensado para modelar sistemas complejos con gran cantidad de

software, el lenguaje es los suficientemente expresivo como para modelar sistemas

que no son informáticos, como flujos de trabajo (workflow ) en una empresa, diseño

de la estructura de una organización y por supuesto, en el diseño de hardware.

Un modelo UML está 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 diferencia entre UML y los lenguajes de programación normales es que UML es

un lenguaje que utiliza gráficos para describir objetos. UML también es utilizado para

describir patrones de diseño que pueden ser aplicados al entorno .NET.”

6

DIAGRAMAS UML

Un diagrama es la representación gráfica de un conjunto de elementos con sus

relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para

poder representar correctamente un sistema, UML ofrece una amplia variedad de

diagramas para visualizar el sistema desde varias perspectivas. UML incluye los

siguientes diagramas:

Diagramas de estructura:

• Diagrama de clases.

Diagrama de componentes.

• Diagrama de objetos

• Diagrama de estructura compuesta

• Diagrama de despliegue

• Diagrama de paquetes

Diagramas de comportamiento:

Diagrama de actividades

Diagrama de casos de uso

Diagrama de estados

Diagramas de interacción:

Diagrama de secuencia

Diagrama de comunicación

7

Diagrama de tiempos

Diagrama de vista de interacción

Los diagramas más interesantes (y los más usados) son los de casos de uso, clases

y secuencia, por lo que nos centraremos en éstos. El diagrama de casos de uso

representa gráficamente los casos de uso que tiene un sistema. Se define un caso

de uso como cada interacción supuesta con el sistema a desarrollar, donde se

representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que

hacer un sistema y cómo. El diagrama de clases muestra un conjunto de clases,

interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el

diseño de los sistemas orientados a objetos.

En el diagrama de secuencia se muestra la interacción de los objetos que componen

un sistema de forma temporal.

El resto de diagramas muestran distintos aspectos del sistema a modelar. Para

modelar el comportamiento dinámico del sistema están los de interacción,

colaboración, estados y actividades. Los diagramas de componentes y despliegue

están enfocados a la implementación del sistema.

8

¿QUÉ ES RUP?

Es un proceso de desarrollo de software:

Forma disciplinada de asignar tareas y responsabilidades en una empresa de

desarrollo (quién hace qué, cuándo y cómo).

Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología

estándar más utilizada para el análisis, implementación y documentación de

sistemas orientados a objetos.

Es un conjunto de metodologías adaptables al contexto y necesidades de

cada organización.

RUP es una guía de cómo usar UML de la forma más efectiva.

¿CUÁLES SON LOS CICLOS Y FASES QUE INTERVIENEN EN RUP?

RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada

ciclo.

Cada ciclo se divide en 4 fases:

INICIO:

Establece la oportunidad y alcance el proyecto.

ELABORACIÓN:

Analizar el dominio del problema

Establecer una arquitectura base sólida

Desarrollar un plan de proyecto

9

Eliminar los elementos de mayor riesgo para el desarrollo exitoso del

proyecto

CONSTRUCCIÓN O DESARROLLO:

En esta fase todas las componentes restantes se desarrollan e

incorporan al producto.

TRANSICIÓN O CIERRE:

Se debe verificar que el producto cumpla con las especificaciones

entregadas por las personas involucradas en el proyecto.

¿QUÉ SON LOS ROLES?

Un Rol define el comportamiento y las responsabilidades de un individuo.

Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de

cada uno y el resultado (artefactos) que se espera de ellos.

Todos los miembros del equipo comparten:

Base de conocimiento

Proceso

Vista de cómo desarrollar software

Lenguaje de modelamiento (UML)

10

¿QUÉ SON LAS ACTIVIDADES?

Una actividad es una unidad de trabajo que se asigna a un trabajador y lleva entre un

par de horas y un par de días, involucra un solo trabajador y un número pequeño de

artefactos.

¿QUÉ SON ARTEFACTOS?

RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una

serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño

del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

INICIO:

Documento Visión

Especificación de Requisitos

ELABORACIÓN:

11

Diagramas de caso de uso

CONSTRUCCIÓN:

Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LÓGICA:

Diagrama de clases

Modelo E-R (Si el sistema así lo requiere)

VISTA DE IMPLEMENTACIÓN:

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboración

VISTA CONCEPTUAL:

Modelo de dominio

VISTA FÍSICA:

Mapa de comportamiento a nivel de hardware.

12

¿CUÁLES SON LOS PRINCIPIOS DE DESARROLLO DE RUP?

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso

El proceso deberá adaptarse a las características propias del proyecto u

organización. El tamaño del mismo, así como su tipo o las regulaciones que lo

condicionen, influirán en su diseño específico. También se deberá tener en cuenta el

alcance del proyecto en un área subformal.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o

disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los

deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan

en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En

cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del

producto, y se refina la dirección del proyecto así como también los riesgos

involucrados

13

Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe

haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones,

planes, resultados, etc.

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón

del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar

algunos. Esto evita que los ingenieros de software vayan directamente de los

requisitos a la codificación de software a la medida del cliente, sin saber con certeza

qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde

un principio pensando en la reutilización del código. Un alto nivel de abstracción

también permite discusiones sobre diversos niveles y soluciones arquitectónicas.

Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por

ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los

aspectos de la producción. El aseguramiento de la calidad forma parte del proceso

de desarrollo y no de un grupo independiente

14

ORÍGENES DE RUP

Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken

Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la

investigación. En 1995 Rational Software compró una compañía sueca llamada

Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos

de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process

fue el resultado de una convergencia de Rational Approach y Objectory (el proceso

de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational

Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998,

siendo el arquitecto en jefe Philippe Kruchten.

CONCLUSIÓN

Nosotros como equipo consideramos que RUP junto con UML, es una metodología

muy completa, de la cual nos dimos cuenta que posee extensa información con lo

que pudimos comprender que UML y RUP son, aunque ambas distintas cosas,

herramientas que juntas ayudan a crear modelos bastante bien estructurados acerca

de un sistema.

UML es un lenguaje visual y modelado, ofrece varios diagramas para representar

ideas.

RUP es un modelo o proceso de desarrollo de software, se basan en desarrollo

incremental y suele ser difícil si no se cuenta con la documentación adecuada y

suficiente.

RUP usa UML para llevar la documentación del sistema, facilitar la etapa de diseño y

desarrollo, a las ideas y a ayudar al equipo a comunicarlas.

15

FUENTES DE INFORMACIÓN

http://www.wikipedia.org

http://html.rincondelvago.com

http://www.rational.com.ar/herramientas/rup.html

http://www.planetacodigo.com/wiki/glosario:uml

http://www.alegsa.com.ar/Dic/uml.php

http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.

%20XP.pdf

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

http://setepro.googlecode.com/files/Introducción a RUP .ppt

http://www.monografias.com/trabajos16/lenguaje-modelado-unificado/

lenguaje-modelado-unificado.shtml

Enterprise Development with Visual Studio .NET, UML, and MSF

by John Erik Hansen and Carsten Thomsen 

G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado",

Addison Wesley, 1999

Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo",

Addision Wesley, 2000

E. Hernández, J. Hernández, C. Lizandra, "C++ Es-tandar", ITP Paraninfo

2001

El Lenguaje Unificado de Modelado (UML) - Enrique Hernández Orallo

16