Capitulo 2 - Introducción Al RUP y Al UML

Introducción al RUP y al UML
Al finalizar el capítulo, el alumno podrá:
 Aplicar el ciclo de vida del software usando la metodología RUP.

 Reconocer los elementos del lenguaje de Modelamiento UML.
Temas:
1. Metodologías y estándares en el desarrollo de software.

2. Introducción al RUP.
3. Introducción al UML.
Programa UML 2.4.1 for Developer- Enterprise Architect

Introducción al RUP y al UML 24
1. Metodologías y estándares en el desarrollo de software
1.1 Introducción
 Ciclo de Vida del Software
El término ciclo de vida del software describe el desarrollo de software, desde

la fase inicial hasta la fase final.
Un proceso de desarrollo de software es un conjunto de actividades y
resultados asociados que producen un producto de software.
Ian Sommerville define cuatro actividades fundamentales de procesos que son
comunes para todos los procesos de software.
a. Especificación del software, donde los clientes e ingenieros definen el

software a producir y las restricciones sobre su operación.
b. Desarrollo del software, donde el software se diseña y se programa.
c. Validación del software, donde el software se válida para asegurar que
es lo que el cliente requiere.
d. Evolución del software, donde el software se modifica para adaptarlo a

los cambios requeridos por el cliente y el mercado
En general, se considera que los desarrolladores de software consideran

el siguiente ciclo de vida básico.
- Definición de objetivos: definir el resultado del proyecto y su papel

en la estrategia global.
- Análisis de los requisitos y su viabilidad: recopilar, examinar y
formular los requisitos del cliente, así como, examinar cualquier
restricción que se pueda aplicar.
- Diseño general: requisitos generales de la arquitectura de la
aplicación.
- Diseño en detalle: definición precisa de cada subconjunto de la
aplicación.
- Programación (programación e implementación): es la
implementación de un lenguaje de programación para crear las
funciones definidas durante la etapa de diseño.
- Prueba de unidad: prueba individual de cada subconjunto de la
aplicación para garantizar que se implementaron, de acuerdo con las
especificaciones.
- Integración: para garantizar que los diferentes módulos se integren
con la aplicación. Éste es el propósito de la prueba de integración que
está cuidadosamente documentada.
- Prueba beta (o validación), para garantizar que el software cumple
con las especificaciones originales.
- Documentación: sirve para documentar información necesaria para
los usuarios del software y para desarrollos futuros.
- Implementación
- Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias del
software (mantenimiento continuo).
 Tipos de Procesos
Un proceso de ciclo de vida define el alcance de un proceso y su relación entre

sus actividades. Scott W. Ambler, en su libro “The Enterprise Unified Process:
Extending the Rational Unified Process”, clasifica los ciclos de vida de procesos
como sigue:
Ciclo de Vida Organización/Negocio: Empresa
Ciclo de Vida de la Tecnología de la Información
Ciclo de Vida del Sistema
Ciclo de Vida
Desarrollo Software
a. Ciclo de Vida de Desarrollo Software

Incluye las actividades necesarias para desarrollar un sistema y colocar el
mismo en producción.
Ejemplos:
 RUP
 Extreme Programming (XP)
b. Ciclo de vida del sistema

Extiende el desarrollo para incluir actividades requeridas para operar y
soportar un sistema después de su puesta en producción y el eventual
retiro de un sistema anterior.
Ejemplo:
 ISO 12207 standard (ISO 1998) define un ciclo de vida del
sistema de alto nivel.
c. Ciclo de Vida de Tecnología de Información (TI)

Incluye las actividades de un departamento de TI; añade disciplinas
requeridas para manejar adecuadamente el portafolio de sistemas de una
empresa.
Ejemplos:
 EUP (Enterprise Unified Process)
d. Ciclo de vida del Negocio u organización

Incluye las actividades completas de una organización, incluye ambas: las
de TI y aspectos de negocio.
Para que sea efectivo, el ciclo de vida de TI debe encajar en el ciclo de
vida de la organización.
1.2 Metodologías
Concepto
Una metodología es un conjunto de métodos que se utilizan para desarrollar una

actividad con el objetivo de formalizarla y optimizarla.
Metodologías vs. Ciclo de vida
Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el
ciclo de vida indica qué es lo que se ha de obtener a lo largo del desarrollo del
proyecto, pero no cómo hacerlo
La metodología indica cómo hay que obtener los distintos productos parciales y
finales
Generaciones de las Metodologías
Desde los inicios del desarrollo de software se consideran las siguientes tres
generaciones:
 Desarrollo convencional.
 Desarrollo estructurado.
 Desarrollo orientado a objetos.
1.2.1. Elementos de una metodología
Una metodología considera los siguientes elementos:
 Ciclo de vida: secuencia ordenada del desarrollo completo (cascada,

prototipo, espiral)
 Productos: documentos, entregables, evidencias, etc.
 Procedimientos y herramientas: ¿cómo?, ¿con qué?
 Criterios de evaluación: ¿cómo nos fue?
1.2.2. Características de una metodología
 Existencia de reglas predefinidas.

 Cobertura total del ciclo de desarrollo.
 Verificaciones intermedias.
 Planificación y control.
 Comunicación efectiva.
 Utilización sobre un abanico amplio de proyectos.
 Fácil formación.
 Herramientas case.
 Actividades que mejoren el proceso de desarrollo.
 Soporte al mantenimiento.
 Soporte de la utilización de software.
1.2.3. Usos de las metodologías
Desde el punto de vista de Desde el punto de vista Desde el punto de vista del
administración del desarrollo cliente
 Facilita la planificación.  Comprensión del  Garantiza la calidad del

 Facilita el control y problema. producto.
seguimiento de los  Optimización del  Mayor confianza.
proyectos. proceso y dentro del
 Mejora la relación proceso, las fases a
costo/beneficio. seguir.
 Optimiza el uso de recursos.  Facilidad de
 Facilita la comunicación mantenimiento.
entre los participantes.  Mejora de la
 Facilita la evaluación de los reusabilidad.
proyectos.
1.3 Clasificación de las Metodologías

Un proceso de software detallado y completo suele denominarse “Metodología”. Las
metodologías se basan en una combinación de los modelos de proceso genéricos
(cascada, evolutivo, incremental, etc.).
Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y

guías asociadas, que son aplicables a algunas actividades del proceso de
desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
Se consideran 3 clases de metodologías:
1. Metodologías Estructuradas
Comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada;
luego a mediados de los 70’s, aparecieron técnicas para el Diseño primero y
después, para el Análisis.
Están orientadas a procesos, datos y mixtas. Crea los modelos de forma
descendente.
Ejemplos:
- MERISE (Francia),
- MÉTRICA (España),
- SSADM (Reino Unido).
2. Metodologías Tradicionales
Son aquellas que están guiadas por una fuerte planificación durante todo el proceso
de desarrollo. Se realiza una intensa etapa de análisis y diseño antes de la
construcción del sistema.
Ejemplo:
- RUP (Rational Unified Process)
3. Metodologías Ágiles
Un proceso es ágil cuando el desarrollo de software suele ser:
- Incremental: entregas pequeñas de SW, con ciclos rápidos.

- Cooperativo: cliente y desarrolladores trabajan juntos constantemente
con una cercana comunicación.
- Sencillo: el método en sí mismo es fácil de aprender y modificar, bien
documentado.
- Adaptable: permite realizar cambios de último momento.
Características de una metodología ágil:
- Individuos y sus interacciones son más importantes que procesos y

herramientas.
- Software que funcione es más importante que documentación
exhaustiva.
- Colaboración con el cliente, en lugar de negociación de contratos.
- Respuesta ante el cambio en vez de seguir un plan cerrado.
Ejemplo:
- XP (eXtreme Programming)
1.3.1 Métrica
Es una metodología de planificación, desarrollo y mantenimiento de

sistemas de información, promovida por el Ministerio de Administraciones
Públicas del Gobierno de España para la sistematización de actividades del
ciclo de vida de los proyectos software en el ámbito de las administraciones
públicas.
Está basada en el modelo de procesos del ciclo de vida de desarrollo
ISO/IEC 12207 (Information Technology - Software Life Cycle Processes)
así como, en la norma ISO/IEC 15504 SPICE (Software Process
Improvement And Assurance Standards Capability Determination).
Objetivos:
- Proporcionar o definir sistemas de Información que ayuden a conseguir

los fines de la organización mediante la definición de un marco
estratégico para el desarrollo de los mismos.
- Mejorar la productividad de los departamentos de sistemas y tecnologías
de la información y las comunicaciones, permitiendo una mayor
capacidad de adaptación a los cambios y teniendo en cuenta, la
reutilización, en la medida de lo posible.
- Facilitar la comunicación y entendimiento entre los distintos participantes
en la producción de software.
- Facilitar la operación, mantenimiento y uso de los productos de software
obtenido.
Estructura:
Métrica 3 se divide en procesos principales (relativos a la planificación,

desarrollo y mantenimiento) e interfaces (procesos asociados al desarrollo:
gestión de la configuración, de proyectos y aseguramiento de la calidad).
Asimismo, cada proceso se divide en actividades y cada actividad tiene una
descripción y una tabla de tareas propias de la actividad. Además, cada
tarea tiene la correspondiente descripción y define los productos que
necesita de entrada, los que produce de salida, las prácticas necesarias

para llevar a cabo la tarea y los participantes.
Métrica 3 es flexible en su estructura porque no es obligatorio seguir todos

los procesos o actividades, pues se adapta en función de las necesidades
de cada proyecto. Tampoco es necesario seguir las actividades
secuencialmente, en ocasiones será factible su ejecución en paralelo.
MÉTRICA V3
PROCESOS INTERFACES
Planificación Mantenimiento -Gestión de Proyectos (GP)

Desarrollo
(PSI) (MSI)
Gestión de la Configuración
(GC)
- Estudio de viabilidad (EVS)
Seguridad (SEG)
- Análisis del SI (ASI)
Aseguramiento de la Calidad
- Diseño del SI (DSI)
(CAL)
- Construcción del SI (CSI)
- Implantación y aceptación
del SI (IAS)
a. Procesos
 Planificación (PSI).
 Desarrollo de Sistemas de Información.
- Estudio de Viabilidad del Sistema (EVS).
- Análisis del Sistema de Información (ASI).
- Diseño del Sistema de Información (DSI).
- Construcción del Sistema de Información (CSI).
- Implantación y Aceptación del Sistema (IAS).
 Mantenimiento de Sistemas de Información (MSI).
En una única estructura la metodología Métrica Versión 3, cubre distintos

tipos de desarrollo: estructurado y orientado a objetos, facilitando a través
de interfaces la realización de los procesos de apoyo u organizativos:
gestión de proyectos, gestión de configuración, aseguramiento de calidad
y seguridad.
b. Interfaces
 Gestión de Proyectos (GP)

 Seguridad (SEG)
 Aseguramiento de la Calidad (CAL)
 Gestión de la Configuración (GC)
1.3.2 RUP (Rational Unified Process)
Es un proceso de ingeniería de software, que guía las actividades de los

diferentes equipos de trabajo. Propone qué y cuándo desarrollar. Su
objetivo es asegurar la producción de software de calidad:
- Que satisfaga los requerimientos del usuario.

- En tiempo y presupuesto predecible.
Es un producto de Rational Software Corp adquirido por IBM. RUP

incorpora las mejores prácticas para el desarrollo de software de una
manera adaptable a un amplio rango de proyectos y entornos.
Se divide en dos dimensiones:
 Eje horizontal: representa el tiempo y muestra las etapas del ciclo

de vida del proceso.
Muestra los aspectos dinámicos del proceso, expresándolos en
términos de ciclos, fases, iteraciones e hitos.
 Eje vertical: representa los workflows de los procesos principales,
agrupando las actividades, según su naturaleza.
Muestra el aspecto estático del proceso: lo describe en términos de
componentes, actividades, workflows, artefactos y personas.
Características:
- Desarrollo iterativo.
- Administración de requerimientos.
- Usa UML (Unified Modeling Language)
- Produce artefactos.
- Arquitectura basada en componentes.
- Modelamiento visual.
- Proceso complejo.
- Es un marco de trabajo.
- Configurable y adecuado para proyectos medianos y grandes.
1.3.2.1 Extreme Programming
La metodología de Extreme Programming (XP) es relativamente nueva y

polémica, porque ataca frontalmente muchos de los principios asentados en
la Ingeniería del software y defiende, como su nombre bien dice, una serie
de principios “extremos” y que en su primera lectura parece completamente
irrealista. A menudo se confunde con lo que algunas veces se llama “code
and fix”, es decir, el ponerse a programar directamente, sin un proceso de
ingeniería, muchas veces incluso, sin contar con una especificación de
requisitos inicial.
El principal objetivo de
XP consiste en controlar
un problema
fundamental en el
desarrollo de software:
la alta volatilidad,
especificaciones
incompletas cambios y
falta de cultura del
negocio. Esto hace que
los desarrolladores
tarden en entender el
sistema que deben
desarrollar. XP ataca
este problema mediante
ciclos de iteración
extremadamente cortos en los cuales se añade muy poca funcionalidad,
construyendo un sistema completo que posiblemente se utilice incluso, en
producción; permitiendo a los desarrolladores, asimilar la problemática de
una forma más natural. Por otra parte, exige una alta implicación de los
usuarios en el desarrollo para crear un auténtico clima de trabajo en equipo.
En este sentido, el ciclo de vida del Extreme Programming se puede ver

como el ciclo de vida orientado a prototipos evolutivos llevado al extremo,
unido a una serie de principios particulares de esta metodología. Para que
el elevado ritmo de integraciones no produzca un sistema degenerado, se
enfatizan especialmente las pruebas de unidad y prestar una atención alta a
la calidad del código, y la necesidad de diseños sencillos. Además, se debe
partir de un diseño de base relativamente estable, ya que los fundamentos
del diseño no pueden cambiar continuamente.
A grandes rasgos, Extreme Programming permite que:
 Los requerimientos se especifican continuamente y se plasman en las

“user stories” que deben ser documentos mucho más ligeros que las
especificaciones de requisitos clásicos, en los que los usuarios
cuentan, en dos o tres fases y un lenguaje no técnico relativamente
informal, cada funcionalidad.
 Entregar un número alto de versiones con, relativamente, pocas
funcionalidades nuevas.
 Mantener el mayor nivel de rotación entre tareas del proyecto con el fin
de que no hayan personas que concentren todo el conocimiento de un
área y supongan así, un alto riesgo.
 Máxima simplicidad en el diseño.
 Utilizar “chapuzas” controladas para reducir riesgos, es decir, probar

conceptos con pequeños módulos o programas rápidos para medir su
viabilidad y tirarlos luego.
 No añadir funcionalidad de detalle al principio, sino mantener la
funcionalidad en el nivel más básico posible.
 Aplicar técnicas de refactoring (reconstrucción o reestructuración de
código de una manera disciplinada con el fin de eliminar código
obsoleto de un proyecto siempre que sea aconsejable).
 El cliente debe estar siempre disponible.
 Programar antes el código de las pruebas unitarias que el código del
producto en sí.
 Propiedad colectiva del código. Esto va unido al hecho de rotar los
desarrolladores entre áreas.
 Dejar las optimizaciones para el final.
 No trabajar en exceso. El razonamiento es que las implicaciones
negativas sobre la motivación del equipo descompensan las posibles
ganancias de tiempo.
 Todo el código debe tener sus pruebas de unidad y no podrá ser
puesto en producción hasta pasarlas todas.
 Uso intensivo de tests de aceptación.
Este modelo se muestra en la siguiente figura:
Ciclo de vida de un proyecto al que se aplica la metodología de Extreme Programming.
Iteración
Detalle del trabajo en una iteración en el Extreme Programming.

En la figura se aprecia que la iteración en el Extreme Programming está

orientado a ciclos muy cortos, de días.
La polémica está servida y se centra en dos aspectos principalmente: los
costes de desarrollo que genera este modelo de trabajo y la viabilidad de la
idea del “código colectivo”.
Ventajas:
 Parte de una visión muy realista en el sentido que considera la realidad
en los desarrollos con los clientes. Así, por ejemplo, tiene en cuenta la
dinámica con los clientes en la cual disponer de una definición
razonablemente completa de funcionalidad del producto suele ser pura
ficción.
 Extreme Programming enfatiza especialmente la importancia el diseño
simple y la importancia de las pruebas, un punto especialmente
descuidado en el desarrollo.
 Aporta algunas ideas “refrescantes” que son útiles como principios
incluso sin aplicar la metodología en sí. La programación en parejas es
un buen ejemplo, o los “stand up meetings”.
Inconvenientes:
 La metodología no es escalable, solamente puede tener sentido en
proyectos relativamente pequeños, según XP proyectos de entre 2 y 12
desarrolladores.
 Algunos de los principios parecen demasiado extremos y no gozan de
un respaldo con argumentos sólidos por los defensores de esta
metodología. Por ejemplo, el principio de la programación colectiva, es
decir, que todos puedan tocar en todas partes; este es un punto que
genera mucho debate porque el peligro de una evolución anárquica de
las funcionalidades de los módulos parece alta y muy difícilmente
controlable. Otro ejemplo es el refactoring, la misma metodología pide
cierta estabilidad en el diseño base, pero a la vez enfatiza la necesidad
de refactoring, dos principios que entran fácilmente en conflicto, pero
no aporta criterios claros para saber dónde situar punto de equilibrio
entre ambos.
 La metodología no responde con soluciones o con sugerencias a
muchos los problemas que plantean sus principios, lo cual da una
impresión de encontrarse aún en un estado relativamente hipotético.
1.4 Marco de Trabajo

En la web, Wikipedia muestra una definición general para el concepto Marco de
trabajo o Framework:
“La palabra inglesa "framework" define, en términos generales, un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de
problemática particular que sirve como referencia, para enfrentar y resolver
nuevos problemas de índole similar.”
En líneas generales, se tienen marcos de trabajo para varios ámbitos.

1.4.1 SCRUM
En palabras de Ken Schwaber: “Scrum no es una metodología, es un

marco de trabajo. Eso quiere decir que Scrum no dice exactamente, lo que
se debe hacer”.
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el

desarrollo de software. El desarrollo se realiza en forma iterativa e
incremental (una iteración es un ciclo corto de construcción repetitivo).
Cada ciclo o iteración termina con una pieza de software ejecutable que
incorpora nueva funcionalidad.
Las iteraciones en general, tienen una duración entre 2 y 4 semanas.
Scrum se utiliza como marco para otras prácticas de ingeniería de

software como RUP o Extreme Programming.
En Scrum, el equipo se focaliza en una única cosa: construir software de

calidad. Por otro lado, la gestión de un proyecto Scrum se focaliza en
definir cuáles son las características que debe tener el producto a construir
(qué construir, qué no y en qué orden) y en remover cualquier obstáculo
que pudiera entorpecer la tarea del equipo de desarrollo. Además, tiene un
conjunto de reglas muy pequeño y simple, basado en los principios de
inspección continua, adaptación, auto-gestión e innovación.
1.4.2 TOGAF
Es un framework de Arquitectura Empresarial que proporciona un enfoque

para el diseño, planificación, implementación y gobierno de una
arquitectura empresarial de información.
TOGAF se basa en cuatro dimensiones:
- Arquitectura de Negocios (o de Procesos de Negocio): define la

estrategia de negocios, la gobernabilidad, la estructura y los procesos
clave de la organización.
- Arquitectura de Aplicaciones: provee un plano para cada uno de
los sistemas de aplicación que se requiere implantar, las
interacciones entre estos sistemas y sus relaciones con los procesos
de negocio centrales de la organización.
- Arquitectura de Datos: describe la estructura de los datos físicos y

lógicos de la organización, y los recursos de gestión de estos datos.
- Arquitectura Tecnológica: describe la estructura de hardware,
software y redes requerida para dar soporte a la implantación de las
aplicaciones principales, de misión crítica, de la organización.
1.5 Estándares de la Industria
1.5.1 CMMI
El Modelo de Madurez y Capacidad Integrado (CMMI) es un conjunto

de prácticas y técnicas importantes que pueden ser implantadas por
cualquier entidad empresarial o de cualquier otra índole que
desarrolla o mantiene software, que desee entrar a un esquema de
mejora continua de procesos.
Publicado por el software Engineering Institute de la Universidad

Carnegie Mellon, ha sido usado ampliamente por la comunidad del
software para evaluar la madurez de los procesos del software
usados en compañías y agencias, para desarrollar planes de
mejoramiento, o como un manual de referencia para establecer
prácticas más maduras y más seguras.
Características:
- El Modelo de Madurez de Capacidades (Capability Maturity

Model) es un marco de trabajo que describe los elementos
claves de un proceso de software eficaz.
- Describe un camino de mejoramiento evolutivo para pasar
desde un proceso inmaduro a un proceso maduro y
disciplinado.
- Basado en conocimientos adquiridos de evaluaciones de los
procesos de software y extensos feedback con industrias y el
gobierno.
La primera publicación de CMM fue revisada y usada por la

comunidad de software durante 1991 y 1992. La versión 1.1 fue
publicada en 1993 y en 1996 fue liberada la versión 2, que evolucionó
integrando diferentes métodos en la mejora de los procesos, como los
estándares ISO.
El modelo CMMI es producto de la evolución e integración de

modelos CMM diseñados para disciplinas específicas:
- Software (CMM/SW)
- Ingeniería de Sistemas (CMM/SE EIA-731)
- Adquisiciones (CMM/SS)
- Integrated Product Development (CMM/IPD) entre otros.
El modelo CMMI ensambla los modelos CMM de disciplinas

específicas en un modelo Integrado (CMMI) que puede ser
personalizado a la medida de la empresa.
Estructura Interna del CMMI
- Primera capa: Niveles de Madurez.

- Segunda capa: Áreas clave de Proceso.
- Tercera capa: Prácticas Claves.
El modelo para software (CMMI) establece 5 niveles de madurez para

clasificar a las organizaciones, en función de qué áreas de procesos
consiguen sus objetivos y se gestionan con principios de ingeniería.
Es lo que se denomina un modelo escalonado o centrado en la
madurez de la organización.
Niveles de Madurez
Nivel Descripción
Punto base. La organización tiene procesos ad-hoc o caóticos.
1-Inicial
El éxito se debe a personas heroicas.
La organización empieza a guardar información. Ya hay
2-Repetible
definiciones, pueden repetirse éxitos anteriores.
Se conocen procesos estándares para desarrollar o mantener
3-Definido software. Hay prácticas de Ingeniería de Software y de
Administración de procesos.
Se usan datos recolectados. Las decisiones están basadas en
4-Administrado datos cuantitativos. Los procesos son medidos, hay
retroalimentación.
La organización se dedica a mejorar continuamente. Se
5-Optimizado
localizan debilidades y fortalezas.
Áreas Clave de Proceso (KPAs)
Nivel Áreas Clave de Proceso
1-Inicial
Gestión de Requisitos (REQM), planificación de proyecto,
monitorización y control de proyectos, gestión y acuerdo de
2-Repetible
suministros, medición y análisis, gestión de la calidad de
procesos y productos, gestión de la configuración.
Desarrollo de requisitos (RD), solución técnica, verificación,

validación, integración de producto, procesos orientados a la
3-Definido
organización, formación, gestión Integrada de proyecto,
gestión de riesgos, análisis y resolución de decisiones.
Gestión cuantificada de proyectos, rendimiento de los

4-Administrado
procesos de la organización.
5-Optimizado Innovación y desarrollo.
Comparación RUP Vs CMMI
 RUP es un proceso que define quién debe hacer las cosas, qué debe
hacerse, cómo y cuándo. Dado su enfoque, mantiene modelos en
lugar de gran cantidad de documentación, utiliza un lenguaje concreto
y bien definido (UML).
 CMMI es un modelo estático, que define áreas claves (PA) en las que
se deben llevar a cabo prácticas específicas o genéricas, por lo tanto,
el hecho de implementar RUP en el desarrollo de un proyecto implica
que ciertas KPA de CMMI sean alcanzadas y otras no.
1.5.2 BPM
Business Process Modeling, también conocido como Business

Process Management es un conjunto de tecnologías y estándares para
el diseño, ejecución, administración y monitoreo de los procesos de
negocio.
BPM es un enfoque centrado en los procesos para mejorar el

rendimiento que combina las tecnologías de la información con
metodologías de proceso y gobierno. También se le considera como
una colaboración entre personas de negocio y tecnólogos para
fomentar procesos de negocio efectivos, ágiles y transparentes.
Posee funciones específicas:
• Centrarse en los procesos.

• Alinear la empresa y la tecnología.
• Buscar la mejora continua de los procesos.
• Aprovechar lo existente y hacer uso de lo nuevo.
Objetivos:
• Agilidad de negocio.
• Eficacia.
• Eficiencia.
• Mejorar el rendimiento a los capitales invertidos.
Beneficios:
• Formalizar procesos y encontrar mejoras necesarias. Fuerza

a la organización a definir, redefinir y formalizar sus procesos
actuales.
• Facilitar flujos de procesos eficientes y automatizados.
Disminuye el tiempo entre actividades.
• Incrementar la productividad y reducir personal. Trabajo más
rápido y con menos personal.
• Permitir que la gente resuelva problemas difíciles. Mejora la
calidad del personal, toma de decisiones.
• Simplificar regulaciones.
La implementación de BPM involucra la articulación de la estrategia, los

procesos y la tecnología de una empresa, para generar valor al
negocio. A diferencia de otros modelos de gestión, BPM se concentra
en la articulación de las iniciativas estratégicas con los procesos de
negocio, apalancados en estándares tecnológicos que facilitan su
despliegue alineado en las operaciones diarias de la organización.
Para lograr esta articulación es necesario desarrollar una serie de
procesos que permiten alinear de manera controlada, los aspectos
estratégicos del negocio, a través de la identificación y articulación de
los conceptos claves del proceso y la asociación de los componentes
tecnológicos que permitan flexibilizar los cambios en la cotidianidad
empresarial.
BPM articula la estrategia, los procesos y la tecnología de una organización.
1.6 Notaciones
1.6.1 UML
Es un lenguaje de propósito general para el modelado, que se
encuentra orientado a objetos, cuyo objetivo es describir cualquier
tipo de sistema en términos de diagramas.
1.6.2 BPMN
Es una notación gráfica estandarizada que permite el modelado de
procesos de negocio, en un formato de flujo de trabajo (workflow).
BPMN fue inicialmente desarrollada por la organización Business
Process Management Initiative (BPMI), y es actualmente mantenida
por el OMG (Object Management Group), luego de la fusión de las
dos organizaciones en el año 2005. Su versión actual, a abril de
2011, es la 2.0.
Su principal objetivo es proveer una notación estándar que sea

fácilmente legible y entendible por parte de todos los involucrados e
interesados del negocio (stakeholders). Entre estos interesados están
los analistas de negocio (quienes definen y redefinen los procesos),
los desarrolladores técnicos (responsables de implementar los
procesos), así como, los gerentes y administradores del negocio
(quienes monitorean y gestionan los procesos). En síntesis, BPMN
tiene la finalidad de servir como lenguaje común para cerrar la brecha
de comunicación que frecuentemente, se presenta entre el diseño de
los procesos de negocio y su implementación.
Laboratorio No. 4
Comparación de Metodologías y notaciones del mercado
Objetivos:
 Identificar y comparar las metodologías más importantes del mercado.
Duración:
20 minutos
Descripción:
De forma grupal, el participante elabora un cuadro comparativo con las principales
metodologías y notaciones del mercado.
Notas:
2. Introducción al RUP
2.1. Conceptos básicos

El proceso unificado de desarrollo (RUP) fue creado por los fundadores de
RATIONAL SOFTWARE y hoy se encuentra en poder de IBM, teniendo en esencia
lo siguiente:
El objetivo del producto Rational Unified Process® (RUP®) es el desarrollo correcto

de software. Hay tres elementos centrales que definen RUP:
1. Un conjunto subyacente de filosofías y principios para conseguir un

desarrollo de software correcto.
2. Una infraestructura de bloques de construcción del proceso y
contenido del método reutilizables.
3. El método subyacente y el lenguaje de definición del proceso.
El RUP incorpora el manejo del riesgo a lo largo del proceso, ya que está manejado
por los casos de uso y su enfoque técnico se centra en la arquitectura del software.
 El RUP potencia la productividad del equipo.

Lo hace al proveer a cada uno de sus miembros, un fácil acceso a una base de
conocimiento con lineamientos, plantillas y guías, sobre qué herramientas usar
para todas las actividades críticas del desarrollo. Al tener todos los miembros del
equipo, acceso a la misma base de conocimientos, no importa si se trabaja con
requerimientos, diseño, prueba, administración del proyecto o administración de
configuración. Se garantiza que todos los miembros de equipo compartan un
lenguaje común, un proceso común y una visión común de cómo desarrollar
software.
 Las actividades especificadas por RUP crean y mantienen “modelos”.

Más que apuntar a la producción de una gran cantidad de documentos en papel,
RUP pone el acento en el desarrollo y el mantenimiento de modelos del sistema.
 RUP es una guía sobre cómo usar efectivamente el UML.

El UML es un lenguaje estándar que permite comunicar claramente
requerimientos, arquitectura y diseños. UML es considerado como el medio
técnico para comunicar un diseño de software y sus modelos se consideran
como “los planos” del software.
 RUP está soportado por herramientas que automatizan gran parte del
proceso.
A pesar que no es indispensable utilizarlas, las herramientas de la suite de
Rational son un gran apoyo para crear y mantener los diversos elementos del
proceso de ingeniería de software: modelización visual, programación, testing,
requerimientos etc. Son invalorables en el apoyo del registro asociado con la
administración de cambios, como para la administración de configuración que
acompaña al proceso.
 RUP es un proceso configurable.

No existe un único proceso adecuado para todo el desarrollo de software. RUP
sirve para pequeños equipos de desarrollo tanto como para grandes
organizaciones de desarrollo. Está basado en una simple y clara arquitectura de
proceso, que suministra comunidad, a través de una familia de procesos. Puede
incluso ser variado para adecuarse a diversas situaciones. Además, contiene un
kit de desarrollo, que brinda soporte para configurar el proceso, de modo que
pueda adecuarse a las necesidades de cada organización.
2.1.1. Características del RUP
- Es Orientado a Objetos (Object Oriented - OO).

- Es iterativo e incremental.
- Basado en casos de uso (Use Cases).
- Centrado en arquitecturas.
Figura 1. Características del RUP.
Cada fase del RUP puede ser descompuesta en miniproyectos llamados

iteraciones.
Una iteración es un ciclo completo de desarrollo, que da como resultado
una versión (interna o externa) de un producto ejecutable; un
subconjunto del producto final en desarrollo, que crece de modo
incremental de iteración en iteración, para llegar a ser el sistema final.
2.1.2. ¿Quiénes deben usar RUP?
Si el éxito de una empresa depende de su capacidad para desarrollar y

desplegar software, RUP será de gran ayuda, puesto que se desarrolla
principalmente, con dos grupos de usuarios:
- Desarrolladores de software que trabajan como parte de un equipo

de trabajo, incluidos los interesados en dichos proyectos de desarrollo
de software.
- Ingenieros del proceso, en particular, los gestores e ingenieros del
proceso de software.
Los desarrolladores de software pueden encontrar una guía con los

requisitos que se les exigen en los roles definidos en RUP.
A un profesional que trabaja en un proyecto de ingeniería de software de
RUP, se le asigna uno o más roles definidos, donde cada rol particiona
un conjunto de tareas y productos de trabajo de los que ese rol es
responsable. También se ofrece una guía sobre cómo esos roles
colaboran en términos de las actividades que se necesitan para llevar a
cabo el proceso configurado.
Los ingenieros del proceso pueden encontrar información sobre cómo

definir, configurar, personalizar e implementar los procesos de ingeniería.
Además, la familia de productos RUP, proporciona un número de
herramientas que permiten y simplifican la definición, configuración y
personalización del proceso de ingeniería. Asimismo, con el producto
RUP se proporciona un número de vistas que se centran en diferentes
grupos de profesionales de la ingeniería de software.
2.1.3. ¿Cuándo utilizar RUP?

Se puede utilizar RUP desde el principio de un nuevo proyecto de

software, pero se puede seguir utilizándolo en los ciclos de desarrollo
subsiguientes, tiempo después de que el proyecto inicial haya
terminado. No obstante, la forma de utilizar RUP varía para ajustarse a
las necesidades requeridas.
Existen unas pocas consideraciones que determinarán cuándo y cómo

utilizar partes diferentes de RUP:
 Ciclo de vida del proyecto (número de iteraciones, longitud de cada

fase, longitud del proyecto).
 Propósitos empresariales, visión, ámbito y riesgo del proyecto.
 Tamaño del esfuerzo de desarrollo de software.
2.2. Vista dinámica del RUP

El proceso unificado (RUP) se repite a lo largo del mismo, en una serie de ciclos
que constituyen la vida de un sistema. Cada ciclo concluye en una versión del
producto y del mismo modo, cada ciclo de vida del software está dividido en
fases:
a. Fase de Inception (Inicio)

b. Fase de Elaboration (Elaboración)
c. Fase de Construction (Construcción)
d. Fase de Transition (Transición)
Cada fase, al concluir, cuenta con un punto de control claramente definido que
es conocido como hito, que normalmente, es un conjunto de metas definidas.
2.2.1. Fases del RUP

a. Fase Inception (Fase de Inicio)
Durante esta fase se establece el caso de negocio para el sistema y se limita el

alcance del proyecto. Para cumplir esto, se debe identificar todas las entidades
externas, con las cuales el sistema interactuará (actores) y se define la naturaleza
de esta interacción a alto nivel. Esto incluye identificar todos los casos de uso y
describir los más significativos.
El caso de negocio incluye criterios de éxito, riesgo, análisis y estimación de los

recursos necesarios, y un plan preliminar de fases e iteraciones (plan grueso) que
muestre las fechas de los principales puntos de control. El artefacto clave que
sintetiza estos considerandos se llama: Visión.
Objetivos:
 Establecer el ámbito de software y las condiciones de los límites del
proyecto, incluidas una visión operativa, criterios de aceptación y aquello
que debe contener el producto y lo que no.
 Discriminar los casos de uso más importantes del sistema, los principales
casos de ejemplo de las operaciones, de los que dependerán las
principales concesiones del diseño.
 Exhibir y demostrar al menos, una arquitectura posible contra alguno de los
principales casos de ejemplo.
 Estimar el coste global y la planificación de todo el proyecto (y
estimaciones más detalladas para la fase de elaboración)
 Estimar los riesgos potenciales (las causas de incertidumbre)
 Preparar el entorno de soporte para el proyecto.
Resultado:
 Un documento panorámico: una visión general de los requerimientos
esenciales del proyecto, características clave y principales exigencias.
 Un modelo de caso de uso inicial (que será refinado posteriormente).
 Un glosario inicial del proyecto.
 Un caso de negocio inicial, que incluya contexto del negocio, criterios de
éxito (proyección de ganancias, reconocimiento del mercado, etc.) y
presupuesto financiero.
 Una determinación inicial de riesgo.
 Un plan grueso del proyecto que muestre fases e iteraciones.
 Un modelo del negocio, si fuera necesario.
 Si es posible un prototipo inicial.
Punto de control (hito): objetivos del ciclo de vida.

Al final de esta fase de Inicio está el principal punto de control del proyecto:
objetivos del ciclo de vida.
Los criterios de evaluación para esta fase de Inicio son:
 Acuerdo entre los participantes sobre la definición de alcance y

costo/cronograma estimado.
 Comprensión de los requerimientos de alto nivel evidenciados por la
fidelidad a los casos de uso primarios.
 Credibilidad del costo/cronograma estimado, prioridades, riesgos y proceso
de desarrollo.
 Una solución conceptual.
b. Fase Elaboration (Fase de Elaboración)
Las decisiones sobre arquitectura deben ser hechas con comprensión del sistema
completo, el alcance, la funcionalidad principal y los requerimientos no funcionales
(también conocidos como atributos de calidad). Mientras que el proceso debe
siempre considerar los cambios, las actividades de la fase de elaboración
garantizan que la arquitectura, los requerimientos y los planes están
suficientemente estables, y el riesgo suficientemente mitigado, como para poder
determinar previsiblemente el costo, así como, el cronograma para completar el
desarrollo.
En esta fase se construye un prototipo arquitectónico, que incluye la

implementación de los casos de uso más críticos y transversales. Este esfuerzo
debería incluir, por lo menos, casos de uso, identificados en la fase de
conceptualización, los que exponen típicamente los principales riesgos técnicos
del proyecto.
Un prototipo evolutivo de un componente producido con calidad es siempre la

meta, esto no excluye el desarrollo de uno o más prototipos exploratorios
descartables, para mitigar riesgos específicos, tales como: negociaciones de
diseño/requerimientos, estudio de factibilidad de componentes o demostraciones a
los inversionistas, clientes y usuarios finales.
Objetivos:
 Analizar el dominio del problema.
 Establecer una base de arquitectura sólida.
 Desarrollar el plan del proyecto.
 Eliminar los mayores elementos de riesgo.
Resultado:
 Un modelo de casos de uso (completo por lo menos en un 80%), luego de
ser identificados todos los casos de uso y actores, además de haberse
desarrollado la especificación de la mayoría de los casos de uso.
 Requerimientos suplementarios que capturen los requerimientos no
funcionales y cualquier requerimiento que no esté asociado a un caso de
uso específico.
 Una descripción de la arquitectura de software.
 Un prototipo de arquitectura ejecutable.
 Una lista de riesgos revisada y el caso de negocio revisado.
 Un plan de desarrollo para todo el proyecto, incluyendo el plan grueso, que
muestre iteraciones y criterios de evaluación para cada iteración.
Punto de control: arquitectura del ciclo de vida

Al final de la fase de elaboración está el segundo punto de control importante del
proyecto: el punto de control de la arquitectura del ciclo de vida. En este punto se
examinan detalladamente los objetivos y alcances del sistema, la elección de la
arquitectura y la resolución de los principales riesgos.
Los principales criterios de evaluación para la fase de elaboración incluyen las

respuestas a estas preguntas:
 ¿Es estable la visión del producto?

 ¿Es estable la arquitectura?
 ¿Muestra el prototipo arquitectónico ejecutable que los elementos
principales de riesgo han sido identificados y resueltos?
 ¿Está suficientemente detallado y afinado el plan para la primera iteración
de construcción? ¿Está apoyado en bases de estimación creíbles?
 ¿Todos los participantes están de acuerdo en que se puede obtener la

visión actual si se ejecuta el plan para desarrollar el sistema completo, en
el contexto de la arquitectura actual?
c. Fase Construction (Fase de Construcción)
Durante la fase todos los componentes restantes y características de la aplicación

son desarrollados e integrados al producto y todas sus funcionalidades son
enteramente probadas. Esta fase es un proceso de manufactura, en el cual se
pone el acento en la administración de recursos y el control de las operaciones
para optimizar costos, tiempos y calidad. En este sentido, la atención se traslada
del desarrollo de la propiedad intelectual durante la conceptualización y
elaboración, al desarrollo de productos instalables durante la construcción y la
transición.
En muchos proyectos es conveniente poder realizar actividades en paralelo. Estas

actividades pueden acelerar significativamente, la disponibilidad de versiones
instalables, además de incrementar la complejidad de la administración de
recursos y la sincronización del flujo de tareas.
Una arquitectura robusta y un plan comprensible están altamente relacionados.
Resultado:
 Un producto listo para ser puesto en manos del usuario final. Consiste, como
mínimo, en:
- El producto de software integrado en las plataformas adecuadas.

- Los manuales del usuario.
- Una descripción de la versión vigente.
Punto de control: capacidad operativa inicial

Al final de la fase de construcción está el tercer punto de control del proyecto:
capacidad operativa inicial. En este punto se decide si el software, los lugares y
los usuarios están listos para operar sin exponer el proyecto a altos riesgos. Esta
versión es llamada a menudo versión beta.
Los criterios de evaluación de esta fase incluyen la respuesta a estas preguntas:
 ¿Es este release del producto lo suficientemente maduro y estable para ser
instalado en la comunidad usuaria?
 ¿Están todos los recursos listos para la transición hacia la comunidad
usuaria?
d. Fase Transition (Fase de Transición)
El propósito de esta fase es transferir el sistema a la comunidad usuaria.

Una vez que el sistema fue entregado al usuario final, habitualmente surgen
cuestiones que requieren desarrollo de nuevas versiones, corrección de ciertos
problemas o conclusión de facilidades pospuestas.
Se ingresa en la fase de transición cuando un release está lo suficientemente

maduro como para ser instalado en el dominio del usuario final. Esto requiere,
típicamente, que algún subconjunto utilizable del sistema haya sido completado en
un aceptable nivel de calidad y que la documentación del usuario esté disponible,
de modo que la transición al usuario permita obtener resultados positivos para
todas las partes.
Esto incluye:
Definir el objetivo del proyecto y elaborar el modelo del

INCEPTION
negocio.
Planificar el proyecto, especificar los Modelos y generar

ELABORATION
la base para las Arquitecturas.
CONSTRUCTION Construir el producto.
TRANSITION Transición de los usuarios al nuevo producto.
 “Beta testing” para validar el nuevo sistema contra las expectativas del
usuario.
 Operación paralela con un sistema heredado que está siendo reemplazado.
 Conversión de las bases de datos operacionales.
 Entrenamiento de usuarios y del equipo de mantenimiento.
Asimismo, esta fase se centra en las actividades requeridas para poner el software
en manos de los usuarios. Típicamente, incluye varias iteraciones, incluyendo
versiones beta, versiones de disponibilidad general, así como, reparación de
errores y versiones de mejoramiento. Además, consume considerable esfuerzo en
desarrollar la documentación orientada al usuario, entrenamiento de usuarios,
apoyo a los usuarios durante la utilización inicial del sistema y reaccionar ante la
retroalimentación del usuario. En este punto del ciclo de vida, sin embargo, la
retroalimentación del usuario debe ser limitada a cuestiones de sintonía,
configuración, instalación y utilizabilidad.
Los objetivos primarios de la fase de transición incluyen:
 Obtener la autonomía del usuario.

 Obtener el acuerdo de los participantes de que la instalación ha sido
completa y que es consistente con los criterios de evaluación de la visión.
 Perfeccionar el producto final.
Tabla 1. Descripción de las Fases de RUP
Punto de control: release del sistema
Al final de la fase de transición está el cuarto punto importante de control del

proyecto: release del sistema. En este punto, se decide si los objetivos han sido
alcanzados y si se podría comenzar otro ciclo de desarrollo. En algunos casos
este punto de control puede coincidir con el final de la fase de conceptualización
para el próximo ciclo.
2.2.2. Iteraciones del RUP
Una iteración es una secuencia de actividades con un plan establecido y

criterios de evaluación, cuyo resultado es una versión del software.
El RUP divide el proceso en cuatro fases, dentro de las cuales se

realizan varias iteraciones en número variable, según el proyecto y en las
que se hace un mayor o menor hincapié en las distintas actividades.
Según la documentación de IBM ® se pueden dividir las iteraciones:
Patron de ciclo
Inception Elaboration Construction Transition
vital
Breve, para establecer el Unica, se definen los Varias, se ejecutan los
Varias, para migrar el
Incremental ámbito y la visión, y para requisitos y se establece la Casos de uso y se afina la
producto a los usuarios
definir el caso de negocio arquitectura arquitectura
Breve, para establecer el Unica, se ejecutan los

Varias, se perfeccionan los Varias, para migrar el
Evolutivo ámbito y la visión, y para casos de uso y se amplia la
requisitos en cada iteración producto a los usuarios
definir el caso de negocio arquitectura
Breve, para establecer el Unica, se establece la linea Unica, se ejecutan los

Entrega Varias, para migrar el
ámbito y la visión, y para base de una arquitectura Casos de uso y se afina la
Incremental producto a los usuarios
definir el caso de negocio estable arquitectura
Breve, para establecer el Unica, se establece la linea Unica y muy larga, se

Varias, para migrar el
Diseño Grande ámbito y la visión, y para base de una arquitectura ejecutan los Casos de uso y
producto a los usuarios
definir el caso de negocio estable se afina la arquitectura
Tabla 2: Iteraciones según Patrones de ciclo de vida

Fuente: IBM® Rational Unified Process®
Moverse de un ciclo al siguiente

Un pase por las cuatro fases es un ciclo de desarrollo; cada pase,
produce una generación del software. A menos que el producto "muera",
irá evolucionando hacia su siguiente generación repitiendo la misma
secuencia de fases de inicio, elaboración, construcción y transición; pero
esta vez, con un distinto énfasis en las distintas fases.
Estos ciclos subsiguientes se denominan ciclos de evolución. A medida

que el producto pasa por diversos ciclos, se van produciendo nuevas
generaciones.
Figura 2. Evolución entre iteraciones

Los ciclos de evolución pueden desencadenarse por mejoras sugeridas

por el usuario, cambios en el contexto del usuario, cambios en la
tecnología subyacente, reacción a la competencia, etc.
Además, los ciclos de evolución suelen tener fase inicial y de elaboración

mucho más cortas, ya que la definición del producto básico y de la
arquitectura básica, los determinan ciclos de desarrollo anteriores. Las
excepciones a esta norma son los ciclos de evolución en los que se
produce una redefinición significativa del producto o de la arquitectura.
2.3. Elementos
El RUP v 7.0 (2006) está estructurado por tres elementos fundamentales:
 Roles - el quién
 Tareas - el cómo
 Productos de Trabajo - el qué
 Actividades - el cuándo
Los Roles realizan un trabajo especializado. En el RUP existen más de 30 roles.
Un rol es el responsable de realizar las tareas (Actividades en RUP 2003) que

producen resultados tangibles llamados Productos de Trabajo.
Al unir y sincronizar a estos tres elementos mencionados en una secuencia

orquestada, de acuerdo a la metodología iterativa incremental y a las mejores
prácticas de desarrollo del software, se obtienen las Actividades (conocidas en
RUP 2003 como los WorkFlows o flujos de trabajo).
2.3.1. Roles
El término Rol es usado para

denominar a los puestos a los
cuales se pueden asignar personas
dentro de un proyecto de desarrollo
de software. Cada rol es
responsable de un conjunto
completo de tareas, como las tareas
necesarias para el análisis de
procesos de negocio. Una persona
puede asumir las responsabilidades de varios roles.
Además, un Rol será responsable de la confección de una serie de

Productos de Trabajo.
Responsabilidades:
 Hacer una serie de tareas.

 Ser el responsable de una serie de productos de trabajo.
2.3.2. Tareas
Es una unidad de trabajo que se asigna a un Rol. Por ejemplo: Análisis

de la Arquitectura.
Una actividad puede llevar entre un par de horas y un par de días,

involucra uno o varios roles (En RUP 2003 era restringido a un solo rol) y
un número pequeño de productos de trabajo.
Las tareas se consideran en la planificación y evaluación del progreso
del proyecto.
Por ejemplo:
Tareas Rol
Planificar una iteración Administrador de proyecto
Encontrar actores y casos de uso Analista
Revisar el diseño Revisor de diseño
Ejecutar pruebas de performance Ing. de pruebas de performance
2.3.3. Productos de Trabajo
Son piezas de información que son producidas, modificadas o usadas

por un proceso. Son el resultado parcial o final, que es producido y
usado durante el proyecto.
Un producto de trabajo es una abstracción general que representa un
resultado del proceso. Entre los productos de trabajo encontramos:
 Artefactos: son productos de trabajo tangibles y bien definidos, que las

tareas consumen, producen o modifican. Los artefactos pueden estar
compuestos por otros artefactos. En general, los artefactos no son
documentos. La forma más eficaz y pragmática de gestionar los
artefactos del proyecto es mantenerlos dentro de la herramienta
adecuada que se haya utilizado para crearlos y gestionarlos.
Ejemplos:
- Una especificación de caso de uso almacenada en Microsoft®
Word®
- Un modelo de diseño almacenado en Rational Software
Architect.
- Un plan de proyecto almacenado en Microsoft® Project®.
 Entregable: es un producto de trabajo que proporciona una descripción

y una definición del empaquetado de otros productos de trabajo y puede
entregarse a una parte interna o externa. Por lo tanto, un entregable
agrega otros productos de trabajo. Los entregables se utilizan para
representar una salida de un proceso que tiene valor, material o
información de otro tipo para un cliente u otra parte interesada.
 Resultado: describe productos de trabajo intangibles que son un

resultado o un estado, como un servidor instalado o una red optimizada.
Como la aparición de un resultado suele documentarse de manera
informal (por ejemplo, mediante actas o memorándums), los resultados
también pueden utilizarse para describir productos de trabajo que no
estén definidos formalmente.
Las tareas tienen productos de trabajo de entrada y de salida. Los roles

utilizan productos de trabajo para realizar tareas y producir otros
productos de trabajo mientras realizan las tareas.
Un Producto de trabajo puede ser un documento, un modelo o un

elemento de modelo. Los artefactos son las entradas y salidas de las
tareas.
Los Productos de trabajo son agrupados por cada disciplina:
 Business Modeling Set

 Requirements Set
 Analysis & Design Set
 Implementation Set
 Test Set
 Deployment Set
 Project Management Set
 Configuration & Change Management Set
 Environment Set
2.4. WorkFlows
Son una secuencia de actividades que produce un resultado de valor observable.
En términos de UML, un Workflow puede ser expresado como un diagrama de
secuencias, de colaboración o de actividades. Asimismo, RUP usa un diagrama
de actividad para representarlo.
El RUP organiza el conjunto de actividades usando:
 Core workflows
 Iteration workflows
 Activity
2.4.1. Core Workflow
Representa una división de los workers y actividades en agrupaciones

lógicas.
Existen seis workflows de ingeniería de procesos:
- Modelado del Negocio

- Requerimientos
- Análisis y Diseño
- Implementación
- Test
- Desarrollo
Además, existen tres workflows de apoyo o soporte:
- Configuración y Administración de Cambios.

- Administración del Proyecto.
- Ambiente.
Workflows
de Proceso
Workflows de
Soporte
Core Workflow
2.4.2. Iteration Workflow
Representa una visión de las actividades pero por cada iteración dentro
de una fase.
Es otra forma de mostrar el proceso, describiéndolo desde la
perspectiva de “qué sucede en una iteración típica”.
Iteration Workflow
– Inception Workflow: incluye las actividades realizadas durante una

única iteración en la fase inicial. El objetivo preferente en la fase
inicial es alcanzar un acuerdo entre todos los interesados respecto a
los objetivos del ciclo vital para el proyecto.
– Elaboration Workflow.
– Construction Workflow.
– Transition Workflow.
2.4.3. Activity
Es la descripción de un workflow a más bajo nivel. Está compuesto de

una serie de tareas que realizan ciertos roles en un workflow
determinado.
RUP los usa para expresar:
 Un grupo específico de tareas que están relacionadas, que son

desarrolladas juntas o en un modelo cíclico.
 Tareas que son desarrolladas por un grupo de gente.
 Tareas que producen un resultado intermedio interesante.
Ejemplo:
Dentro de la Disciplina de Negocio existen varias Actividades que

detalla la lista de tareas por cada rol. Por ejemplo, para la Actividad
Evaluar el Negocio (Evaluar la organización) se toman en cuenta las
principales tareas del rol Analista de Procesos de Negocio.
Figura: Extracto del Activity “Evaluar la Organización”

2.5. Elementos Adicionales del Proceso

RUP tiene otros elementos agregados a las actividades o artefactos para hacer el
proceso más fácil de entender y usar.
 Guidelines: reglas, recomendaciones y heurísticas que soportan actividades y

steps (pasos dentro de las actividades).
 Templates: plantillas, modelos o prototipos de artefactos.
 Tool mentors: proveen una guía adicional para mostrar cómo desarrollar los
steps usando una herramienta de software específica.
 Concepts: son algunos de los conceptos claves del proceso.

Laboratorio Nº 5
Identificación de los elementos de la herramienta RUP2006
Objetivos:
 Identificar y navegar por la herramienta con la metodología.
 Identificar los elementos de dicha herramienta.
Duración:
20 minutos.
Descripción:
De forma individual, el participante navegará por la herramienta e irá ubicando los elementos
que el instructor vaya indicando. Asimismo, identificará Roles, Actividades, Artefactos.
Notas:
3. Introducción al UML
3.1. Fundamentos del UML
Es un lenguaje de propósito general para el modelado, cuyo objetivo es describir

cualquier tipo de sistema en términos de diagramas orientados a objetos.
El lenguaje unificado de modelado de objetos (UML: Unified Modeling Languaje)

está pensado para especificar, visualizar y construir los componentes que
conforman un sistema de software o un modelado de negocios con las más
avanzadas metodologías y herramientas orientadas a objetos.
Cabe mencionar que UML fue desarrollado por Grady Booch, Ivar Jacobson y Jim
Rumbaugh de Rational Software Corporation, con la participación de usuarios,
diseñadores de software y promotores. Éste se basa en las metodologías de OMT,
Booch y OOSE, convirtiéndose en el heredero natural de éstas. Esto significa que
si ya se es usuario de cualquier metodología orientada a objetos, la experiencia
adquirida será ampliada y actualizada con el uso de esta nueva herramienta.
El rango de aplicaciones de este poderoso lenguaje de modelado, cubren un

espectro tan amplio como el modelado de procesos de negocios utilizando "use
cases", clases y objetos, componentes, y procesos en general.
UML es, desde fines de 1997, el lenguaje de modelado orientado a objetos

estándar, de acuerdo con el Object Management Group, y ya se ha integrado en
grandes organizaciones, entre las que se encuentran Microsoft, Hewlett Packard,
Oracle, Rational Rose, etc., quienes ya lo usan como su herramienta de facto.
A su vez, UML es un lenguaje más expresivo, claro y uniforme que los

relacionados con las metodologías de objetos existentes, y si bien no garantiza el
éxito de los proyectos, sí mejora substancialmente su desarrollo, al permitir una
nueva y más fuerte integración entre las herramientas, los procesos y los
dominios. Pero lo más importante, habilita a los desarrolladores y les permite
centrarse en el valor agregado de negocios, proporcionándoles un paradigma para
llevarlo a cabo.
UML combina notaciones provenientes desde:
• Modelado Orientado a Objetos.

• Modelado de Datos.
• Modelado de Componentes.
• Modelado de Flujos de Trabajo (Workflows).
Modelos UML. Enfoques OO
Gráfica 3. Colaboradores de la creacion de UML.
3.1.1. Historia de UML
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch

y Jim Rumbaugh de Rational Software Corporation empezaron a
unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía
Objectory se incorporaron a Rational en su unificación, aportando el
método OOSE.
De las tres metodologías de partida, las de Booch y Rumbaugh pueden

ser descritas como centradas en objetos, ya que sus aproximaciones
se enfocan hacia el modelado de los objetos que componen el sistema,
su relación y colaboración. Por otro lado, la metodología de Jacobson
es más centrada a usuario, ya que todo en su método se deriva de los
escenarios de uso.
UML se ha ido fomentando y aceptando como estándar desde la

formación de OMG, que es también el origen de CORBA, el estándar
líder en la industria para la programación de objetos distribuidos. En
1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación
estándar de facto para el análisis y el diseño orientado a objetos.
Posteriormente, fueron desarrollándose las versiones 1.1, 1.2, 1.3, 1.4
y 1.5 para convertirse, en lo que ahora se conoce como la versión 1.x.
No obstante, UML 1.x evoluciona en UML 2.0, siendo esta evolución

influenciada por el Desarrollo Conducido por Modelo (MDD – Model
Driven Development) y el Modelamiento Conducido por Arquitectura
(MDA – Model Driven Architecture).
3.1.2. Perspectivas para el UML
UML es y será el lenguaje de modelización de objetos estándar

predominante.
Razones:
- Participación de metodólogos influyentes.

- Participación de importantes empresas.
- Aceptación del OMG como notación estándar.
- Herramientas que proveen la notación UML.
El objetivo de UML es describir cualquier tipo de sistema en términos de

diagramas orientados a objetos.
Algunas categorías de Sistemas que puede diagramar el UML.
- Sistemas de Información.
- Sistemas de Tiempo Real.
- Sistemas Embebidos.
- Sistemas Distribuidos.
- Software de Sistemas.
- Sistemas de Negocios.
3.1.3. El nuevo Enfoque del UML 2.x
En las versiones previas, se hacía un fuerte hincapié en que UML no

era un lenguaje de programación, por ello, un modelo creado mediante
UML no podía ejecutarse. A partir de UML 2.0, se modificó el lenguaje,
de manera tal, que permitiera capturar mucho más comportamiento.
Esto permitió la creación de herramientas que soporten la
automatización y generación de código ejecutable, a partir de modelos
UML.
3.2. Estructura del UML
ESTRUCTURA UML
BLOQUES DE MECANISMOS
ARQUITECTURA
CONSTRUCCION COMUNES
Para poder elaborar los diagramas en UML es necesario comprender cómo está
estructurado. Asimismo, es necesario adquirir un modelo conceptual del lenguaje y
esto requiere del aprendizaje de los siguientes elementos:
 Los bloques básicos de construcción.

 Los mecanismos comunes que se aplican a través de UML.
 La arquitectura UML
Por último, se deben combinar estos elementos con la forma con la cual pueden ser
unidos: las reglas UML.
3.2.1. Bloques de Construcción
BLOQUES DE CONTRUCCION
ELEMENTOS RELACIONES DIAGRAMAS
El vocabulario UML incluye 3 clases de bloques de construcción:
1. Elementos
Los elementos representan las abstracciones del modelo. Existen 4 tipos:
a) Elementos estructurales.
b) Elementos de comportamiento.
c) Elementos de Agrupación.
d) Elementos de Anotación.
Estos elementos son los bloques básicos de construcción orientados a

objetos de UML. Se utilizan para escribir modelos bien formados.
a. Elementos Estructurales: son los nombres de los modelos UML, la

mayor parte de ellos son las partes estáticas de un modelo,
representan cosas materiales o conceptuales. Existen 7 elementos
estructurales:
 Clases.
 Interfaz.
 Colaboración.
 Casos de uso.
 Clase activa.
 Componente.
 Nodo.
 Clase: es una descripción de un conjunto de objetos que comparten los

mismos atributos, operaciones, relaciones y semántica.
La clasificación es uno de los mecanismos de abstracción más utilizados
en el Modelado de Objetos. Los objetos o instancias se crean por
instanciación de las clases.
Cada clase se representa en un rectángulo con tres partes:
1. Nombre de la clase (Ejm: Producto)

2. Atributos de la clase (Ejm: CodProducto)
3. Operaciones de la clase (Ejm: GrabarProducto())
Producto
-CodProducto
-DesProducto
-StockAct
-Precio
+BuscarProducto()
+GrabarProducto()
+EliminarProducto()
Ejemplo: Clase Producto
 Interfaz: es una colección de operaciones que

especifican un servicio de una clase o componente.
Por lo tanto, describe el comportamiento visible
externamente de ese elemento. Además, una interfaz
puede representar el comportamiento completo de una
clase o componente, o sólo una parte de ese
comportamiento.
 Colaboración: define la interacción. Es una sociedad de roles y

otros elementos que colaboran para proporcionar un
comportamiento cooperativo mayor que la suma de los
comportamientos de sus elementos. Estas colaboraciones
representan la implementación de patrones que forman un sistema.
Cadena de
Responsabilidad
 Casos de uso: es la descripción de un conjunto

de secuencias de acciones que un sistema Consultar Producto
ejecuta y que produce un resultado observable de
interés para un actor particular.
 Clase activa: es una clase cuyos objetos tienen uno o más

procesos, o hilos de ejecución y por lo tanto, pueden dar origen a
actividades de control. Una clase activa es igual a una clase,
excepto que sus objetos representan elementos cuyo
comportamiento es concurrente con otros elementos. Gráficamente,
solo varía en el borde más grueso alrededor de la clase.
Gestor Evento
+suspender()
+vaciar cola()
Ejemplo: Clase activa Gestor Evento

 Componente: es una parte física y reemplazable de un sistema que

conforma con un conjunto de interfaces y proporciona la
implementación de dicho conjunto.
Component
UML 1.X UML 2.0
 Nodo: es un elemento físico que existe en tiempo de ejecución y

representa un recurso computacional, que por lo general, dispone de
algo de memoria y con frecuencia, capacidad de procesamiento.
Servidor de
Aplicaciones
También existen variaciones de estos siete elementos, tales como:

actores, señales, utilidades, procesos e hilos, aplicaciones,
documentos, archivos, entre otros.
b. Elementos de Comportamiento: representan las partes dinámicas de los

modelos UML. Estos son los verbos de un modelo y que representan
comportamiento en el tiempo y el espacio.
Existen dos tipos:
 Interacción: es un comportamiento que comprende un conjunto de

mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto particular, para alcanzar un propósito específico.
dibujar
stm Login
 Máquina de estados: es un comportamiento que Login Denied

especifica las secuencias de estados por las que
pasa un objeto o una interacción durante su vida, en
respuesta a eventos, junto con sus reacciones a
estos eventos.
c. Elementos de Agrupación: representan las partes organizativas de los

modelos UML. Estos son las cajas en las que puede descomponerse un
modelo. Tiene un único elemento:
uc Use Case View

 Paquetes: en algunas ocasiones se tendrá la
necesidad de organizar los elementos de un Business Use Case Model
diagrama en un grupo, tal vez para mostrar que
ciertas clases o componentes son parte de un
subsistema en particular. Para ello, se agrupará en
un paquete, que se representará por una carpeta
tabular, tal como se muestra en la figura.
Cada paquete corresponde a un subconjunto del modelo y contiene, según

el modelo, clases, objetos, relaciones, componentes y diagramas
asociados.
La arquitectura del sistema viene dada en forma de paquetes y por las
relaciones de dependencia entre ellos. Un paquete puede contener a
otros, sin límite de anidamiento. Un nivel dado puede contener paquetes y
otros elementos de modelado (por ejemplo: diagramas de clases y de
interacción). Cada elemento pertenece a sólo un paquete.
d. Elementos de Anotación: son las partes explicativas de los modelos

UML. Son comentarios que se pueden aplicar para describir, clarificar y
hacer observaciones, sobre cualquier elemento del modelo.
 Notas: es frecuente que alguna parte del diagrama no

represente una clara explicación del porqué está allí o
la manera en que trabaja, cuando éste sea el caso, la
nota UML será útil. Por ejemplo, al imaginar una nota
como el equivalente gráfico de un papel adhesivo. La
nota es un rectángulo con una esquina doblada y
dentro del rectángulo se coloca la explicación.
2. Relaciones
Son los bloques básicos de construcción para relaciones de UML.
Hay cuatro tipos de relaciones en UML:
a) Dependencia: relación semántica donde un elemento (independiente)

puede afectar a otro elemento (dependiente)
b) Asociación: relación estructural que describe un conjunto de enlaces, los

cuales son conexiones entre objetos. La agregación, por ejemplo, es un tipo
especial de asociación, que representa una relación estructural entre un todo y
sus partes. Generalmente, incluye roles y multiplicidad.
0..1 *
patrón empleado
c) Generalización: relación donde los objetos del elemento hijo, pueden

sustituir a los elementos del elemento padre.
d) Realización: es una realización semántica entre clasificadores, en donde un

clasificador especifica un contrato que otro clasificador garantiza que cumplirá.
3. Diagramas UML
Un diagrama es la representación gráfica de un conjunto de elementos,

visualizado la mayoría de las veces como un grafo conexo de nodos
(elementos) y arcos (relaciones).
Los diagramas son los gráficos que muestran los símbolos de los elementos
del modelo, arreglados para ilustrar una parte en particular o un aspecto del
sistema. Permite al usuario visualizar y manipular los elementos del modelo.
UML tiene diferentes diagramas que son utilizados en combinación para

proporcionar todas las vistas del sistema.
a. Diagramas UML 1.X
UML en su versión 1.X tiene nueve tipos de diagramas. A continuación, se

describirán los diagramas más comunes y los conceptos que representan.
• Diagramas de clases: representan la estructura estática, en términos de

clases y relaciones. Además, facilitan las representaciones a partir de las
cuales los desarrolladores podrán trabajar.
OrdenCompra Proveedor
-f -wProvee
-NumOrdCom : Char -Proveedor_id : Char
-FecOrdCom : Date -RazonSocial : String
-GlosaOC : String -DireccionLegal : String
Ins_OrdCompra
-CantInsumos : Double
-PreInsumos : Decimal
Insumo
-InsumoId : Char
-wInsumo -DesInsumo : String
-x
-StkInsumo : Double
-PreInsumo : Decimal
+GrabarInsumo()
+ActualizaInsumo()
+DesactivaInsumo()
-. FamInsumo
-FamInsId : Char
-DesFamIns : String
-wFamIns +CargaComboFamilia()
• Diagramas de casos de uso: representan, en sus dos versiones, diferentes

conceptos. De esta manera, los casos de uso de negocio representan los
procesos del negocio que son usados por los roles del negocio, mientras que,
los casos de uso de sistema describen un sistema desde el punto de vista del
usuario.
Modelo de Casos de Uso de Negocio Modelo de Casos de Uso de Sistema

uc Primary Use Cases
Despachar
productos
Almacenero
Registrar
Inventario
• Diagramas de objeto y colaboración: un objeto es una instancia de una

clase, este diagrama representa objetos, sus relaciones y correspondencia,
para simplificar los diagramas de colaboración que no representan la
transmisión de mensajes. Son una representación espacial de objetos, links e
interacciones.
Lanificio Sur : 3.Capa Datos::Proveedor

Proveedor_id : Char = P0098
RazonSocial : String = Lanificio
DireccionLegal : String = Av.Los Quechuas
OC 56 : 3.Capa Datos::OrdenCompra
NumOrdCom : Char = 56
FecOrdCom : Date = 15/04/09
GlosaOC : String = Urgente
• Diagrama de estados: representa el comportamiento dinámico (orientado al

evento), con el propósito de modelar el ciclo de vida de un objeto. Un objeto se
encuentra, en cualquier momento, en un estado en particular. Por ejemplo, una
persona puede ser recién nacida, infante, adolescente, joven o adulta; una
lavadora podrá estar en fase de remojo, lavado, enjuague, centrifugado o
apagada.
solicitada
solicitar() [verificar=no]
entry/verificar prerequesitos rechazada
exit/UninterpretedAction1
consultar()[ solo si,,,,] [verificar=si]
cancelar() aprobada
cancelada
cancelar()[si no hay deuda]

activa
debitar()
bloqueada CancelaRobo(pin)
Ejemplo: Diagrama de Estados de la clase “cuenta”
• Diagrama de actividades: representa el comportamiento interno de una

operación o de un caso de uso, bajo la forma de un desarrollo por etapas,
agrupadas secuencialmente. Las actividades que ocurren dentro de un caso
de uso o dentro del proceso de una empresa se dan, normalmente, en
secuencia.
• Diagrama de secuencias: los diagrama de clases y los de objeto,

representan información estática. No obstante, en un sistema funcional los
objetos interactúan entre sí y tales interacciones suceden con el tiempo.
Un diagrama de Secuencia es una representación estructurada de
comportamiento como una serie de pasos secuenciales a lo largo del
tiempo. Se usa para representar el flujo de trabajo, el paso de mensajes y
cómo los elementos en general, cooperan a lo largo del tiempo para lograr
un resultado.
sd Add To Shopping Cart
La figura presenta un diagrama de

secuencias que captura las Client
ItemsPage AddToBasket
interacciones que se realizan a través
del tiempo entre el abastecimiento de
agua, el tambor y el drenaje addLineItem()
(representados como rectángulos en la :ShoppingBasket
addLineItem()
parte superior del diagrama).
(from Actors)
Client
• Diagrama de componentes: el moderno desarrollo de software se realiza

mediante componentes, lo que es particularmente importante en los
procesos de desarrollo en equipo.
Los diagramas de componentes describen los elementos físicos y sus
realizaciones. Los componentes representan todos los tipos de elementos
software que entran en la fabricación de aplicaciones informáticas pueden
ser archivos, bibliotecas cargadas dinámicamente, etc.
«executable»
sistema.exe
«document» «library»
Ayuda.doc Elog.dll
«library»
Gestor
• Diagrama de distribución o despliegue: el diagrama de distribución

UML muestra la arquitectura física de un sistema informático. Puede
representar los equipos y dispositivos, mostrar sus interconexiones y el
software que se encontrará en cada máquina. De esta forma, cada
computadora está representada por un cubo y las interacciones entre las
computadoras están representadas por líneas que conectan a los cubos.
Los diagramas de distribución muestran la disposición física de los

distintos nodos que componen un sistema y el reparto de los componentes
sobre dichos nodos.
b. Diagramas UML 2.x
Modelos
Diagramas de Comportamiento Diagramas Estructurales
Diagramas de Diagrama de
Secuencia Diagrama de Diagrama de
Casos de Uso
Clases Objetos
Diagrama de Diagrama Visión
de Interacción Diagrama de Diagrama de
Actividad Componentes Despliegue
Diagrama de Diagrama Diagrama de
Máquina de de Tiempos Diagrama de
Estructura
Paquetes
Estados Compuesta
Diagrama
de Comunicación
UML a partir de su versión 2.X define una serie de diagramas adicionales a

los establecidos en la versión anterior.
El conjunto de diagramas se encuentra organizado en torno a dos
categorías: diagramas estructurales y diagramas dinámicos o de
comportamiento.
Para la versión 2.x, el antiguo diagrama de colaboración se transforma en el

diagrama de comunicación. De la misma manera, el diagrama de estados
se denomina ahora diagrama de máquina de estados. Asimismo,
adicionalmente se incorporan los siguientes diagramas.
• Diagrama de estructura compuesta: se emplea para visualizar de

manera gráfica las partes que definen la estructura interna de un
clasificador. Cuando se utiliza en el marco de una clase, este diagrama
permite elaborar un diagrama de clases donde se muestran los
diferentes atributos (partes) y las clases, a partir de las cuales se definen
los atributos, indicando principalmente, las asociaciones de agregación o
de composición de la clase a la que se le elabora el diagrama.
Elementos:
– Parte: representa una colección o bien un elemento interno que la

clase contiene.
– Puerto: interfaz que se provee para comunicación con el medio
externo.
– Conector: enlaza 2 puertos.
– Interface que expone: implementación (esqueleto) que la clase
expone al exterior.
– Interface que se consume: enlace o dependencia que existe hacia
una interface externa.
• Diagrama visión de interacción: se emplea para representar las

interacciones, a través de diagramas o fragmentos de diagramas de
secuencias, entre los actores y el sistema como una gran caja negra, y
de diagramas de actividades en los que aparecen dichos fragmentos.
• Diagramas de tiempos: empleados para mostrar las interacciones

donde el propósito fundamental consiste en razonar sobre la ocurrencia
de eventos en el tiempo que provocan el cambio de estados de un
elemento estructural (clase, componente, etc.).
• Diagrama de comunicación: es equivalente al diagrama de

colaboración del OMG UML 1.x. Permite especificar interacciones entre
objetos que conforman la estructura interna de un clasificador.
c. Estructura Taxonómica del UML 2.3
El bloque de construcción básico del UML es un diagrama. La estructura

de los diagramas UML está reflejado por el diagrama mostrado, de
acuerdo con la especificación del UML, a partir de la versión 2.0 del
Object Development Group.
Los detalles sobre estos diagramas específicos se organizan de acuerdo

a esta estructura taxonómica, que da la perspectiva a los diagramas y a
sus interrelaciones. Los diagramas de interacción comparten propiedades
y atributos similares, como lo hacen los diagramas estructurales y de
comportamiento.
UML intenta construir en UML 1.x, no sustituir los elementos por ninguna
razón. OMG especificó que los cambios deben tener el menor impacto
como sea posible, para los usuarios de lenguajes actuales.
d. Marcos o Frames
etiqueta
CasoUso1
Actor1 CasoUso2
En OMG UML 2.0 los diagramas aparecen dentro de un marco (frame)

que posee una etiqueta para indicar el tipo de diagrama.
Las etiquetas establecidas por la especificación para identificar los

diferentes tipos de diagramas son las siguientes.
Estructural
pkg Diagrama de Paquete

cmp Diagrama Componentes
Dinámica o Comportamiento
uc Diagrama de Casos de Uso

act Diagrama de Actividad
stm Diagrama de Máquina de Estados
sd Diagrama de Secuencia
3.2.2. Mecanismos Comunes
Existen cuatro mecanismos comunes que se aplican de forma consistente a través

de todo el lenguaje.
a. Especificaciones: UML no es sólo un lenguaje gráfico, sino que detrás de

cada notación gráfica hay una especificación que proporciona una
explicación textual de la sintaxis y semántica del bloque de construcción.
Por ejemplo, detrás del ícono de una clase hay una especificación que
proporciona información de sus atributos, operaciones, signaturas y
comportamiento de la clase.
La notación gráfica de UML se utiliza para visualizar el sistema, por su
parte, la especificación se utiliza para enunciar los detalles de dicho
sistema.
b. Adornos: la mayoría de los elementos UML tienen una única y clara

notación gráfica que proporciona una representación visual de los aspectos
más importantes del elemento. Pero la especificación puede incluir otros
detalles, algunos de los cuales se pueden incluir como adornos gráficos en
la notación base. Por ejemplo, se pueden incluir adornos en el ícono de una
clase indicando la visibilidad de las operaciones.
SÍMBOLO SIGNIFICADO
Producto
-CodProducto + Público
-DesProducto - Privado
-StockAct
# Protegido
-Precio
$ Estático
+BuscarProducto()
-GrabarProducto() / Derivado (no estándar)
#EliminarProducto() * Abstracto (no estándar)
c. Divisiones Comunes: al modelar sistemas orientados a objetos, el mundo

puede dividirse, por lo menos, en un par de formas: clase-objeto e interfaz-
implementación.
Una clase es una abstracción; un objeto es una manifestación concreta de
dicha abstracción. Todos los bloques de construcción de UML presentan esta
dicotomía. Por ejemplo, se puede tener casos de uso e instancias de casos
de uso, componentes e instancias de componentes.
Una interfaz declara un contrato, una implementación representa la
realización concreta de ese contrato responsable de hacer efectiva de forma
fidedigna la semántica completa de la interfaz. Casi todos los bloques de
construcción presentan esta otra dicotomía; por ejemplo, se pueden tener
casos de uso y las colaboraciones que los realizan, así como operaciones y
los métodos que las implementan.
d. Mecanismos de Extensibilidad: UML proporciona un lenguaje estándar para

escribir planos software, pero no es posible que un lenguaje cerrado sea
siempre suficiente para expresar todos los matices posibles de todos los
modelos, en todos los dominios y en todos los momentos. Por esta razón
UML es abierto-cerrado, pudiendo extender el lenguaje de manera
controlada.
Los mecanismos de extensión incluyen:
 Estereotipos: parte del rango de la sensibilidad de los mecanismos dados

en UML. Cada elemento del modelo UML puede tener uno o más
estereotipos cuando la semántica básica del elemento no es suficiente.
Un estereotipo permite la metaclasificación de un elemento UML, lo cual
conlleva a los usuarios, añadir nuevas clases de elemento del modelo
sobre el núcleo predefinido por UML. Un ejemplo de estereotipos
predefinidos por UML son “inclusiones” y “extensiones”.
Finalmente, permite la extensión controlada por usuarios de UML de las
clases del meta modelo.
«Business Use Case»

Registrar
Devolucion Libro
__________________________
Si paso la fecha de devolucion
«extends»
«Business Actor»
Lector
«Business Use Case»
Registrar Pago de
Mora
Los diseñadores de UML han buscado el balance entre las clases built - in
y las extensiones introducidas por estereotipo. Sólo los conceptos
fundamentales han sido expresados como clases distintas. Otros
conceptos que pueden ser derivados desde los conceptos básicos, han
sido tratados como estereotipos.
Gráficamente, un estereotipo se representa como un nombre entre

comillas francesas «nombre-estereotipo». Opcionalmente, el elemento
estereotipado se puede dibujar con un nuevo ícono asociado al
estereotipo.
A partir de la versión 2.4.1 de UML, los estereotipos deben empezar con

una letra Mayúscula.
Estereotipo/ Se aplica al
Significado
Palabra clave símbolo
Especifica un conjunto coherente de roles
que juegan los usuarios de los casos de
Actor Clase
uso, cuando interactúan con estos casos de
uso.
Maneja comunicaciones entre el entorno
del sistema y el sistema, además, suele
Boundary Clase
proporcionar la interfaz del sistema con un
usuario o con otro sistema
Se trata de clases que coordinan los
eventos necesarios para llevar a cabo. El
Control Clase
comportamiento que se especifica en el
caso de uso, representan su dinámica.
Especifica una clase persistente. Este tipo
de clase suele reflejar entidades del mundo
Entidad Clase real o elementos necesarios para realizar
tareas internas al sistema. También se
denominan clase dominio.
Especifica un actor que representa un ROL
desempeñado en relación al negocio por
alguien o algo en el ambiente de negocio.
Business Actor Actor Asimismo, representa a algún participante
fuera del alcance del negocio y, por lo
tanto, tiene una comprensión del
comportamiento visible del negocio
Especifica un componente que representa
File Componente un documento que contiene código, fuente
o datos.
Tabla 3. Estereotipos más comunes
 Valores etiquetados: son una extensión de las propiedades de un

elemento de UML que permiten añadir nueva información en la
especificación del elemento.
Gráficamente un valor etiquetado se representa como una cadena de
caracteres entre llaves asociada al nombre del elemento. La cadena
incluye un nombre (etiqueta), un separador (=) y un valor (de la etiqueta).
Todo elemento UML tiene su propio conjunto de propiedades: las clases
tienen nombres, atributos y operaciones; las asociaciones tienen nombres
y dos o más extremos, etc.
Se aplica al
Valor etiquetado Significado
símbolo
Todos los Especifica un comentario, una descripción o una
documentation
elementos explicación del elemento al que se asocia.
La mayoría de Especifica el nodo o el componente en el que
location
los elementos reside el elemento.
Especifica si el estado de la instancia se
Clase mantiene después de terminar el proceso que la
persistence Asociación creó; los valores posibles son: persistente (se
Atributo mantiene el valor) y transitorio (no se mantiene
el valor).
Clase Especifica el significado de la clase o la
semantics
Operación operación.
Tabla 4. Valores etiquetados.
 (Constraints): con las restricciones, se puede añadir nuevas semánticas

o cambiar reglas existentes. Una restricción específica es que las
condiciones que deben ser mantenidas verdaderas para que el modelo
sea considerado bien formado.
UML no especifica una sintaxis particular para constraints que aparecen

entre corchetes, entonces pueden ser expresados en lenguaje natural,
seudo-código, expresiones de navegación o expresiones matemáticas.
Se aplica al
Restricción Significado
símbolo
Especifica que la instancia o el enlace son
Instancia
Destroyed destruidos antes de terminarse la ejecución
Enlace
de la interacción que lo contiene.
Especifica que no se han especificado todos
Incomplete Generalización los hijos en la generalización y que se
permiten hijos adicionales.
Especifica que la instancia o el enlace se
Instancia
New crean durante la ejecución de la interacción
Enlace
que lo contiene.
Especifica que, sobre un conjunto de
Or Asociación asociaciones, exactamente una se manifiesta
por cada objeto asociado.
Tabla 5. Restricciones.
3.2.3. Arquitectura UML
Una de las herramientas para representar modelos de arquitectura

anteriores al UML es la denominada 4+1 vistas, propuesta por Phillippe
Kruchten. Ésta surge de la necesidad de los desarrolladores al modelar
un problema; lógicamente en este proceso se hace énfasis en
proporcionar la mayor información del mismo, a través de los diagramas
que se utilicen para su descripción, esto trae consigo que puedan
suceder conflictos en la representación de la arquitectura del sistema.
Vista de
Vista Lógica Implementación
Vista de los
Casos de Uso
Vista de Vista de
Procesos Distribución
Las vistas muestran diferentes aspectos de los sistemas que son

modelados. Una vista no es un gráfico, pero es una abstracción que
consiste en una serie de diagramas. Sólo definiendo una serie de vistas,
cada una mostrando un aspecto particular del sistema, puede ser
construida como una imagen completa del sistema. Las vistas también
enlazan el lenguaje de modelado al método o proceso escogido para el
desarrollo.
Las vistas son:
 Vista de caso de usos

 Vista lógica
 Vista de componentes
 Vista de procesos
 Vista de despliegue
3.3. Reglas de UML
Los bloques de construcción de UML no pueden combinarse de cualquier manera,

ya que tienen reglas que especifican a qué debe parecerse un modelo bien
formado.
Un modelo bien formado es aquel que es semánticamente autoconsistente y está en
armonía con todos sus modelos relacionados.
UML tiene reglas semánticas para:
 Nombres
 Alcance
 Visibilidad
 Integridad
 Ejecución
Los modelos que, construidos durante el proceso software de un sistema con gran
cantidad de software, tienden a evolucionar y pueden ser vistos por diferentes
usuarios de formas diferentes y en momentos diferentes. Por esta razón, es común
en el equipo de desarrollo no sólo construir modelos bien formados, sino también
construir modelos que posean las siguientes características:
 Abreviados: ciertos elementos se ocultan para simplificar la vista.

 Incompletos: pueden estar ausentes ciertos elementos.
 Inconsistentes: no se garantiza la integridad del modelo.
3.3.1. Reglas UML de Nombres

Estas reglas definen cómo llamar a los elementos, relaciones y
diagramas.
Ejemplo:
 Los diagramas de casos de uso pueden usar dos tipos de relaciones
de dependencia, los nombres para estos tipos deberán ser:
«Include» o «Extend»
 Los Casos de uso deberán tener como nombre: el verbo de la
acción que realiza asociado al nombre del objeto afectado.
3.3.2. Reglas UML de Alcance

El contexto que da significado específico a un nombre.
Ejemplo:
 El alcance de propiedad de un clasificador: “Sólo hay un valor de la
característica para todas las instancias del clasificador”
3.3.3. Reglas UML de Visibilidad

Cómo se pueden ver y utilizar esos nombres por otros.
Ejemplo:
 Private, sólo el propio clasificador puede utilizar la característica.
3.3.4. Reglas UML de Integridad

Cómo se relacionan apropiada y consistentemente unos elementos con
otros.
Ejemplo:
 Un actor no puede tener una relación «Include» con un caso de uso.
 Las relaciones «Include» se realizan entre 2 casos de uso
3.3.5. Reglas UML de Ejecución

Qué significa ejecutar o simular un modelo dinámico.
Ejemplo:
 Un diagrama de secuencia representa la ejecución de un modelo, a
través de objetos
Laboratorio Nº 6:
Generación de una plantilla inicial en UML 2.x
Objetivos:
 Identificar la herramienta de modelado.
 Preparar un archivo con la estructura interna inicial en la realización de un
Proyecto.
Duración:
20 minutos.
Descripción:
De forma individual el participante navegará por la herramienta e irá ubicando los elementos
que el instructor vaya indicando. Asimismo, construirá una plantilla inicial de trabajo.
Notas:

Capitulo 2 - Introducción Al RUP y Al UML

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Capitulo 2 - Introducción Al RUP y Al UML

Încărcat de

Drepturi de autor:

Formate disponibile

Introducción al RUP y al UML

Al finalizar el capítulo, el alumno podrá:

 Aplicar el ciclo de vida del software usando la metodología RUP.

1. Metodologías y estándares en el desarrollo de software.

Programa UML 2.4.1 for Developer- Enterprise Architect

1. Metodologías y estándares en el desarrollo de software

 Ciclo de Vida del Software

El término ciclo de vida del software describe el desarrollo de software, desde

a. Especificación del software, donde los clientes e ingenieros definen el

d. Evolución del software, donde el software se modifica para adaptarlo a

En general, se considera que los desarrolladores de software consideran

- Definición de objetivos: definir el resultado del proyecto y su papel

Un proceso de ciclo de vida define el alcance de un proceso y su relación entre

Ciclo de Vida Organización/Negocio: Empresa

Ciclo de Vida de la Tecnología de la Información

Ciclo de Vida del Sistema

a. Ciclo de Vida de Desarrollo Software

b. Ciclo de vida del sistema

c. Ciclo de Vida de Tecnología de Información (TI)

d. Ciclo de vida del Negocio u organización

Una metodología es un conjunto de métodos que se utilizan para desarrollar una

Metodologías vs. Ciclo de vida

Generaciones de las Metodologías

1.2.1. Elementos de una metodología

Una metodología considera los siguientes elementos:

 Ciclo de vida: secuencia ordenada del desarrollo completo (cascada,

 Productos: documentos, entregables, evidencias, etc.

 Procedimientos y herramientas: ¿cómo?, ¿con qué?

 Criterios de evaluación: ¿cómo nos fue?

1.2.2. Características de una metodología

 Existencia de reglas predefinidas.

1.2.3. Usos de las metodologías

 Facilita la planificación.  Comprensión del  Garantiza la calidad del

1.3 Clasificación de las Metodologías

Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y

Se consideran 3 clases de metodologías:

- Incremental: entregas pequeñas de SW, con ciclos rápidos.

Características de una metodología ágil:

- Individuos y sus interacciones son más importantes que procesos y

Es una metodología de planificación, desarrollo y mantenimiento de

- Proporcionar o definir sistemas de Información que ayuden a conseguir

Métrica 3 se divide en procesos principales (relativos a la planificación,

necesita de entrada, los que produce de salida, las prácticas necesarias

Métrica 3 es flexible en su estructura porque no es obligatorio seguir todos

Planificación Mantenimiento -Gestión de Proyectos (GP)

- Construcción del SI (CSI)

En una única estructura la metodología Métrica Versión 3, cubre distintos

 Gestión de Proyectos (GP)

1.3.2 RUP (Rational Unified Process)

Es un proceso de ingeniería de software, que guía las actividades de los

- Que satisfaga los requerimientos del usuario.

Es un producto de Rational Software Corp adquirido por IBM. RUP

Se divide en dos dimensiones:

 Eje horizontal: representa el tiempo y muestra las etapas del ciclo

1.3.2.1 Extreme Programming

La metodología de Extreme Programming (XP) es relativamente nueva y

En este sentido, el ciclo de vida del Extreme Programming se puede ver

A grandes rasgos, Extreme Programming permite que:

 Los requerimientos se especifican continuamente y se plasman en las

 Utilizar “chapuzas” controladas para reducir riesgos, es decir, probar

Este modelo se muestra en la siguiente figura:

Ciclo de vida de un proyecto al que se aplica la metodología de Extreme Programming.

Detalle del trabajo en una iteración en el Extreme Programming.

En la figura se aprecia que la iteración en el Extreme Programming está