Desarrollo de software orientado a objetos

Unidad 1:El proceso unificado de software

RUP

Agenda

Introducción. La Estructura del Proceso Unificado Características del RUP RUP y UML

Introducción

¿Qué es un proceso de software? Es un marco de trabajo que permite la

programación de las tareas necesarias para construir un software de alta calidad.

Proceso de ingeniería de

softwareRequerimientos Software

CaracterísticasMarco común de trabajo del proceso

Actividades de protección y administración

Actividades del marco del trabajo

Conjunto de tareasTareas

Hitos, Entregas

Puntos SQA

EXAMENEXAMEN

Modelos

Para resolver los problemas reales de las organizaciones, los ingenieros de software deben incorporar una estrategia de desarrollo que integre el proceso, los métodos y las herramientas necesarias para la construcción del software.

Existen síntomas de problemas en el desarrollo del software ….. Mala comprensión de las necesidades del

usuario. Incapacidad de afrontar cambios en los

requerimientos. Módulos que no calzan entre si. Software difícil de mantener y extender. Descubrimiento tardío de defectos en el

proyecto ....

Existen síntomas de problemas en el desarrollo del software ….. ….. Pobre calidad del software. Pobre e inaceptable rendimiento. Falta de definición de

responsabilidades en los miembros del equipo.

Falta de confiabilidad en el proceso de construir y producir.

Síntomas• necesidades usuarios• requerimientos

cambiantes• módulos no calzan• poco mentenible• tardía detección• baja calidad• baja performance• versiones y cambios • l iberación y distr ibución

Causas• requerimientos

insuficientes• comunicación ambigua• arquitecturas frágiles• complejidad excesiva• inconsistencias no

detectadas • testing pobre• evaluación subjetiva• desarrollo en cascada • cambios no controlados• automatización insuficienteDiagnóstico

Sin embargo….tratar los síntomas no resuelve el problema

Causas de los problemas de desarrollo de software Administración inadecuada de

requerimientos. Comunicación ambigua e imprecisa. Arquitectura frágil. Complejidad excesiva. Inconsistencias no detectadas entre los

requerimientos, el diseño y la programación.

Pruebas insuficientes. …

Causas de los problemas de desarrollo de software

…. Evaluación subjetiva del avance del

proyecto. Enfrentamiento tardío de riesgos

(desarrollo en cascada). Propagación de cambios sin control. Bajo nivel de automatización.

......Enfrentando las Causas se eliminan los Síntomas

Desarrolle iterativamente. Administre requerimientos. Use arquitectura de componentes. Modele el software visualmente. Verifique calidad. Controle los cambios.

Causas

Mejores Prácticas

Las mejores prácticas enfrentan las causas

EXAMENEXAMEN

Las mejores prácticas de software

Las mejores prácticas de software son propuestas comercialmente probadas de desarrollo que usadas en forma combinada atacan la raíz de las causas de las fallas, eliminando los síntomas y permitiendo el desarrollo y mantenimiento de software de calidad de manera predictiva y reiterativa.

Las mejores prácticas se refuerzan entre si

ControleCambios

VerifiqueCalidad

ModeleVisualmenteDesarrolle

Iterativamente

Use Arquitecturade Componentes

Asegura participación del usuariomientrás evolucionan requerimientos

Valida tempranamentelas decisiones arquitectónicas

Permite manejar la complejidadde diseñar incrementalmente

Mide la calidad en forma oportuna y frecuente

Evoluciona la línea base incrementalmente

AdministreRequerimientos

¿Que es el RUP?

Es un proceso de ingeniería de software. Se describe entre otras cosas como:

Centrado en una arquitectura. Guiado por casos de uso. Iterativo e incremental. Enfrenta riesgos.

¿Que es el RUP?

Provee: Lineamientos, templates para herramientas, que guían una implementación efectiva de las6 Mejores Practicas.

Se define como una “Base de Conocimiento” Soportada en la Web. Con búsquedas e hiper-vínculos.

Estructura del proceso unificado

Estructura del Proceso Unificado

ambiente

Modelo del negocio

Implementación - Codificación

Prueba - Test

Análisis y diseño

Iter.#1

FasesDisciplinas del Proceso

Iteraciones - Tiempo

Disciplinas de Soporte

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Despliegue

Adm. configuración y cambios

Requerimientos

Elaboración TransiciónConcepción Construcción

Iteracion(es)Preliminar(es)

Adm. del proyecto – Gestión del Proy.

EXAMENEXAMEN

Estructura del proceso unificado Dimensiones

El eje horizontal representa el tiempo y muestra el ciclo de vida del proceso tal y como se desenvuelve. Muestra el aspecto dinámico (iteraciones).

El eje vertical representa los flujos de trabajo (workflows) nucleares, que agrupan actividades por su naturaleza. Representa el aspecto estático

Estructura dinámica

Tiempo

Concepción Elaboración Construcción Transición

Concepción Define el alcance del proyecto y eldesarrollo de los casos del negocio.

Elaboración Planifica el proyecto, especificalas características y define loscimientos de la arquitectura.

Construcción Construye el producto.

Transición Implementa el producto a sususuarios.

Principales hitos de control

Tiempo

Visión Soportebase de la

Arquitectura

CapacidadInicial

Versióndel

Producto

Concepción Elaboración Construcción Transición

Ciclo de Vida

Una i teración es una secuencia de actividades con un plan establecido y criterios de evaluación, cuyo resultado es una versión o release.

Iteración ... Iteración Iteración ... Iteración ...

Release Release Release Release Release Release Release Release

Iteración ...

Concepción Elaboración Construcción Transición

Ciclo de Vida-Dos perspectivas

Estructura Estática

¿Cómo ocurre el proceso y sus detalles?

¿Qué se produce u obtiene?

¿Quién lo hace o se responsabiliza?

¿Cuándo ocurre el proceso?Fases e iteraciones

Flujos del ProcesoActividades, pasos

ArtefactosModelos, reportes y/o

documentos

Trabajadores

Estructura Estática

Descripción de un caso de Uso

Paquete de Caso de Uso

Caso de Uso

Es responsable por

Analista

Artefacto

Es una pieza de información producida, modificada o usada por un proceso

Trabajador

Es un rol asumido por un empleado Es una unidad

de trabajoActividad

Estructura Estática

Trabajador - el Quién Actividades - el Cómo Artefactos - el Qué Workflows - el Cuándo

Trabajador (Worker) El término Worker define el comportamiento y

responsabilidades de un individuo o un grupo de individuos trabajando juntos como equipo.

Trabajador

Artefactos Actividades

Responsable Lleva a cabo

Actividad

Es una unidad de trabajo de un Worker que: tiene un propósito claro. es expresada normalmente en

términos de creación o actualización de artefactos.

es asignada a un worker específico

Actividades Están fraccionadas en “pasos”. Los

pasos se agrupan en: Pasos pensantes. Pasos de desarrollo. Pasos de revisión.

ActividadPasos

Guías de Trabajo

Tool Mentor

Tiene

TieneTiene

Artefacto

Es una pieza de información que es producida, modificada o usada por un proceso.

Trabajador

Artefacto Actividad

Responsable

Resultado

Input

Reporte Guías Template

Tiene Tiene Tiene

+ Modelo

Workflows

Es una secuencia de actividades que produce un resultado de valor observable. En terminos de UML un workflow puede

ser expresado como un diagrama de secuencias, de colaboración o de actividades.

RUP usa un diagrama de actividad para representar el workflow.

Workflows

El RUP organiza el conjunto de actividades usando: Workflows del proceso Workflows de iteración Workflows de detalle

Workflows del proceso

Los workflows del proceso agrupan las actividades propias de las disciplinas de ingeniería de software.

Hay seis workflows de de procesos propiamente dichos: Modelo del negocio Requerimientos Análisis y Diseño Implementación Prueba Distribución

Workflows del proceso

.......y tres workflows de apoyo: Configuración y administración de

Cambios Administración del proyecto Definición del ambiente

Workflows de iteración Es otra forma de mostrar el proceso, describiéndolo

desde la perspectiva de “lo que sucede en una iteración típica”.

Estas actividades se establecen en un cronograma. Disciplinas del Proceso

Disciplinas de Soporte

ManagementEnvironment

Business Modeling

ImplementationTest

Analysis & Design

Preliminary Iteration(s)

Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Workflow de Iteración

Fases

Workflows de detalle Es una descripción de un workflow del

proceso a más bajo nivel. RUP los usa para expresar: un grupo específico de actividades que

están relacionadas y que son desarrolladas juntas o en un modelo cíclico.

actividades que son desarrolladas por un grupo de gente.

actividades que producen un resultado intermedio interesante.

Modelos y WorkflowsCada workflow describe cómo crear y mantener un “modelo” en particular

DesignModel

ImplementationModel

TestModel

realized by

implemented by

RequirementsWorkflow

Analysis /DesignWorkflow

ImplementationWorkflow

Test Workflow

Use-CaseModel

BusinessModeling

Business Model

verified by

Características del RUP

Características del RUP

Las principales características del RUP son: Centrado en una arquitectura. Guiado por casos de uso. Iterativo e incremental. evolutivo Manejo de proyectos y riesgos. Administración y control de cambios.

Características: Centrado en una arquitectura. Los modelos son los vehículos para visualizar,

especificar, construir y documentar la arquitectura. RUP prescribe el refinamiento sucesivo de una

arquitectura ejecutable. Vista 4+1 arquitectura ruc

tiempo

Arquitectura

Inception Elaboration Construction Transition

“Vista 4+1” modelo de arquitectura

Vista de Proceso

RendimientoEscalabilidad agregar o quitar …

Operatividad

Integradores de sistemas

Vista Estructural

Estructura

Analistas/Diseñadores

Vista de Implementación

Programadores Administración

del Software

Vista de Despliegue

Topología Entrega, instalación

comunicación

Ingenieros de sistemas

Vista Casos de Uso

Usuarios Finales Funcionalidad

El dominio de la arquitectura

Cualidades

Procesos

Representación

EL “qué” El “para qué”

El “cómo”El “quién”

Característicasdel Sistema

Arquitectura Requerimientos

Atributos decalidad del sistema

Satisface

Condiciona

Organización

Arquitecto

Técnicas

Participantes

Define roles

Produce

Sigue

DefineTecnología

La Arquitectura y las Iteraciones

Modelo de Casos de

Uso

Modelo del

Diseño

Modelo de despliegue

Modelo de Prueba

Modelo de Implementación

Contenido

RUP es la armazón de un proceso

No existe un proceso universal • RUP está diseñado para la flexibilidad y la extensión.

» Permite una variedad de estrategias de ciclos de vida.» Selecciona que artefactos producir y cuado. » Define actividades y roles.» Aplica los conceptos de modelamiento (UML)

Características: Guíado por Casos de Uso

Requer. Implem. Prueba

Los casos de uso vinculan a todos los workflows juntos

Análisis Diseño

Manejo de Casos de Uso

Los Casos de Uso manejan las Iteraciones Conduce un buen número de actividades

de desarrollo. Creación y validación de la arquitectura del

sistema. Definición de casos de prueba y

procedimientos. Planeamiento del iteraciones. Creación de la documentación del usuario. Despliegue del sistema

Sincroniza el contenido de diferentes modelos.

Artefactos de Requerimientos

Especificaciones Complementarias

Requerim.

Funcional No Funcional (URPS)

Casos de Uso

Casos de Uso - Conceptos

Actor

Caso de Uso

• Un actor es algo o alguien fuera del sistema que interactúa con este.

• Un caso de uso es una secuencia de acciones ejecutadas por un sistema para obtener un resultado de valor para un actor

Actores y ámbito del sistema

¿Límites delSistema?

Sistema Agencias

Cajero Bancario

Cliente

Sistema Bancario

¿Qué hay en un modelo de Casos de Uso? Los actores y sus descripciones Diagramas de Casos de Uso mostrando

relaciones Para cada caso de uso

Nombre y pequeña descripción Flujo de eventos Pre-condiciones y post-condiciones Requerimientos especiales Opcionalmente, prototipos de interfaz usuaria Otros diagramas, como diagramas de

actividad o diagramas de estado

Desde los Casos de Uso hasta los Ejecutables

Casos deUso

Clases deAnálisis

CódigoFuente

ExecClases deDiseño

Casos de Uso e Interfaces

Desde los casos de uso se pueden obtener prototipos de las pantallas propuestas

Ellas constituyen la base del diseño de interfaz usuario.

Casos de Uso y Documentación

Modelo de Casos de Uso

Implantación

Material soporte usuarios•Manual de Usuario•Help en línea•Demos•Tutoriales•Material entrenamiento

Casos de Uso y el Modelo de Pruebas

EspecificacionesComplementarias

Modelo de Casos de UsoTest

Modelo de Test

Modelo de Casos de Uso y otros modelos

verificaciónrealización

Modelo de Casos de Uso(requerimientos)

Modelo de Implementación

(código fuente)

Modelo de Test(casos de test y procedi-

mientos de test)

influencia

Modelo de diseño

(clases y objetos)

Casos de Uso e Iteraciones

Modelo de Casos de Uso

Plan de Iteración

Plan detallado para unaiteración en particular

EspecificaciónComplementaria

Administración

del Proyecto

Restricciones

Características: Iterativo e Incremental El ámbito de cada iteración está

basado en: Los principales riesgos del proyecto. La funcionalidad requerida por el sistema. El tiempo asignado a la iteración en el

plan del proyecto. La fase y sus objetivos específicos.

Planificación de Iteraciones

El alcance de la iteración se expresa en términos de: Casos de uso elegidos. Requerimientos no funcionales elegidos.

Cada Iteración consiste de una mini-cascada

Iteración 3 Iteración 4 Iteración 5

Chequeo depreparación parala iteración

Evaluación dela Iteración

Plan de Iteración

Requerimientos

Análisis & Diseño

Implantación

Prueba

Prepara Versión

Ciclos de desarrollo

Un ciclo de desarrollo incluye una ejecución completa de las cuatro fases y produce una generación de software. La mayoría de los sistemas requiere múltiples ciclos. Un ciclo de desarrollo inicial genera la liberación

inicial. Ciclos posteriores se usan para mantener o mejorar

el sistema. Los ciclos pueden ser secuenciales o traslaparse.

Estrategias de Desarrollo Iterativo

Incremental (1)

C o n c e p t u a l p r o t o t y p e

A r c h i t e c t u r a l b a s e l i n e

R e l e a s eD e l i v e r y

# 1 # 2 # n + 1 # . . # m # m + 1 # m + 2 . . I t e r . N o .

P r e l .I t e r a t i o n

E l a b o -r a t i o n C o n s t r u c t i o n T r a n s i t i o nI n c e p t i o n

Incremental (1)

Estrategias de Desarrollo Iterativo

C o n c e p t u a l p r o t o t y p e

A r c h i t e c t u r a l b a s e l i n e

R e l e a s e

D e l i v e r y

# 1 # 2 # n + 1 # . . # m # m + 1 # m + 2 . . I t e r .N o .

P r e l .I t e r a t i o n

E l a b o r a t i o n

C o n s -t r u c -t i o n T r a n s i t i o nI n c e p t i o n

Evolucionario (2)

Estrategias de Desarrollo Iterativo

Incremental (1)

C o n c e p t u a l p r o t o t y p e

A r c h i t e c t u r a l b a s e l i n e

R e l e a s e

D e l i v e r y

# 1 # 2 # n + 1 # . . # m # m + 1 # m + 2 . . I t e r .N o .

P r e l .I t e r a t i o n

E l a b o -r a t i o n

C o n s -t r u c -t i o n T r a n s i t i o nI n c e p t i o n

Entregas incrementales (3)

Estrategias de desarrollo Iterativo

C o n c e p t u a l p r o t o t y p e

A r c h i t e c t u r a l b a s e l i n e

R e l e a s e

D e l i v e r y

# 1 # 2 # 3 . . I t e r .N o .

E l a b o -r a t i o n C o n s t r u c t i o n T r a n s i t i o nI n c e p t i o n

El gran diseño (4)

Ciclo de Retroalimentación

Costos y PlazosReales Iteración N

• Resultado de Tests• Densidad de

Defectos• Estabilidad

Arquitectura• Otras métricas

Evaluación de Cali-dad de la Iteración N

Plan Proy. revisado• Costo Total• Programac. Gral.• Ambito

Plan Iteración N+1

• Costo• Programación• Contenido

Lista de riesgos revisada

• Compare costos y plazos reales con los del plan de iteración

• Determine si hay trabajo a rehacer

- Asígnelo a futura(s) iteración(es)

• Determine que riesgos han sido reducidos, eliminados o cuales identificados

• Actualice el plan del proyecto

• Prepare plan próxima iteración

- Use lista de riesgos revisada y seleccione Casos de Uso

Evaluación de Iteración N

Plan de Iteración

Definir criterios de evaluación objetivos. Identificar que artefactos concretos y

medibles serán desarrollados o actualizados y las actividades necesarias para lograrlo.

Descomponer las actividades hasta llegar a sub-actividades con una asignación y responsabilidad clara y una duración controlable.

Plan de Iteración

Usar estimaciones para asignar duración y esfuerzo de cada actividad.

Hacer los ajustes necesarios de acuerdo a las restricciones de recursos.

Plan de Iteraciones

¿Cuántas iteraciones deben hacerse en cada proyecto?

¿Cuánto debe durar cada iteración? Depende de un número de consideraciones:

Tamaño del sistema: Mientras mayor el sistema, más larga la duración

Número de personas: Mientras más gente, más larga la duración

Bajo 3 0 1 1 1

Típico 6 1 2 2 1

Alto 9 1 3 3 2

Total I E C T

DesarrolleBusiness

Case

Lider deProyecto

DesarrollePlanProy.

Analice lista de Riesgos

AsignePersonal

EvalueIteración

EjecutePlan de

Iteración

DesarrollePlan de

Iteración

IdentiqueRiesgos

Controlando el ciclo de vida iterativo La evaluación de la iteración provee el

feedback necesario para controlar el proceso

Características: Manejo de Proyectos y Riesgos

Progreso

Estabilidad

Adaptabilidad

Modularidad

Calidad

Madurez

Gastos

Tamaño y Complejidad

Tasa de cambio en el tamaño o complejidad del sistema

Facilidad de cambio

Ambito de cambio

Número de errores

Frecuencia de errores

Costo del proyecto versus presupuesto

Métrica Signif icado

Asignación de Recursos: Duración y Esfuerzo Distribución de esfuerzo para un ciclo de

desarrollo inicial de un proyecto de tamaño medio

5%esf.

20% esfuerzo 65% esfuerzo10%esf.

Recursos

Tiempo

Concep Elaboración Construcción Transición

Manejo de Riesgos

Riesgo - Todo lo que pueda afectar el éxito del proyecto Riesgo Directo - el proyecto tiene un alto

grado de control Riesgo Indirecto - el proyecto tiene poco

o ningún control

Manejo de Riesgos

Atributos de Riesgo: Probabilidad de ocurrencia Impacto en el proyecto (severidad) Indicador de magnitud de Riesgo: Alto,

Significativo, Moderado, Parcial, Bajo

Estrategias frente al Riesgo

Evitar el riesgo - reorganizar el proyecto, de manera que no sea afectado por el riesgo.

Transferir el riesgo - reorganizar el proyecto, de manera que el riesgo sea asumido por otro.

Estrategias frente al Riesgo

Aceptar el Riesgo - vivir con él

Amortiguar el Riesgo - reducir su probabilidad o impacto

Definición de plan de contingencia - que hacer si el riesgo se transforma en un problema real (“Plan B”)

El Riesgo conduce el Ciclo de Vida Iterativo La evaluación del riesgo es un

proceso continuo; los riesgos van cambiando en el tiempo.

Las primeras iteraciones enfrentan los mayores riesgos

Características: Administración y Control de Cambios

Cliente

Yo necesito un nuevo requerimientoy cambios a los casos de uso actuales...

¡El cliente está consciente que hay un cambio al Modelo de Casos de Uso!

Hace el impacto en costo más visible para el cliente

Administración y configuración de Cambios La administración de configuraciones

y cambios de los requerimientos es importante por las mismas razones que la administración de configuraciones de código fuente es importante

Administración y configuración de Cambios Beneficios de administración de

requerimientos bajo CM Previene de cambios no autorizados Conserva las revisiones de los

documentos de los requerimientos Permite recuperar versiones anteriores de

los documentos Previene la actualización simultanea de

documentos

La administración de Cambios es Clave

Inputs de Clientes yUsuarios Finales

Marketing

Nueva Característica

NuevoRequerimiento

Error

Mesa de Ayuda

ProcesoAprobación

(EquipoRevisión

Cambios)

Los requerimientos de cambio vienen de muchas fuentes durante el ciclo de vida del producto

Inputs de programadores y testeadores

CR

Test

Code

Reqs

Vision

CM Artifacts

CRSystem

CRSystem

Mejoras

Desarrolloen equipos

RUP y UML

Lenguaje deModelamiento

ProcesoUnificado

¿Qué es UML?

El lenguaje de modelamiento unificado (UML) está descrito en "The Unified Modeling Language for Object-Oriented Development" escrito por Grady Booch, James Rumbaugh e Ivar Jacobson.

Está basado en las experiencias personales de los autores.

Incorpora contribuciones de otras metodologías.

¿Qué es UML?

UML es el lenguaje “Standard” para visualización, especificación, construcción, y documentación de los elementos de un sistema “software intensivo”

Puede ser utilizado a través de todo el ciclo de vida de desarrollo

¿Qué es UML?

UML combina lo mejor de: Conceptos de modelamiento de

datos. Modelamiento del negocio

(workflow). Modelamiento de objetos. Modelamiento de componentes.

Ventajas del UML

Es un estándar abierto Da soporte a todo el ciclo de vida de

desarrollo del software. Da soporte a diversas áreas de

aplicación. Está soportado por muchas

herramientas.

Creación del UML

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

publicfeedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners

Meyer

Before and after conditions

Harel

StatechartsGamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contribuciones al UML

Workflows y Modelos

Requerimientos

Diseño

Implementación

Prueba

Análisis

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

UML - Sus diagramas proporcionan vistas dentro de cada modelo

Cada Workflow está asociado con uno o más modelos

Modelos, Vistas, y Diagramas

Use CaseDiagramsUse Case

DiagramsDiagramas deCasos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deImplementación

StateDiagramsState

DiagramsDiagramasde Objeto

ScenarioDiagramsScenario

DiagramsDiagramas deTransición de

Estados

Use CaseDiagramsUse Case

DiagramsDiagramasde Secuencia

StateDiagramsState

DiagramsDiagramas deClase

Diagramasde Actividades

Modelos

Modelo de casos de usoUse CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Modelo de análisis y diseñoUse CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Incluye subsistemas y paquetes

Modelo de despliegueUse CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Incluye clases y componentes

Modelo de pruebaUse CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Prueba la sincronización de los modelos

La arquitectura y los modelos

Vistas

Modelos

Use CaseModel

DesignModel

Depl.Model

Impl.Model

TestModel

AnalysisModel

Funciones versus Formas

Casos de uso Arquitectura

• Los casos de uso especifican funciones. La arquitectura especifica la forma.

• Los casos de uso y la arquitectura deben estar balanceados.

Dos partes de un todo unificado

UML RUP

• Convergencia en el futuro

• Convergencia a través de los esquemas de proceso.

• Es un estándar de OMG