INSTITUTO TECNOLÓGICO SUPERIOR DE CALKINÍ

INGENIERÍA INFORMÁTICA

ACTIVIDAD:

11.- GESTIONAR LA INFORMACION SOBRE RUP & UML (AF)

ALUMNOS:
COB CHI JOSHUA NEFTALI
HAAS AGUAYO LUIS ANGEL
HIDALGO COB DANIEL ALBERTO
MOO MAY JONATAN ISRAEL

DOCENTE:
MARLENE MENDEZ MORENO

CALKINÍ, CAMPECHE 22 DE SEPTIEMBRE DE 2023

 INTRODUCCIÓN.

RUP es un marco de trabajo de desarrollo de software ampliamente utilizado en la

industria para gestionar proyectos de desarrollo de software de manera eficiente y
efectiva. RUP fue desarrollado por Rational Software Corporation, adquirida
posteriormente por IBM, y se ha convertido en un enfoque fundamental para el
desarrollo de software en equipos grandes y complejos.
El RUP se basa en principios de ingeniería de software sólidos y se enfoca en la
gestión del ciclo de vida completo del desarrollo de software, desde la concepción
y el diseño hasta la implementación y el mantenimiento. A lo largo de su evolución,
RUP ha incorporado las mejores prácticas de la industria y ha adaptado enfoques
ágiles y orientados a objetos, lo que lo hace altamente adaptable a diferentes
contextos y necesidades de proyectos.
UML es un lenguaje visual utilizado en ingeniería de software para representar y
comunicar conceptos y diseños relacionados con sistemas y procesos. UML se ha
convertido en un estándar de facto en la industria del desarrollo de software,
permitiendo a los profesionales de la tecnología expresar ideas y soluciones de
manera efectiva, independientemente de su complejidad.
UML es una herramienta valiosa en todo el ciclo de vida del desarrollo de
software, desde la concepción y el análisis hasta la implementación y el
mantenimiento. Además, promueve la comunicación efectiva entre los miembros
del equipo de desarrollo y otras partes interesadas, lo que ayuda a evitar
malentendidos y a garantizar que todos tengan una comprensión clara de los
requisitos y el diseño del sistema.
Proceso de desarrollo unificado – RUP.

Es una metodología de desarrollo de software que está basado en componentes e

interfaces bien definidas, y 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 proceso que puede especializarse para una gran variedad de sistemas de
software, en diferentes áreas de aplicación, diferentes tipos de organizaciones,
diferentes niveles de aptitud y diferentes tamaños de proyecto.

Historia

RUP fue creado por Grady Booch (creador del método Booch), Ivar Jacobson y
James Jacobson (Creador de la Técnica de Modelado de Objetos), la misma
aparece en junio de 1998 con el acrónimo RUP 5.0 y puesto a la disposición del
público a inicios de 1999 y su funcionamiento se centraba en las personas, los
procesos y las herramientas.
Su funcionalidad parte de una serie de métodos los cuales se puede comentar, el
método ericcson, método utilizado por la compañía del mismo nombre para el
proceso unificado de desarrollo, a este proceso se le anexa un proceso
denominado Objetory creado por Jacobson. En el año 1995 se anexa el enfoque
Rational dando paso a ROP 4.0 (Rational Objetory Process) que junto a la OMT
(Objects Modeling Technique) de Rumbaugh y Booch lo que permitió dar origen a
UML, esta herramienta fortaleció mucho más a ROP en el empleo de caso de
usos. Para el año 1996, surge ROP 4.1 con la integración de actividades SQA
(Software Quality Assurance, Software de Control de Calidad por sus siglas en
ingles), esto permitía el aseguramiento de un software de calidad que se adapte a
las necesidades del usuario final por medio de la actualización de UML. Para 1998
se lanza al mercado una fase de prueba, con un UML fortalecido y la integración
de los enfoques de la ingeniería de Negocios y la Ingeniería de Datos a partir de
aquí nace RUP, con los lineamientos y vertientes que hoy día conocemos.
Fases.

1. Fase de Inicio: Se enfoca 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 de la arquitectura.
Durante esta fase las iteraciones hacen mayor énfasis en actividades
modelado del negocio y los requisitos.

2. Fase de elaboración: Durante esta fase de elaboración, se centran al

desarrollo de los casos de uso tomando como base la de diseño, como lo
dice la elaboración lleva una serie de requerimientos una serie de pasos; el
modelo de la organización, el análisis y el diseño se van acumulando las
actividades y para empezar una parte de implementación mediante
desarrollo de la fase de inicio que va a ser orientada a la base de la
construcción de todas las especificaciones de la arquitectura del diseño.
Hasta obtener un diseño bien construido.

3. Fase de construcción: Durante la fase de construcción, se lleva a cabo la

construcción del producto por medio de una serie de iteraciones las cuales
se seleccionan algunos Casos de Uso, se define su análisis y después el
diseño y se procede a su implantación y sus respectivas pruebas. En esta
fase se realiza una serie de cascadas para cada ciclo, se realizan tantas
iteraciones hasta que se termine la nueva implementación y el producto
esté listo para ser enviado al usuario.

4. Fase de transición: Durante esta fase de transición se busca garantizar

que el producto este bien preparado para su entrega al usuario. Es una fase
que puede tener muchos cambios a la hora de la entrega.

Cada una de estas fases participan todas las diciplinas, pero dependiendo de la
fase el esfuerzo dedicado a una diciplina varia.
Lenguaje de modelado unificado – UML

Fue creado para forjar un lenguaje de modelado visual común y semántica rico
para la arquitectura, el diseño y la implementación de sistemas de software
complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones
mas allá del desarrollo de software.
El objetivo es capturar las partes esenciales del sistema mediante notaciones
gráficas, a esto se le conoce como “modelado visual”, el cual es independiente del
lenguaje de implementación (el lenguaje que se usará para codificar)
Es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos
que aparecen a fines de los 80's y principios de los 90s.UML es llamado un
lenguaje de modelado, no un método. Los métodos consisten de ambos de un
lenguaje de modelado y de un proceso.
Es comparable con planos usados en otros campos y consiste en diferentes tipos
de diagramas. En general los diagramas UML describen los límites, la estructura y
el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se
pueden usar para generar código en diversos lenguajes usando los diagramas
UML, esta guarda relación directa con el análisis y el diseño orientado objetos.

Historia

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los
conocía, habían desarrollado otras metodologías. Se asociaron para brindar
claridad a los programadores creando nuevos estándares. La colaboración entre
Grady, Booch y Rumbaugh fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos
UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones,
incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su
propio desarrollo de negocios. Ellos, junto con muchas otras personas y
compañías, establecieron los recursos necesarios para desarrollar un lenguaje de
modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para
el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye
información sobre UML 2.0 en la segunda edición de 2005.
Fases.

Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente.
A través del modelado de casos de uso, los actores externos que tienen interés en
el sistema son modelados con la funcionalidad que ellos requieren del sistema (los
casos de uso). Los actores y los casos de uso son modelados con relaciones y
tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y
casos de uso son descritos en un diagrama use-case. Cada use-case es descrito
en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del
sistema sin considerar la funcionalidad que se implementará. Un análisis de
requerimientos puede ser realizado también para procesos de negocios, no
solamente para sistemas de software.

Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que están presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
también se consideran en esta fase a través de los modelos dinámicos en UML.
Es importante notar que sólo se consideran clases que están en el dominio del
problema (conceptos del mundo real) y todavía no se consideran clases que
definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica.
Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
análisis son agregadas en esta fase. El diseño resulta en especificaciones
detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de
programación orientado a objetos. Cuando se crean los modelos de análisis y
diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a
código.

Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
típicamente ejecutadas por el programador. Las pruebas de integración integran
componentes y clases en orden para verificar que se ejecutan como se especificó.
Las pruebas de sistema ven al sistema como una "caja negra" y validan que el
sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptación conducidas por el cliente verifican que el sistema satisface los
requerimientos y son similares a las pruebas de sistema.

Elementos

 CLASE: Es la unidad básica que encapsula toda la información de un

Objeto (un objeto es una instancia de una clase). A través de ella podemos
modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente,
etc.).
En UML, una clase es representada por un rectángulo que posee tres
divisiones

 Superior: Contiene el nombre de la Clase

 Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).
 Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).
 ATRIBUTOS: Los atributos o características de una Clase pueden ser de
tres tipos, los que definen el grado de comunicación y visibilidad de ellos
con el entorno, estos son:

 Public (+): Indica que el atributo será visible tanto dentro como fuera de la
clase, es decir, es accsesible desde todos lados.
 Private (-): Indica que el atributo sólo será accesible desde dentro de la
clase (sólo sus métodos lo pueden accesar).
 Protected (#): Indica que el atributo no será accesible desde fuera de la
clase, pero si podrá ser accesado por métodos de la clase además de las
subclases que se deriven (ver herencia).

 MÉTODOS: Los métodos u operaciones de una clase son la forma en como

ésta interactúa con su entorno, éstos pueden tener las características:

 Public (+): Indica que el método será visible tanto dentro como fuera de la
clase, es decir, es accsesible desde todos lados.
 Private (-): Indica que el método sólo será accesible desde dentro de la
clase (sólo otros métodos de la clase lo pueden accesar).
 Protected (#): Indica que el método no será accesible desde fuera de la
clase, pero si podrá ser accesado por métodos de la clase además de
métodos de las subclases que se deriven (ver herencia).

 CARDINALIDAD:

 Uno o muchos: 1..* (1..n)

 0 o muchos: 0..* (0..n)
 Número fijo: m (m denota el número).

 HERENCIA (ESPCIALIZACION Y GENERALIZACION): Indica que una

subclase hereda los métodos y atributos especificados por una Super
Clase, por ende la Subclase además de poseer sus propios métodos y
atributos, poseerá las características y atributos visibles de la Super Clase
(public y protected).
 AGREGACION: Para modelar objetos complejos, n bastan los tipos de
datos básicos que proveen los lenguajes: enteros, reales y secuencias de
caracteres. Cuando se requiere componer objetos que son instancias de
clases definidas por el desarrollador de la aplicación, tenemos dos
posibilidades:

 Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del

objeto incluido está condicionado por el tiempo de vida del que lo incluye.
Este tipo de relación es comúnmente llamada Composición (el Objeto base
se construye a partir del objeto incluido, es decir, es "parte/todo").
 Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de
vida del objeto incluido es independiente del que lo incluye. Este tipo de
relación es comúnmente llamada Agregación (el objeto base utiliza al
incluido para su funcionamiento).

 ASOCIACION: La relación entre clases conocida como Asociación, permite

asociar objetos que colaboran entre si. Cabe destacar que no es una
relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro

 DEPENDENCIA O INSTALACIÓN: Representa un tipo de relación muy

particular, en la que una clase es instanciada (su instanciación es
dependiente de otro objeto/clase). Se denota por una flecha punteada.

 CLASE ABSTRACTA: Una clase abstracta se denota con el nombre de la

clase y de los métodos con letra "itálica". Esto indica que la clase definida
no puede ser instanciada pues posee métodos abstractos (aún no han sido
definidos, es decir, sin implementación). La única forma de utilizarla es
definiendo subclases, que implementan los métodos abstractos definidos.
 CLASE PARAMETRIZADA: Una clase parametrizada se denota con un
subcuadro en el extremo superior de la clase, en donde se especifican los
parámetros que deben ser pasados a la clase para que esta pueda ser
instanciada. El ejemplo más típico es el caso de un Diccionario en donde
una llave o palabra tiene asociado un significado, pero en este caso las
llaves y elementos pueden ser genéricos.
 CONCLUSIÓN

La RUP es un enfoque de desarrollo de software que ha desempeñado un papel

importante en la industria, especialmente en proyectos grandes y complejos.
Aunque ha evolucionado con el tiempo y sigue siendo relevante en algunos casos,
no es la única opción disponible y puede ser necesario personalizarla para
adaptarse a las necesidades específicas de un proyecto. La elección de un
enfoque de desarrollo debe basarse en las características del proyecto y las
preferencias del equipo de desarrollo.
UML es una herramienta poderosa y versátil que ha desempeñado un papel
fundamental en el desarrollo de software y la ingeniería de sistemas. Proporciona
una forma eficaz de comunicar y visualizar conceptos complejos, y su estatus
como estándar de la industria lo hace ampliamente reconocido y utilizado en todo
el mundo. Sin embargo, es importante recordar que UML es una herramienta y un
lenguaje, y su efectividad depende de cómo se aplique en el contexto de un
proyecto específico y de la comprensión de los principios de modelización.
 REFERENCIAS

Cornejo, J. E. (Enero de 2008). El Lenguaje de Modelado Unificado. Obtenido de docIRS:

https://www.docirs.cl/uml.asp

EL LENGUAJE UNIFICADO DE MODELADO (UML). (s.f.). Obtenido de UNAM: http://profesores.fi-

b.unam.mx/carlos/aydoo/uml.html#:~:text=Las%20fases%20del%20desarrollo%20de,%2C
%20Dise%C3%B1o%2C%20Programaci%C3%B3n%20y%20Pruebas.

Monsivais, E. G. (s.f.). UML : Lenguaje de Modelado Unificado. Obtenido de ITESRC:

https://www.itesrc.edu.mx/portal/articles.php?id_art=1#:~:text=El%20UML%20fue
%20desarrollado%20por,grupo%20con%20sus%20consecuentes%20versiones.

Proceso unificado de desarrollo. (s.f.). Obtenido de EcuRed:

https://ecured.cu/Proceso_unificado_de_desarrollo#Un_poco_de_historia

Proceso Unificado Rational (RUP). (03 de Abril de 2011). Obtenido de

http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/
A8%20Cap%C3%ADtulo%205.pdf?sequence=8.

Process, R. U. (Diciembre de 2012). Metodología RUP. Obtenido de blogspot:

http://rupequipo1.blogspot.com/2012/12/algo-de-historia.html

Qué es el lenguaje unificado de modelado (UML). (s.f.). Obtenido de Lucidchart:

https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml