Post on 06-Jul-2015
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