Your SlideShare is downloading. ×
Desarrollo de software orientado a objetos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Desarrollo de software orientado a objetos

1,625

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,625
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
58
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Desarrollo de software orientado a objetos Unidad 1: El proceso unificado de software RUP
  • 2. Agenda     Introducción. La Estructura del Proceso Unificado Características del RUP RUP y UML
  • 3. Introducción
  • 4. ¿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. Requerimientos Proceso de ingeniería de software Software
  • 5. Características Marco común de trabajo del proceso Actividades del marco del trabajo Conjunto de tareas Tareas Hitos, Entregas Puntos SQA Actividades de protección y administración E
  • 6. 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.
  • 7. 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  ....
  • 8. 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.    
  • 9. Sin embargo….tratar los síntomas no resuelve el problema Síntomas • necesidades usuarios • requerimientos cambiantes Causas • requerimientos insuficientes • comunicación ambigua • módulos no calzan • arquitecturas frágiles • poco mentenible • complejidad excesiva • tardía detección • inconsistencias no detectadas • baja calidad • baja performance • versiones y cambios • liberación y distribución Diagnóstico • testing pobre • evaluación subjetiva • desarrollo en cascada • cambios no controlados • automatización insuficiente
  • 10. 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.  …
  • 11. 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.
  • 12. Las mejores prácticas enfrentan las causas Mejores Prácticas Causas       Desarrolle iterativamente. Administre requerimientos. Use arquitectura de componentes. Modele el software visualmente. Verifique calidad. Controle los cambios. ......Enfrentando las Causas se eliminan los Síntomas E
  • 13. 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.
  • 14. Las mejores prácticas se refuerzan entre si Asegura participación del usuario mientrás evolucionan requerimientos Valida tempranamente las decisiones arquitectónicas Desarrolle Iterativamente Permite manejar la complejidad de diseñar incrementalmente Mide la calidad en forma oportuna y frecuente Evoluciona la línea base incrementalmente Administre Requerimientos Use Arquitectura de Componentes Modele Visualmente Verifique Calidad Controle Cambios
  • 15. ¿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.
  • 16. ¿Que es el RUP?  Provee: Lineamientos, templates para herramientas, que guían una implementación efectiva de las 6 Mejores Practicas.  Se define como una “Base de Conocimiento”  Soportada en la Web.  Con búsquedas e hiper-vínculos.
  • 17. Estructura del proceso unificado
  • 18. Estructura del Proceso Unificado E Fases Disciplinas del Proceso ConcepciónElaboración Construcción Transición Modelo del negocio Requerimientos Análisis y diseño Implementación - Codificación Prueba - Test Despliegue Disciplinas de Soporte Adm. configuración y cambios Adm. del proyecto – Gestión del Proy. ambiente Iteracion(es) Preliminar(es) Iter. #1 Iter. #2 Iter. Iter. Iter. #n #n+1 #n+2 Iter. Iter. #m #m+1 Iteraciones - Tiempo
  • 19. 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
  • 20. Estructura dinámica Concepción Elaboración Construcción Transición Tiempo Concepción Define el alcance del proyecto y el desarrollo de los casos del negocio. Elaboración Planifica el proyecto, especifica las características y define los cimientos de la arquitectura. Construcción Construye el producto. Transición Implementa el producto a sus usuarios.
  • 21. Principales hitos de control Concepción Elaboración Construcción Transición Tiempo Visión Soporte base de la Arquitectura Capacidad Inicial Versión del Producto
  • 22. Ciclo de Vida Concepción Iteración ... Elaboración Iteración ... Construcción Iteración Iteración ... Transición Iteración Release Release Release Release Release Release ... Release Release Una iteración es una secuencia de actividades con un plan establecido y criterios de evaluación, cuyo resultado es una versión o release.
  • 23. Ciclo de Vida-Dos perspectivas
  • 24. Estructura Estática Fases e iteraciones Flujos del Proceso Actividades, pasos Artefactos Modelos, reportes y/o documentos Trabajadores ¿Cuándo ocurre el proceso? ¿Cómo ocurre el proceso y sus detalles? ¿Qué se produce u obtiene? ¿Quién lo hace o se responsabiliza?
  • 25. Estructura Estática Es un rol asumido por un empleado Actividad Es una unidad de trabajo Trabajador Analista Es responsable por Descripción de un caso de Uso Artefacto Caso de Uso Paquete de Caso de Uso Es una pieza de información producida, modificada o usada por un proceso
  • 26. Estructura Estática     Trabajador Actividades Artefactos Workflows - el Quién el Cómo el Qué el Cuándo
  • 27. Trabajador (Worker)  El término Worker define el comportamiento y responsabilidades de un individuo o un grupo de individuos trabajando juntos como equipo. Trabajador Responsable Artefactos Lleva a cabo Actividades
  • 28. 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
  • 29. Actividades  Están fraccionadas en “pasos”. Los pasos se agrupan en:  Pasos pensantes.  Pasos de desarrollo.  Pasos de revisión. Actividad Tiene Pasos Tiene Guías de Trabajo Tiene Tool Mentor
  • 30. Artefacto  Es una pieza de información que es producida, modificada o usada por un proceso. Trabajador Responsable Resultado Artefacto Input + Modelo Tiene Reporte Tiene Guías Tiene Template Actividad
  • 31. 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.
  • 32. Workflows  El RUP organiza el conjunto de actividades usando:  Workflows del proceso  Workflows de iteración  Workflows de detalle
  • 33. 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
  • 34. Workflows del proceso  .......y tres workflows de apoyo:  Configuración y administración de Cambios  Administración del proyecto  Definición del ambiente
  • 35. 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. Fases Disciplinas del Proceso Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Workflow de Iteración Disciplinas de Soporte Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1
  • 36. 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.
  • 37. Modelos y Workflows Cada workflow describe cómo crear y mantener un “modelo” en particular Business Modeling Business Model Requirements Workflow Analysis /Design Workflow Implementation Workflow Test Workflow realized by Use-Case Model implemented by Design Model verified by Implementation Model Test Model
  • 38. Características del RUP
  • 39. 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.
  • 40. 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 Inception Elaboration Construction tiempo Arquitectura Transition
  • 41. “Vista 4+1” modelo de arquitectura Vista Estructural Analistas/ Diseñadores Estructura Usuarios Finales Funcionalidad Vista de Implementación Programadores Administración del Software Vista Casos de Uso Vista de Vista de Proceso Despliegue Integradores de sistemas Rendimiento Escalabilidad agregar o quitar … Operatividad Ingenieros de sistemas Topología Entrega, instalación comunicación
  • 42. El dominio de la arquitectura El “para qué” EL “qué” Cualidades Arquitectura Características del Sistema Satisface Condiciona Requerimientos Representación Produce El “quién” Arquitecto Atributos de calidad del sistema Tecnología El “cómo” Sigue Procesos Técnicas Participantes Define Define roles Organización
  • 43. La Arquitectura y las Iteraciones Modelo de Casos de Uso Modelo Modelo de Modelo de del Implementación despliegue Diseño Contenido Modelo de Prueba
  • 44. 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)
  • 45. Características: Guíado por Casos de Uso Requer. Análisis Diseño Implem. Los casos de uso vinculan a todos los workflows juntos Prueba
  • 46. Manejo de Casos de Uso
  • 47. 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.
  • 48. Artefactos de Requerimientos Requerim. Funcional No Funcional (URPS) Especificaciones Complementarias Casos de Uso
  • 49. 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
  • 50. Actores y ámbito del sistema Sistema Bancario Cliente Sistema Agencias Cajero Bancario ¿Límites del Sistema?
  • 51. ¿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
  • 52. Desde los Casos de Uso hasta los Ejecutables Casos de Uso Clases de Análisis Clases de Diseño Código Fuente Exec
  • 53. 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.
  • 54. Casos de Uso y Documentación Implantación Modelo de Casos de Uso Material soporte usuarios •Manual de Usuario •Help en línea •Demos •Tutoriales •Material entrenamien
  • 55. Casos de Uso y el Modelo de Pruebas Modelo de Casos de Uso Test Modelo de Test Especificaciones Complementarias
  • 56. Modelo de Casos de Uso y otros modelos Modelo de Casos de Uso (requerimientos) realización influencia Modelo de diseño (clases y objetos) Modelo de Implementación (código fuente) verificación Modelo de Test (casos de test y procedimientos de test)
  • 57. Casos de Uso e Iteraciones Restricciones Modelo de Casos de Uso Administración del Proyecto Plan de Iteración Especificación Complementaria Plan detallado para una iteración en particular
  • 58. 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.
  • 59. Planificación de Iteraciones  El alcance de la iteración se expresa en términos de:  Casos de uso elegidos.  Requerimientos no funcionales elegidos.
  • 60. Cada Iteración consiste de una mini-cascada Plan de Iteración Requerimientos Análisis & Diseño Implantación Prueba Prepara Versión Iteración 3 Iteración 4 Chequeo de preparación para la iteración Iteración 5 Evaluación de la Iteración
  • 61. 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.
  • 62. Estrategias de Desarrollo Iterativo Incremental (1) Incremental In c e p t io n P r e l. I t e r a t io n Co (1) E la b o r a tio n #1 nce p tu C o n s tru c tio n #2 A rc h ite #n+1 c tu al p ra l ro t bas o ty e lin pe e # .. #m T r a n s itio n # m + 1 # m + 2 . . It e r. No. Re De le a liv e se ry
  • 63. Estrategias de Desarrollo Iterativo Evolucionario (2) E la b o ra tio n In c e p tio n P r e l. I te r a t io n Co C onstru c tio n #1 nc ep #2 #n+1 # . . #m Ar tu a lp ro t o ty pe ch T r a n s itio n #m +1 Re le a ite se c tu ra l ba se li n e # m + 2 . . Ite r. N o. De li v e ry
  • 64. Estrategias de Desarrollo Iterativo Incremental (1) Entregas incrementales (3) In c e p tio n Constru c tio n E la b o r a tio n P r e l. #1 I t e r a t io n Co nc ep T r a n s itio n #2 Ar tu a lp ch ro t ite o ty #n+1 Re c tu pe ra l le a ba se se li n e # .. #m # m + 1 # m + 2 . . I t e r. N o. De liv e ry
  • 65. Estrategias de desarrollo Iterativo El gran diseño (4) In c e p tio n E la b o ra tio n C o n s tr u c tio n #1 Co Ar ch nc ite ep c tu tu a ra l lp ro t ba o ty se li n pe e T r a n s itio n #2 Re le a se #3 . . Ite r. N o. De li v e ry
  • 66. Ciclo de Retroalimentación Evaluación de Iteración N • Costos y Plazos Reales Iteración N Evaluación de Calidad de la Iteración N • Resultado de Tests • Densidad de Defectos • Estabilidad Arquitectura • Otras métricas • • • • 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 Lista de riesgos revisada Plan Proy. revisado • Costo Total • Programac. Gral. • Ambito Plan Iteración N+1 • Costo • Programación • Contenido
  • 67. 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.
  • 68. 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.
  • 69. Plan de Iteraciones  ¿Cuántas iteraciones deben hacerse en cada proyecto? Total I E C T Bajo 3 0 1 1 1 Típico 6 1 2 2 1 Alto 9 1 3 3 2  ¿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
  • 70. Controlando el ciclo de vida iterativo  La evaluación de la iteración provee el feedback necesario para controlar el proceso Ejecute Plan de Iteración Desarrolle Business Case Identique Riesgos Desarrolle Plan Proy. Lider de Proyecto Desarrolle Plan de Iteración Evalue Iteración Asigne Personal Analice lista de Riesgos
  • 71. Características: Manejo de Proyectos y Riesgos Significado Métrica Progreso  Tamaño y Complejidad Estabilidad  Tasa de cambio en el tamaño o complejidad del sistema Adaptabilidad  Facilidad de cambio Modularidad  Ambito de cambio Calidad  Número de errores Madurez  Frecuencia de errores Gastos  Costo del proyecto versus presupuesto
  • 72. 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 Recursos 5% esf. 20% esfuerzo Concep Elaboración 65% esfuerzo Construcción 10% esf. Transición Tiempo
  • 73. 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
  • 74. Manejo de Riesgos  Atributos de Riesgo:  Probabilidad de ocurrencia  Impacto en el proyecto (severidad)  Indicador de magnitud de Riesgo: Alto, Significativo, Moderado, Parcial, Bajo
  • 75. 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.
  • 76. 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”)
  • 77. 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
  • 78. Características: Administración y Control de Cambios Yo necesito un nuevo requerimiento y cambios a los casos de uso actuales... Cliente  ¡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
  • 79. 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
  • 80. 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
  • 81. La administración de Cambios es Clave Los requerimientos de cambio vienen de muchas fuentes durante el ciclo de vida del producto CM Artifacts Proceso Aprobación (Equipo Revisión Cambios) Nueva Característica Nuevo Requerimiento Error Mejoras Inputs de Clientes y Usuarios Finales Vision Marketing Reqs CR System Code CR System Inputs de programadores y testeadores Test Mesa de Ayuda CR
  • 82. RUP y UML Desarrollo en equipos Lenguaje de Modelamiento Proceso Unificado
  • 83. ¿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.
  • 84. ¿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
  • 85. ¿Qué es UML?  UML combina lo mejor de:  Conceptos de modelamiento de datos.  Modelamiento del negocio (workflow).  Modelamiento de objetos.  Modelamiento de componentes.
  • 86. 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.
  • 87. Creación del UML UML 1.3 OMG Acceptance, Nov 1997 UML 1.1 Final submission to OMG, Sep ‘97 public feedback First submission to OMG, Jan ´97 UML 1.0 UML partners UML 0.9 Web - June ´96 OOPSLA ´95 Other methods Unified Method 0.8 Booch method OMT OOSE
  • 88. Contribuciones al UML Harel Meyer Before and after conditions Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification
  • 89. Workflows y Modelos Requerimientos Análisis Diseño UML - Sus diagramas proporcionan vistas dentro de cada modelo Use Case Model Analysis Model Design Model Depl. Model Impl. Model Implementación Test Model Prueba Cada Workflow está asociado con uno o más modelos
  • 90. Modelos, Vistas, y Diagramas Use Case Use Case Diagrams Diagramas Diagrams de Secuencia Use Case Use Case Diagrams de Diagramas Diagrams Casos de Uso Scenario Scenario Diagrams de Diagramas Diagrams Colaboración Scenario Scenario Diagramas Diagrams de Diagrams Transición de Estados State State Diagrams de Diagramas Diagrams Clase Modelos State State Diagrams Diagramas Diagrams de Objeto State State Diagrams de Diagramas Diagrams Componentes Component Component Diagrams Diagramas Diagrams Diagramas de Actividades de Implementación
  • 91. Modelo de casos de uso Use Case Diagrams Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Object Diagrams
  • 92. Modelo de análisis y diseño Use Case Diagrams Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Incluye subsistemas y paquetes
  • 93. Modelo de despliegue Use Case Diagrams Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Incluye clases y componentes
  • 94. Modelo de prueba Use Case Diagrams Use Case Model Class Diagrams Analysis Model Component Diagrams Design Model Deployment Diagrams Depl. Model Impl. Model Test Model Prueba la sincronización de los modelos Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Object Diagrams
  • 95. La arquitectura y los modelos Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model Modelos Vistas
  • 96. 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.
  • 97. Dos partes de un todo unificado UML • Es un estándar de OMG RUP • Convergencia en el futuro • Convergencia a través de los esquemas de proceso.

×