PowerPoint 2 - Introducción RUP y UML PDF

División de Alta Tecnología
UML 2.4.1 for Developer – Enterprise Architect
Copyright © Todos los Derechos Reservados - Cibertec Perú SAC
Cap. 2 Introducción al RUP y al UML
Objetivos Generales
 Aplicar el ciclo de vida del software usando la metodología RUP.

 Reconocer los elementos del lenguaje de Modelamiento UML.
Contenido de Agenda
 Metodologías y Estándares en el desarrollo de software

 Introducción al RUP
 Introducción al UML
1
1.1. Introducción
 Para un correcto proceso de

desarrollo de software, deberá
evaluarse los diferentes métodos,
modelos, estándares y frameworks
del mercado.
1.1.1. El 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.
Fuente: Ian Sommerville
1.1.2. Tipos de procesos
 Un proceso de ciclo de vida define el alcance de un proceso y su relación

entre sus actividades.
 Es importante distinguir entre los 4 tipos de ciclos de vida de procesos:
 El ciclo de vida del desarrollo de software.
 El ciclo de vida del sistema.
 El ciclo de vida de TI.
 El ciclo de vida del Negocio u organización.
2
ALCANCE
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
 Tipos de Proceso
 Ciclo de Vida de Desarrollo Software
 Este ciclo de vida incluye las actividades necesarias para desarrollar un sistema.
 Ejemplos:
 RUP
 eXtreme Programming (XP) Ciclo de Vida Organización/Negocio: Empresa
Ciclo de Vida
Desarrollo Software
 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.
Ciclo de Vida
Desarrollo Software
3
 Tipos de Procesos
 Ciclo de Vida de TI
 Este ciclo de vida 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) Ciclo de Vida Organización/Negocio: Empresa
Ciclo de Vida
Desarrollo Software
 Tipos de Procesos:
 Ciclo de Vida Organización/Negocio: Empresa
 Este ciclo de vida incluye las actividades completas de su 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.
Ciclo de Vida
Desarrollo Software
1.2. Metodologías
 Conjunto de métodos que se utilizan para desarrollar una actividad con el objetivo
de formalizarla y optimizarla.
 Elementos de una metodología:
 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?
4
1.2. Metodologías
 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 hay que 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.
1.2.1. Elementos
Herramientas
Productos Procedimientos
Ciclo de
Evaluación
vida
Roles
Figura:
http://apexsistemas.com/images/cliente6.png
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.
5
1.2.3. ¿Para qué usar una metodología?
 Desde el punto de vista de

administración:
 Facilita la planificación.
 Facilita el control y seguimiento de los
proyectos.
 Mejora la relación costo/beneficio.
 Optimiza el uso de recursos.
 Facilita la comunicación entre los
participantes.
 Facilita la evaluación de los proyectos.
 Desde el punto de vista del desarrollo:

 Comprensión del problema.
 Optimización del proceso y dentro del proceso, las fases a seguir.
 Facilidad de mantenimiento.
 Mejora de la reusabilidad.
 Desde el punto de vista del cliente:

 Garantiza la calidad del producto.
 Mayor confianza.
6
1.3. Clasificación de las metodologías
1 Estructuradas
2 Tradicionales
3 Ágiles
 Estructuradas
 Los métodos estructurados 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 luego, para el Análisis.
 Crea los modelos de forma descendente.
 Son las orientadas a procesos, a datos y las mixtas.
 Ejemplos:
 MERISE (Francia),
 MÉTRICA (España),
 SSADM (Reino Unido).
 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)
 Métrica V3
© Copyright IBM Corp. 1987, 2006.
7
 Ágiles
 Un proceso es ágil cuando el desarrollo de software es:
 incremental (entregas pequeñas de SW, con ciclos rápidos)
 cooperativo (cliente y desarrolladores trabajan juntos 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)
 Ejemplo:
 XP (eXtreme Programming)
 SCRUM (Considerado un framework)
 Las Metodologías Ágiles valoran más…:

 Al individuo y las interacciones en el equipo de desarrollo más que a las
actividades y las herramientas.
 Desarrollar software que funciona más que conseguir una buena documentación.
 La colaboración con el cliente más que la negociación de un contrato.
 Responder a los cambios más que seguir, estrictamente, una planificación
1.3.1. Métrica v3
MÉTRICA V3
PROCESOS INTERFASES
Planificación (PSI) Desarrollo Mantenimiento (MSI) -Gestión de Proyectos (GP)
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 ESTRUCTURA GENERAL

del SI (IAS)
8
1.3.1. Métrica v3
 “La Metodología MÉTRICA Versión 3 ofrece a las Organizaciones un

instrumento útil para la sistematización de las actividades que den soporte
al ciclo de vida del software dentro del marco que permite alcanzar los
siguientes objetivos”.
Ministerio de Administraciones Públicas del Gobierno Español 2000
Métrica versión 3, MAP – Estado Español
 Métrica v3 se basa en Métrica v2.1 y ha tomado como referencia, la norma

ISO 12207.
 Todo ello incluye los avances de la tecnología del desarrollo del software.
1.3.1. Métrica v3
 Objetivos:
 Proporcionar o definir Sistemas de Información que ayude 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, además, 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.
1.3.2. RUP (Rational Unified Process)
IBM(R) Rational Unified Process(R)
9
 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.
 Es un producto de Rational Software Corp, adquirido por IBM.
 Incorpora las mejores prácticas para el desarrollo de software, de una manera
adaptable a un amplio rango de proyectos y entornos.
 Objetivo:
 Asegurar la producción de software de calidad:
 Que satisfaga los requerimientos del usuario.
 En tiempo y presupuesto, predecible.
 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; adecuado para proyectos medianos y grandes.
Comparación: MÉTRICA 3 - RUP
 Tanto Métrica 3 como RUP emplean el concepto: “trabajador”

 Ambas emplean el lenguaje UML.
MÉTRICA 3 RUP
Business Modeling
Estudio de Viabilidad del Sistema
Requirements
Análisis del Sistema de Información
Analysis & Design
Diseño del Sistema de Información
Construcción del Sistema de Información Implementation
Implantación y Aceptación del Sistema Test

Mantenimiento de Sistemas de Información Deployment
10
1.3.3. eXtreme Programming (XP)
12 PRINCIPIOS:
 Programación en pares.
 Propiedad colectiva del código.
 Refactoring.
 Pequeños releases.
 Diseño simple (yagni).
 Unidad de pruebas.
 Planear el juego.
 Estándares de codificación.
 40 horas a la semana.
 Metáfora.
 Participación del cliente.
 Integración continua.
 Movimiento “Agile Development” metodología “Ligera”.

 Desafiante.
 De moda.
 Motivación: “Promueva el Cambio”.
 Altamente incremental / Iterativo.
 Las Pruebas se programan primero.
 Programación en pares.
 “User Stories” como requerimientos.
 Jamás Casos de Uso.
 Se necesitan buenos desarrolladores.
 Bueno para grupos pequeños.
Figura: http://wigahluk.files.wordpress.com/2008/12/aeron20withtext.jpg
Historia de Usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número: Iteración Asignada: 2
Prioridad en Negocio: Alta
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail,
afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción
del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda
posteriormente acceder al artículo.
Observaciones: Fuente: www.dsic.upv.es
11
Spike para historia de usuario
Fuente: www.dsic.upv.es
1.4. Marco de Trabajo (Framework)
 ¿Qué es un Framework?
 “La palabra inglesa "framework" (marco de trabajo) 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.”
Fuente: http://es.wikipedia.org/wiki/Framework
 Tenemos varias áreas en las que se aplica los frameworks:

 Frameworks de desarrollo de software.
 Frameworks arquitectónicos.
1.4.1. SCRUM
 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 debes hacer”.
 “Scrum es considerado un framework de desarrollo ágil de software”
 Los pilares de Scrum son, principalmente, dos: el ciclo de vida iterativo e

incremental y diversas reuniones a lo largo del proyecto.
12
1.4.1. SCRUM
 Es liviano, iterativo e incremental.
 Simple.
 Adaptable.
 Enfocado en la productividad.
 Comunicación directa con Stakeholders.
 Equipo de trabajo coordinado.
 Divide el trabajo en Sprints (2-4 semanas).
 En cada Sprint se diseña, codifica y prueba.
1.4.1. SCRUM
 Roles:
 Product Owner
 Scrum Master
 Team
 Reuniones:
 Sprint (planificación, revisión
y retrospectiva)
 Daily scrum meeting
 Artefactos:
 Product Backlog
 Sprint backlog
 Burndown chart
 ¿Qué es un Framework en Arquitectura?

 John Zachman dice:
 “Un framework es una estructura lógica para clasificar y organizar las
representaciones descriptivas de una Empresa, las cuales son, especialmente,
significativas tanto para la dirección y control de la organización como para el
desarrollo de sus sistemas”
13
 Elección de un Framework
Un framework que ayude a

entender todos los elementos
que participan en la empresa
y cómo interactúan entre sí.
 Un Framework simplifica los conceptos de una arquitectura, haciéndola

fácil de entender, separando sus procesos adecuadamente y ajustándose
a un determinado tipo de empresa, lo cual los hace a algunos, bastante
específicos.
 La lista de framework’s es amplia, entre ellos encontramos:
 Zachman, TOGAF, DoDAF, FEAF, PERA, etc.
1.4.2. TOGAF
 TOGAF - Open Group Architecture

Framework (Framework Arquitectónico
del Open Group)
 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 Architecture Development Method

Fuente: www.ibm.com
14
1.4.2. TOGAF
 TOGAF se basa en las cuatro dimensiones:
• Estrategia • Blueprint
NEGOCIO
APLICACI
ONES
DATOS TI
• Estructura • HW / SW
1.4.2. TOGAF
 Metodología de desarrollo de arquitectura de empresa..
 Historia en defensa.
 Estándar abierto.
 Neutral.
 Amplia aceptación.
 Perspectiva holística.
 Proceso /
herramienta de
Planificación.
1.5. Estándares de la industria
CMMI
BPM
15
1.5.1. Modelo 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.
1.5.1. Modelo CMMI

CARACTERÍSTICAS DE MADUREZ
Organizaciones con procesos

Organizaciones con procesos Inmaduros
maduros
Procesos improvisados por los gerentes y
Procesos documentados
desarrolladores
Cada uno posee sus propios procesos Procesos seguidos consistentemente
Procesos comprometidos en orden a cumplir costos El rendimiento de los procesos es medido, seguido y
y fechas acordadas entendido
La calidad es predecible porque los procesos están bajo
Calidad difícil de predecir
control
Los procesos "viven" mientras viven los Los procesos "viven" por si solos y son mejorados
desarrolladores continuamente
Las nuevas tecnologías corren riesgo de caer en Las nuevas tecnologías son incorporadas de una manera
desuso disciplinada
Tiene pocos recursos propios Incrementa la productividad
Tiene altibajos en la productividad por rotación del
Entrega con la calidad esperada
recurso
Los empleados están descontentos Satisface a los clientes
1.5.1. Modelo CMMI
Primera Capa: NIVELES DE MADUREZ
NIVEL DESCRIPCIÓN
Punto base. La organización tiene procesos ad-hoc o caóticos. El éxito se debe a personas
1- Inicial
heroicas.
La organización empieza a guardar información. Hay definiciones, pueden repetirse éxitos
2- Repetible
anteriores.
Se conocen procesos estándares para desarrollar o mantener software. Hay prácticas de

3- Definido
Ingeniería de Software y de Administración de procesos.
Se usan datos recolectados. Las decisiones están basadas en datos cuantitativos. Los procesos
4- Administrado
son medidos, hay retroalimentación.
5- Optimizado La organización se dedica a mejorar continuamente. Se localizan debilidades y fortalezas.
16
1.5.1. Modelo CMMI
Segunda capa: Á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,

2- Repetible Gestión y acuerdo de 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,

3- Definido Procesos orientados a la organización, Formación, Gestión Integrada de proyecto, Gestión de riesgos,
Análisis y resolución de decisiones.
4- Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de la organización.
5- Optimizado Innovación y desarrollo.
1.5.1. Modelo CMMI: KPAs por Categoría
Categoría Áreas de Proceso

CATEGORÍA ÁREAS DE PROCESO
Gestión de Proyectos • Planificación de proyecto
• Monitorización y control de proyecto
• Gestión y acuerdo con proveedores
• Gestión integrada de proyecto
• Gestión de riesgos
• Gestión cuantificada de proyecto
Soporte • Gestión de la configuración

• Gestión de la calidad de procesos y productos
• Medición y análisis
• Análisis y resolución de decisiones
• Análisis y resolución de problemas
Ingeniería • Desarrollo de requisitos

• Gestión de requisitos
• Soluciones técnicas
• Integración de producto
• Verificación
• Validación
Gestión de Procesos • Definición de los procesos de la organización

• Procesos orientados a la organización
• Formación
• Rendimiento de los procesos de la organización
• Innovación y desarrollo
1.5.1. Modelo CMMI
17
1.5.1. Modelo CMMI vs RUP
 RUP es un proceso…  CMMI es un modelo estático…

 Que define quién debe hacer las  Que define áreas claves (PA) en las
cosas, qué debe hacerse, cómo y que se deben llevar a cabo prácticas
cuándo. específicas o genéricas
 Que mantiene modelos en lugar de  El hecho de implementar RUP en el

gran cantidad de documentación desarrollo de un proyecto implica que
ciertas KPA de CMMI sean alcanzadas
 Utiliza un lenguaje concreto y bien y otras no.
definido (UML).
Análisis RUP – CMMI Nivel 2

ÁREAS CLAVE DE
REVISIÓN
PROCESO
RUP define claramente el proceso de administración de requerimientos y
Gestión de Requisitos
aporta herramientas como los casos de uso, es una de las bases de RUP.
RUP habla de la planeación del proyecto de manera iterativa y del control
Planificación de proyecto
de riesgos.
Monitorización y control de
RUP define cómo debe ser el control del proyecto.
Proyectos
RUP es muy claro cuando se habla de administración de la configuración,

Gestión de la configuración
incluso es una de las mejores prácticas recomendada.
Análisis RUP – CMMI Nivel 2
ÁREAS CLAVE DE
REVISIÓN
PROCESO
Gestión y acuerdo de RUP no menciona nada sobre administración de acuerdos, es algo no
suministros considerado.
Medición y Análisis La medición y análisis no están contemplados, detalladamente, en RUP.
En la etapa de transición se lleva a cabo la verificación de la calidad aunque

Gestión de la calidad de no tan detallada como lo exige CMMI. La verificación de calidad del
procesos y productos producto está bien definida pero la evaluación de calidad del proceso no
está considerada.
18
1.5.2. BPM (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.
 Es considerado la disciplina
empresarial cuyo objetivo es
mejorar la eficiencia, a través de
la gestión sistemática de los
procesos de negocio, que se
deben modelar, automatizar,
integrar, monitorear y optimizar
de forma continua.
TRIÁNGULO DE BPM
Alineado con:
• Estrategia
• Visión
• Misión
 BPM permite modelar la arquitectura empresarial orientándola a procesos.

 Busca la mejora continua de los procesos.
 Alinea Procesos – Tecnología.
 Permite su monitorización y control.
 Aprovechar lo existente y hacer uso de lo nuevo.
Organización Enfoque
tradicional BPM
Sistemas centrados en Procesos de Negocio que son
Sistemas centrados en datos
modelados mediante workflows.
Enfocado a departamentos funcionales Enfocado en equipos por proceso
19
Antes de BPM
Después de BPM
1.6. Notaciones
UML
BPMN
1.6.1. Notación UML
 Debe entenderse como:

 Un estándar para modelado de sistemas.
 No es un estándar para procesos de software.
 Debe aplicarse en el contexto de un proceso de software.
 Es una notación, no es un proceso, no es una metodología.
20
1.6.2. Notación BPMN
 BPMN - Business Process Modeling Notation

 Notación desarrollada, inicialmente, por BPMI (Business Process Management
Initiative).
 Fusión con OMG (Object Management Group) en Junio de 2005.
Elementos centrales de los Diagramas
Ejemplo
21
Laboratorio: 4. Identificación de Objetos
 Ejercicio:
 Tiempo: 20 minutos
 En este laboratorio, usted:
 Compara las metodologías del mercado.
 Discute en grupo los beneficios de cada metodología y notación.
Contenido de Agenda

2.1. Conceptos básicos
 RUP:
 Proceso que implementa el ciclo de vida iterativo incremental.
 Es una guía sobre cómo usar, efectivamente, el UML.
 Está soportado por herramientas, que automatizan gran parte del proceso.
 Es un proceso configurable.
IBM® Rational Unified Process®
22
2.1.1. Características de RUP
Tomar el último feedback

Mitigar los mayores
riesgos temprano Integrado con
herramientas de
desarrollo
Iterativo e Basado en
Aumentar el reuso Incremental Casos de Uso
Captura de
requerimientos de
usuario
Centrado
en la Configurable
Arquitectura
Mejorar la calidad
Permite que el sistema Personalizar el proceso
evolucione
2.1.2. ¿Quiénes deben usar RUP?
Desarrolladores de
Software
Ingenieros de Proceso
2.2. Vista dinámica de RUP
23
2.2. Vista dinámica de RUP
 RUP divide el proceso de desarrollo en disciplinas, teniendo un producto al

final de cada disciplina.
 Cada disciplina se divide en cuatro Fases:
 Inception
 Elaboration
 Construction
 Transition
Cada fase concluye con un punto de control bien definido en el cual, ciertas decisiones críticas
deben ser tomadas, y por lo tanto, deben haber sido alcanzadas las metas clave.
2.2.1. Fases
Inception Elaboration Construction Transition

tiempo
INCEPTION Definir el objetivo del proyecto y elaborar el modelo del negocio.
Planificar el proyecto, especificar los Modelos y generar la base para las

ELABORATION
Arquitecturas.
CONSTRUCTION Construir el Producto.
TRANSITION Transición de los usuarios al nuevo producto.
a) Fase: Inception
 Resultados de la fase:
 Visión general de requerimientos esenciales del proyecto.
 Modelo de caso de uso inicial.
 Glosario inicial del proyecto.
 Caso de negocio inicial.
 Determinación inicial de riesgo.
 Plan del proyecto, que muestre fases e iteraciones.
 Modelo del negocio, si es necesario.
 Uno o varios prototipos.
24
b) Fase: Elaboration
 Resultado de la fase:
 Un modelo de caso de uso (completo, por lo menos en 80%).
 Requerimientos suplementarios (no funcionales).
 Una descripción de la arquitectura de software.
 Un prototipo de arquitectura ejecutable.
 Una lista de riesgos.
 Un plan de desarrollo para todo el proyecto (plan global).
 Especificar el proceso de desarrollo que se usará.
 Un manual de usuario preliminar.
c) Fase: Construction
 Resultados de la Fase:
 El producto de software integrado en las plataformas adecuadas.
 Los manuales del usuario.
 Una descripción de la versión vigente.
 Hito principal:
 Capacidad Operativa Inicial.
 En este punto, se decide si el software, los lugares y los usuarios están listos para
estar operativos, sin exponer el proyecto a altos riesgos. (versión “beta”)
d) Fase: Transition
 Se ingresa en la fase cuando un release está suficientemente maduro para

ser instalado en el dominio del usuario final. Esto incluye:
 “Beta testing” para validar el nuevo sistema contra las expectativas del usuario.
 Operación paralela con un sistema heredado que está siendo reemplazado.
 Entrenamiento de usuarios y del equipo de mantenimiento.
 HITO:
 Punto de Control de Release del Sistema.
 Se decide si los objetivos han sido alcanzados y si se podría comenzar otro ciclo
de desarrollo.
25
2.2.2. Iteraciones
 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.
Iteraciones según Patrón de Ciclo de Vida
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
2.3. Elementos
CUÁNDO FASES E ITERACIONES

ocurre el proceso
CÓMO WORKFLOW / ACTIVIDADES / TAREAS

ocurre el proceso
QUÉ PRODUCTOS DE TRABAJO

se obtiene del proceso
QUIÉN WORKERS
hace el proceso
ESTRUCTURA ESTÁTICA DEL RUP
26
2.3. Elementos
Define la conducta y
responsabilidades de un Unidad de
TAREA Trabajo
individuo o de un conjunto de
individuos
ROL
Describe un
Analista Caso de Uso
Es responsable de: PRODUCTO DE
TRABAJO
Una pieza de información que
es producida, modificada o
usada por un proceso
Use case
Use case Package
Elementos básicos del RUP 2003
2.3.1. Roles
 Un Rol define el comportamiento y las responsabilidades de un individuo.
ROL
Responsable Lleva a cabo
Producto de
Tareas
Trabajo
27
2.3.1. Roles
 Es como un “sombrero” que la persona usa durante el proyecto:

 Una persona puede tener varios sombreros.
 Es el rol que desempeña en un momento dado.
 Responsabilidades:
 Hacer una serie de tareas.
 Ser el responsable de una serie de Producto de Trabajo /artefactos.
2.3.1. Roles
 Analyst  Testing professional

 Business-Process Analyst  Test Designer
 Business Designer  Tester
 Business-Model Reviewer
 Requirements Reviewer  Manager
 System Analyst  Change Control Manager
 Use-Case Specifier  Configuration Manager
 User-Interface Designer  Deployment Manager
 Process Engineer

Developer  Project Manager
 Architect  Project Reviewer
 Architecture Reviewer  Other
 Capsule Designer  Any Worker
 Code Reviewer  Course Developer
 Database Designer  Graphic Artist
 Design Reviewer  Stakeholder
 Designer  System Administrator
 Implementer  Technical Writer
 Integrator  Tool Specialist
2.3.2. Tareas
 Una tarea es una unidad de trabajo que se asigna a un Rol.

 Una tarea tiene un conjunto de pasos (steps) para poder desarrollarla.
 Es asignada a un Rol específico.
 Los pasos (steps) se categorizan en: Rol

 Thinking Steps Responsable Lleva a cabo
 Performing Steps
Producto de Tareas
 Reviewing Steps Trabajo
28
2.3.2. Tareas Tareas
 Una tarea lleva entre un par

Ejemplos:
de horas y un par de días,
 Planificar una iteración.
involucra uno o varios roles y
un número pequeño de  Especificar un caso de uso.
artefactos.  Encontrar actores y casos de uso.
 Las tareas se consideran en la  Ejecutar pruebas de performance.
planificación y evaluación del
progreso del proyecto.
Asignación de actividades
Recursos Rol Tareas

Miguel
Diseñador Diseño de Objetos
.....
José Luis
Autor del USE-CASE Especificaciones del USE - CASE
.....
Sandra Diseño de l USE- CASE

Diseñador del USE - CASE
.....
Alfredo Controlador de la Calidad Revisión del Diseño

.....
Arquitecto Análisis y Diseño de la

Juan Arquitectura .....
Tareas por Rol
Ejemplo: Analista de Sistemas
29
2.3.3. Productos de trabajo
 Resultado parcial o final, que es

producido y usado durante el proyecto.
 Son las entradas y salidas de las tareas.
 Puede ser un documento, un modelo o un
elemento de modelo. Rol
Responsable Lleva a cabo
Producto de trabajo Tareas
Productos de trabajo por rol
Ejemplo: Analista de Sistemas
RUP 2003 vs RUP 2006
 Diferencias
RUP 2,003 RUP 2,006 Forma Gráfica
Actividad Tarea
Detalle de Flujo de trabajo Actividad
Rol Rol
Artefacto Producto de Trabajo
30
2.4. WORKFLOWS
2.4. WORKFLOW
 Es 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.
2.4. WORKFLOW
Clasificación de los Workflows
Core Workflow
Iteration Workflow
Activity
31
2.4.1. CORE WORKFLOW
 Los Core Workflows representan una división de los workers y actividades

en agrupaciones lógicas.
Workflows de
Proceso
Workflows de
Soporte
2.4.2. ITERATION WORKFLOW
 Los Iteration Workflows representan una visión de las actividades, pero por
cada iteración dentro de cada fase.
Ejemplo:
Iteración 1 de la
fase de
Elaboración.
2.4.3. ACTIVITY (Workflow Detail en RUP 2003)
 Es una descripción de un workflow, a más bajo

nivel.
 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 conjunto de tareas por
desarrollar.
32
2.5. Elementos adicionales del proceso
 RUP tiene otros elementos para hacer más fácil el proceso.
Concepts
Guidelines
Templates
Tool mentors
Laboratorio: 1.5. Herramienta
 Ejercicio 5:
 Identificará la herramienta que contiene la Metodología.
 Navegará por la herramienta, identificando sus principales elementos.
Contenido de Agenda

33
3.1. Fundamentos del UML
UML = Unified Modeling Languaje
 El lenguaje unificado de modelado de objetos (UML) 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.
3.1.1. Historia de UML UML 2.4.1

Ago 2011
UML 2.3
UML 2.2 2010
2009
UML 2.0
2004
UML 1.5
2003
UML 1.4
2000
UML 1.3 Revisiones menores
1999
UML 1.2
Nov ‘97 1998 UML aprobado
por el OMG
UML fue desarrollado por Grady
Booch, Ivar Jacobson y James
Rumbaugh de Rational Software
Corporation, con la participación de
usuarios, diseñadores de software y
promotores; y se basa en las
metodologías de OMT, Booch y
OOSE.
3.1. Fundamentos del UML
UML:
 Debe entenderse como:
 Un estándar para modelado de sistemas.
 No es un estándar para procesos de software.
 Debe aplicarse en el contexto de un proceso de software.
 Es una notación, no es un proceso, no es una metodología.
 Establecido como estándar para documentar el proceso de ingeniería de
software.
 Combina lo mejor del modelado de procesos, objetos, datos y componentes.
34
3.2. Estructura de UML
ESTRUCTURA UML
BLOQUES DE
MECANISMOS COMUNES ARQUITECTURA
CONSTRUCCIÓN
3.2. Estructura de UML
3.2.1 Bloques de Construcción

A. Elementos
B. Relaciones
C. Diagramas
3.2.2 Mecanismos comunes del UML
A. Especificaciones
B. Adornos
C. Divisiones comunes
D. Mecanismos de extensibilidad
3.2.3 Arquitectura
3.2.1. Bloques de construcción
 El vocabulario UML incluye 3 clases de bloques de construcción:
BLOQUES DE CONTRUCCIÓN
ELEMENTOS RELACIONES DIAGRAMAS
35
A. Elementos UML
ELEMENTOS UML
ESTRUCTURALES COMPORTAMIENTO AGRUPACIÓN ANOTACIÓN
a) Elementos Estructurales
 7 Elementos estructurales:
 Clases.
 Interfaz.
 Colaboración.
 Casos de Uso.
 Clase Activa.
 Componente.
 Nodo.
 CLASES
 La clase es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica.
Producto
Nombre de la clase
-CodProducto
-DesProducto
-StockAct
-Precio Atributos
+BuscarProducto()
+GrabarProducto()
+EliminarProducto()
Operaciones
36
 INTERFAZ
 Es una colección de operaciones que especifican un servicio de una clase o
componente. Por lo tanto, una interfaz describe el comportamiento visible
externamente de ese elemento.
 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.
Cadena de
Responsabilidad
 CASOS DE USO
 Descripción de un conjunto de secuencias de acciones que un sistema ejecuta y
que produce un resultado observable de interés para un actor particular.
Consultar Producto
37
 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()
 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.X
 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
38
b) Elementos de Comportamiento
 Elementos de Comportamiento
 Representan las partes dinámicas de los modelos UML. Estos son los verbos de un
modelo, representan comportamiento en el tiempo y el espacio.
 Existen dos tipos:

 Interacción.
 Máquina de Estados.
 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
 MÁQUINA DE ESTADOS
 Es un comportamiento que 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.
Esperando
39
c) Elementos de Agrupación
AGRUPACION
 Elementos de Agrupación:
 Se utiliza para agrupar elementos de modelado, semánticamente, relacionados
en unidades cohesivas.
 Elemento:
 El paquete (Package)
 Es la forma que tiene UML de
agrupar elementos en subsistemas. Reglas del
Negocio
 Un sistema pequeño puede tener un
único paquete.
d) Elementos de Anotación
ANOTACIÓN
 Elementos de Anotación:
 Se utiliza para anexar al modelo información relevante.
 Elemento:
 La nota
 Una nota es como el equivalente gráfico de un papel adhesivo.
B. Relaciones UML
 Representan los enlaces de los elementos entre sí.

 Existen 4 tipos de relaciones en UML.
RELACIONES UML
DEPENDENCIA ASOCIACIÓN GENERALIZACIÓN REALIZACIÓN
40
a) Relación de Dependencia
 Relación semántica donde un elemento (independiente) puede afectar a

otro elemento (dependiente)
Flecha de dependencia
b) Relación de 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 ente un todo y sus partes. Generalmente, incluye roles y
multiplicidad.
0..1 *
patrón empleado
c) Relación de Generalización
 El elemento origen es una especialización del elemento destino más

general y se puede sustituir por éste.
 Relación donde los objetos del elemento hijo, pueden sustituir a los
elementos del elemento padre.
41
d) Relación de Realización
 Es una realización semántica entre clasificadores, en donde un clasificador

especifica un contrato que otro clasificador garantiza que cumplirá.
C. Diagramas UML
 Los diagramas agrupan los elementos entre sí.
DIAGRAMAS UML
UML 1.X UML 2.X
a) Diagramas UML 1.X
State
State de
Use Diagramas
Diagrams
UseCase
Case de
Diagramas
Diagrams
Clases State
Use Diagrams State de
UseCase
Case de
Diagramas Diagrams
Casos de Uso
Diagramas
Diagrams
Diagrams
Diagrams
Diagrams Objetos
Secuencia
Scenario
Scenario de State
State de
Diagramas
Diagrams Diagramas
Diagrams
Diagrams
Colaboración Diagrams
Componentes
Modelos
Scenario
Scenario de
Component
Component
Diagramas
Diagrams Diagramas
Diagrams
Diagrams
de
Diagrams
Estados Distribución
Diagramas de
Actividad
42
Caso de Uso de Negocio

 DIAGRAMAS DE CASO DE USO
 Los casos de uso de negocio representan los
procesos del negocio que son usados por
los roles del negocio.
 Los casos de uso de sistema describen un
sistema desde el punto de vista del usuario.
Caso de Uso de Sistema
uc Primary Use Cases
De spachar
productos
Almacenero
Re gistrar
Inv e ntario
 DIAGRAMA DE CLASES OrdenCompra

-NumOrdCom : Char
-f -wProvee
Proveedor
-Proveedor_id : Char
Representa la estructura estática,

-FecOrdCom : Date -RazonSocial : String
 -GlosaOC : String -DireccionLegal : String
en términos de clases y relaciones.

 Está compuesto por los siguientes
Ins_OrdCompra
elementos: -CantInsumos : Double
-PreInsumos : Decimal
Insumo
 Clases -InsumoId : Char
-wInsumo -DesInsumo : String
-x
-StkInsumo : Double
 Relaciones -PreInsumo : Decimal
+GrabarInsumo()
+ActualizaInsumo()
+DesactivaInsumo()
-. FamInsumo
-FamInsId : Char
-DesFamIns : String
-wFamIns +CargaComboFamilia()
 DIAGRAMA DE OBJETOS
 Modelan las instancias de los
elementos contenidos en los
diagramas de clases. Lanificio Sur : 3.Capa Datos::Proveedor
Proveedor_id : Char = P0098
RazonSocial : String = Lanificio
 Instantánea de un conjunto de DireccionLegal : String = Av.Los Quechuas
objetos y sus relaciones en un OC 56 : 3.Capa Datos::OrdenCompra

momento concreto. NumOrdCom : Char = 56
FecOrdCom : Date = 15/04/09
GlosaOC : String = Urgente
 Contienen objetos y enlaces.
43
 DIAGRAMA DE SECUENCIA
sd Add To Shopping Cart
 Es una representación estructurada

de comportamiento como una serie Cl i ent
ItemsPage AddToBasket
de pasos secuenciales, a lo largo

del tiempo. addLi neItem()
:ShoppingBasket
 Se usa para representar el flujo de addLi neItem()
trabajo, el paso de mensajes y

cómo los elementos, en general,
cooperan a lo largo del tiempo (from Actors)
Cl i ent
para lograr un resultado.
 DIAGRAMA DE COLABORACIÓN
 Muestra las interacciones entre los
elementos en tiempo de ejecución
en forma semejante a un
diagrama de Secuencia. No
obstante, los diagramas de
Colaboración se usan para
visualizar relaciones inter objetos,
mientras que los diagramas de
Secuencia son más efectivos para
visualizar procesamiento, a lo
largo del tiempo.
 DIAGRAMA DE ESTADO
 Muestra el comportamiento solicitar()
solicitada
[verificar=no]
dinámico (orientado al evento), entry/verificar prerequesitos

exit/UninterpretedAction1
rechazada
con el propósito de modelar el consultar()[ solo si,,,,] [verificar=si]
ciclo de vida de un objeto.

cancelar() aprobada
Muestra la secuencia de estados

cancelada

de un objeto o la interacción cancelar()[si no hay deuda]
directa durante su vida, en activa
respuesta a los estímulos recibidos,

debitar()
en conjunto con sus respuestas y bloqueada CancelaRobo(pin)
acciones.
44
 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.
 DIAGRAMA DE COMPONENTES
 Describen los elementos físicos y sus relaciones en el entorno de realización.
 Los componentes representan todos los tipos de elementos de software que
entran en la fabricación de aplicaciones informáticas.
«executable»
sistema.exe
«document» «library»
Ayuda.doc Elog.dll
«library»
Gestor
 DIAGRAMA DE DESPLIEGUE
 Muestran la configuración de
los distintos materiales que
forman parte de un sistema y
la distribución de los
programas ejecutables sobre
estos materiales.
45
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
 DIAGRAMA DE ESTRUCTURA COMPUESTA.

 Se emplea para visualizar de manera gráfica, las partes que definen la
estructura interna de un clasificador.
 DIAGRAMA VISIÓN DE INTERACCIÓN
 Se emplea fundamentalmente 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.
46
 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
 Equivalente al diagrama de colaboración del OMG UML 1.x, permite
especificar interacciones entre objetos que conforman la estructura interna de un
clasificador.
Estructura taxonómica del UML 2.0
DIAGRAMA
Diagrama de Diagrama de
Estructura Comportamiento
Diagrama de Diagrama de Diagrama de

Diagrama de Diagrama de Diagrama de Diagrama de
Objetos Clases Componentes
Actividad Casos de Uso Interacción Maquina de Estado
Diagrama de Diagrama de Diagrama de

Estructura Compuesta Paquetes Despliegue
Diagrama de Diagrama de Diagrama de Diagrama de

Secuencia Comunicación Vision de Interacción Tiempos
47
Estructura taxonómica del UML 2.3
Estructura taxonómica del UML 2.4.1
Marcos o frames
 En OMG, a partir de UML 2.0 los diagramas aparecen dentro de un marco

(frame) que posee una etiqueta para indicar el tipo de diagrama.
etiqueta
CasoUso1
Actor1 CasoUso2
48
Etiquetas
 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 Diagramas de Interacción
 dep Diagrama de Despliegue
3.2.2. Mecanismos comunes
 Existen cuatro mecanismos comunes que se aplican de forma consistente, a

través de todo el lenguaje.
MECANISMOS COMUNES
MECANISMOS DE
ESPECIFICACIONES ADORNOS DIVISIONES COMUNES
EXTENSIBILIDAD
A. Especificaciones
 UML no es solo 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.
Anular Pedido
49
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.
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
 Todos los bloques de construcción de UML (y no solo las clases) presentan

divisiones.
 Ejemplo:
 Interfaz – Implementación Julio : Alumno
Alumno Codigo = A022

 Clase - Objeto Apellidos = Paz
-Codigo Nombres = Julio
-Apellidos
-Nombres Julio : Alumno
Julio
Clase - Objeto
D. Mecanismos de extensibilidad
 UML es abierto-cerrado y es posible extender el lenguaje de manera

controlada.
MECANISMOS DE EXTENSION
ESTEREOTIPOS VALORES ETIQUETADOS RESTRICCIONES
50
a. Estereotipos
 Un estereotipo permite la metaclasificación de un elemento UML.

 Permite a los usuarios, añadir nuevas clases de elemento del modelo sobre
el núcleo predefinido por UML.
 En la versión 2.4.1es indispensable se escriba la primera letra con
mayúscula.
«Business Use Case»
Registrar
Devolucion Libro
__________________________
Si paso la fecha de devolucion
«extends»
«Business Actor»
Lector
«Business Use Case»
Registrar Pago de
Mora
a. Estereotipos
ESTEREOTIPO/ SE APLICA AL
SIGNIFICADO
PALABRA CLAVE SÍMBOLO
Actor Clase Especifica un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando
interactúan con éstos.
Boundary Clase Maneja comunicaciones entre el entorno del sistema y el sistema, suelen proporcionar la interfaz del
sistema con un usuario o con otro sistema.
Control Clase Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que
se especifica en el caso de uso, representan su dinámica.
Entidad Clase Especifica una clase persistente. Este tipo de clase suele reflejar entidades del mundo real o
elementos necesarios para realizar tareas internas al sistema. También se denominan clase dominio
Business Actor Actor Especifica un actor que representa un ROL desempeñado en relación al negocio por alguien o algo
en el ambiente de negocio. Un Actor de negocio representa a algún participante fuera del alcance
del negocio y, por lo tanto, tiene una comprensión del comportamiento visible del negocio.
b. Valores etiquetados
 Es una extensión que permite añadir nueva información en la

especificación del elemento.
 Gráficamente, se representa como una cadena de caracteres entre llaves,
asociada al nombre del elemento.
Pagos
{Version = 2.5,
estado = no verificado}
51
c. Restricciones (constraints)
 Se puede añadir nueva semántica o cambiar reglas existentes.

 UML no especifica una sintaxis particular para restricciones que aparecen
entre corchetes, entonces pueden ser expresados en lenguaje natural.
PersonaJuridica
CuentaBancaria
{O lógico}
PersonaNatural +esposo
-genero
0..1
+esposa 0..1
{genero.esposo=masculino y
genero.esposa=femenino}
3.2.3. Arquitectura UML
 Phillippe Kruchten describe la arquitectura UML en “Vistas 4 + 1”
3.3. Reglas de UML
 Consideraciones:
 Los bloques de construcción de UML no pueden combinarse de cualquier manera.
 UML tiene unas 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.
52
3.3. Reglas de UML
REGLAS UML
NOMBRES ALCANCE VISIBILIDAD INTEGRIDAD EJECUCIÓN
3.3.1. Reglas de nombres
 Reglas de Nombres:
 Cómo llamar a los elementos, relaciones y diagramas.
 Ejemplo:
 Relaciones de dependencia entre casos de uso: «Include» y «Extend»
3.3.2. Reglas de alcance
 Reglas 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”
53
3.3.3. Reglas de visibilidad
 Reglas de visibilidad:
 Cómo se pueden ver y utilizar esos nombres por otros.
 Ejemplo:
 Private, solo el propio clasificador puede utilizar la característica.
3.3.4. Reglas de integridad
 Reglas 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 de ejecución
 Reglas de Ejecución:
 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.
54
Laboratorio: 1.6. Plantilla UML
 Ejercicio 6:
 Reconocerá el ambiente de la herramienta usada.
 Establecerá la estructura inicial de un proyecto.
 Identificará y creará los estereotipos que usará en sus proyectos futuros.
 Generará una plantilla de trabajo.
55

PowerPoint 2 - Introducción RUP y UML PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PowerPoint 2 - Introducción RUP y UML PDF

Cargado por

Copyright:

Formatos disponibles

División de Alta Tecnología

UML 2.4.1 for Developer – Enterprise Architect

Copyright © Todos los Derechos Reservados - Cibertec Perú SAC

Cap. 2 Introducción al RUP y al UML

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

 Metodologías y Estándares en el desarrollo de software

 Para un correcto proceso de

1.1.1. El ciclo de vida del software

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

Fuente: Ian Sommerville

1.1.2. Tipos de procesos

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

1.1.2. Tipos de procesos

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

Ciclo de Vida del Sistema

1.1.2. Tipos de procesos

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

Ciclo de Vida del Sistema

1.1.2. Tipos de procesos

 Ciclo de Vida del sistema

Ciclo de Vida Organización/Negocio: Empresa

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

Ciclo de Vida del Sistema

1.1.2. Tipos de procesos

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

Ciclo de Vida del Sistema

1.1.2. Tipos de procesos

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

Ciclo de Vida del Sistema

 Metodologías vs. ciclo de vida

1.2.2. Características de una metodología

 Existencia de reglas predefinidas.

1.2.3. ¿Para qué usar una metodología?

 Desde el punto de vista de

1.2.3. ¿Para qué usar una metodología?

 Desde el punto de vista del desarrollo:

1.2.3. ¿Para qué usar una metodología?

 Desde el punto de vista del cliente:

1.3. Clasificación de las metodologías

1.3. Clasificación de las metodologías

1.3. Clasificación de las metodologías

1.3. Clasificación de las metodologías

1.3. Clasificación de las metodologías

 Las Metodologías Ágiles valoran más…:

Planificación (PSI) Desarrollo Mantenimiento (MSI) -Gestión de Proyectos (GP)

- Implantación y aceptación ESTRUCTURA GENERAL

 “La Metodología MÉTRICA Versión 3 ofrece a las Organizaciones un

 Métrica v3 se basa en Métrica v2.1 y ha tomado como referencia, la norma

1.3.2. RUP (Rational Unified Process)

IBM(R) Rational Unified Process(R)

1.3.2. RUP (Rational Unified Process)

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

1.3.2. RUP (Rational Unified Process)

Comparación: MÉTRICA 3 - RUP

 Tanto Métrica 3 como RUP emplean el concepto: “trabajador”

Implantación y Aceptación del Sistema Test

1.3.3. eXtreme Programming (XP)

1.3.3. eXtreme Programming (XP)

 Movimiento “Agile Development” metodología “Ligera”.

1.3.3. eXtreme Programming (XP)

1.3.3. eXtreme Programming (XP)

Spike para historia de usuario

1.4. Marco de Trabajo (Framework)