Actividad 1 Introducción a UML Dra. Anaisa Hernández González Curso de UML Actividad 1 Introducción a UML Dra. Anaisa Hernández González

Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

Construcción de una casa Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

Construcción de un rascacielos Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, para proyectos de envergadura es difícil eludir un proceso y modelado más rigurosos. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

Problemas de la Industria de Software en la actualidad Tendencia al crecimiento del volumen y complejidad de los productos. 1 Proyectos excesivamente tardes y se exige mayor productividad y calidad en menos tiempo. 2 Insuficiente personal calificado. 3

¿ Por qué fallan los Proyectos de Software? Planificación Irreal 1 Mala Calidad del Trabajo 2 Personal Inapropiado 3 No Controlar los Cambios 4

Planificación Irreal “El sistema es para hoy y con costo 0” 1 Planificación Irreal “El sistema es para hoy y con costo 0” Los ingenieros no son capaces de enfrentar un plan porque: • NO están entrenados para usar métodos de planificación. • Frecuentemente, las estimaciones NO se basan en datos reales.

Mala Calidad del Trabajo 2 Mala Calidad del Trabajo CAUSAS Prácticas pobres de ingeniería Carencia de métricas de calidad Inadecuado entrenamiento en calidad Decisiones de los directivos guiadas por una planificación irreal

Mala Calidad del Trabajo 2 Mala Calidad del Trabajo CONSECUENCIAS Tiempos de pruebas impredecibles Productos con muchos defectos Demoras en la aceptación de los usuarios Extensa garantía de servicio y reparaciones “Una pobre calidad afecta la planificación y torna ineficente el proceso de prueba”

3 Personal Inapropiado Demora del personal Escaso personal Miembros del equipo a tiempo parcial Personal con conocimientos inapropiados PROBLEMAS COMUNES El trabajo se demora o descuida Trabajo ineficiente Sufre la moral del equipo CONSECUENCIAS Con independencia del plan, los proyectos deben comenzar en tiempo y con todo el personal.

Cambios NO controlados 4 Cambios NO controlados HECHOS a RECORDAR: Siempre ocurren cambios en los requerimientos. Los planes del proyecto se basan en el alcance del trabajo conocido. Los cambios siempre requieren más trabajo. Sin planes detallados, los equipos no pueden estimar el efecto o magnitud de los cambios. Si los equipos no controlan cada cambio, se pierde gradualmente el control del plan del proyecto

? Las organizaciones requieren: ¿Cómo enfrentarla? Desarrollar o adquirir una disciplina en el desarrollo del software. 1 2 Controlar que los ingenieros usen de forma consistente los nuevos métodos.

Mejorar el proceso de desarrollo de software Cómo? ¿Qué debe hacer una empresa para obtener software de buena calidad? Mejorar el proceso de desarrollo de software

Cualquier modelo de calidad para mejorar el Proceso de Desarrollo de Software, IMPLICA utilizar los métodos y procedimientos de INGENIERIA Y GESTION DE SOFTWARE

¿Qué es la Ingeniería de Software (IS)? “...la aplicación de un enfoque sistémico, disciplinado y cuantificable hacia el desarrollo, funcionamiento y mantenimiento de software, es decir la aplicación de ingeniería al software” IEEE,1993

IS es una tecnología multicapa METODOS Indican cómo construir técnicamente el Sw. Soporte automático o semiautomático para el proceso y los métodos. HERRAMIENTAS Es el fundamento de la IS. Es la unión que mantiene juntas las capas de la tecnología. PROCESO

Síntomas - Causas Síntomas Causas necesidades usuarios requerimientos cambiantes módulos no calzan poco mantenible tardía detección baja calidad baja performance versiones y cambios liberación y distribución Diagnóstico Causas requerimientos insuficientes comunicación ambigua arquitecturas frágiles complejidad excesiva inconsistencias no detectadas prueba pobre evaluación subjetiva desarrollo en cascada cambios no controlados automatización insuficiente ...tratar los Síntomas no resuelve el problema

Las Mejores Prácticas de la IS atacan las causas Controle Cambios Desarrolle Iterativamente Administre Requerimientos Modele Visualmente Verique Calidad Use arquitectura de componentes

Mejores Prácticas de Software Son propuestas de desarrollo probadas comercialmente, 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.

Mejores Prácticas: Equipos de Alto Rendimiento Resultado Proyectos más exitosos porque están en plazo, en presupuesto y satisfacen las necesidades del usuario Jefe de Proyecto Ing. de Performance Liberación y Distribución Analisis Desarrollador Probador Control Changes Develop Iteratively Use Component Architectures Manage Requirements Model Visually Verify Quality

Enfrentando las Causas se eliminan los Síntomas 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 insuficiente SÍNTOMAS necesidades usuarios requerimientos cambiantes módulos no calzan poco mentenible tardía detección baja calidad baja performance versiones y cambios liberación y distribución MEJORES PRÁCTICAS desarrolle iterativamente adm. requerimientos use arquitectura de componetes modele el software visualmente verifique calidad controle cambios

Mejores Prácticas se refuerzan entre si Asegura participación del usuario mientrás evolucionan requerimientos Administre Requerimientos Use Arquitecturas de Componentes Valida tempranamente las decisiones arquitectónicas Desarrolle Iterativamente Pemite manejar la complejidad de diseñar incrementalmente Modele Visualmente Mide la calidad en forma oportuna y frecuente Verique Calidad Evoluciona la línea base incrementalmente Controle Cambios

Proceso de desarrollo de software Lenguaje Unificado de Modelación Mejores prácticas para el trabajo efectivo de un equipo en el desarrollo del software. Proceso de desarrollo de software (Dirige y organiza el proceso) Lenguaje Unificado de Modelación (Notación)

Sumario Conceptos básicos del modelo de objetos Proceso de desarrollo de software. El Lenguaje Unificado de Modelación (UML) El Proceso Unificado de Desarrollo de Software (RUP)

Lecturas Recomendadas Bibliografía Lecturas Recomendadas BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar; “El Lenguaje Unificado de Modelación. Libro introductorio”.2000. Addison Wesley. RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady; “El Lenguaje Unificado de Modelación. Manual de referencia”.2000. Addison Wesley. JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James, “El Proceso Unificado de Desarrollo de Software”.2000. Addison Wesley. LARMAN, Craig “UML y patrones” 1999, Prentice Hall Iberoamericana.

Lecturas Recomendadas Bibliografía Lecturas Recomendadas BOOCH, Grady, MAKSIMCHUCK, Robert, ENGLEm Michael, YOUNG, Bobbi, CONALLEN, Jim, Houston, Kelli; “Objetct-Oriented Analysis and Design with Applications”. Third Edition. Addison Wesley. 2007. HAMILTON, Kim, MILES, Russell; “Learning UML 2”.2006. O´ Reilly Media CONALLEN, Jim, “Building Web Applications with UML”.2002. 2nd edition. Addison Wesley.

Conceptos básicos del Modelo de Objetos

Enfoque Orientado a Objetos Se basa en conceptos y relaciones entre ellos. Todo Partes Objetos Atributos blanco

Enfoque Orientado a Objetos Tipo de Objeto: Descripción generalizada que describe una colección de objetos similares. Clase: Implementación en software de un tipo de objeto. Tlibro = class private . . . end;

Enfoque orientado a Objetos Método: Implementación en software de la operación. TSemáforo = class ..... Cambiar luz(); end; Cambiar luz

Enfoque Orientado a Objetos Encapsulamiento Empaque conjunto de datos y métodos. Atributos Operaciones

Enfoque Orientado a Objetos Herencia: Propiedad de una clase de heredar el comportamiento de sus ancestros. Polimorfismo: Mecanismo que permite a la subclase implementar la misma operación con un método diferente.

Proceso de Desarrollo de Software

Proceso de desarrollo de software (PDS) CONJUNTO DE ACTIVIDADES Define “quién” está haciendo “qué”, “cuándo” y “cómo” para alcanzar un determinado objetivo. Proceso de desarrollo de software (PDS) CONJUNTO DE ACTIVIDADES Requisitos del usuario Sistema informático

Proceso de desarrollo de software (PDS)

Proceso de desarrollo de software (PDS) Un proceso software debe especificar: la secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividades productos que deben crearse: qué y cuándo asignación de tareas a cada miembro del equipo y al equipo como un todo proporcionar heurísticas criterios para controlar el proceso

UML

Lenguaje de modelación “ Puede ser un seudocódigo, código, imágenes, diagramas, o largos paquetes de descripción; es decir, cualquier cosa que ayude a describir un sistema ” Lenguaje de modelación = + Notación Metamodelo

= + Lenguaje de modelación Lenguaje de modelación Notación Metamodelo (Forma de expresar el modelo) (Descripción de lo que significa esa modelación)

Notación visual Notación visual Manejar la complejidad Interface de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Servidor de BDs (C++ & SQL, ..) Múltiples Sistemas Componentes Reutilizados Modelar el sistema independientemente del lenguaje de implementación Promover la Reutilización

Necesidad de establecer un estándar Situación de partida Situación de partida Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc. Pugna entre distintos enfoques (y correspondientes gurús) Necesidad de establecer un estándar

Lenguaje Unificado de Modelación ? U M L ¿Qué es el UML- Unified Modeling Language? Lenguaje Unificado de Modelación Descrito en "The Unified Modeling Language for Object-Oriented Development" de Grady Booch, James Rumbaugh e Ivar Jacobson. Basado en las experiencias personales de los autores. Incorpora contribuciones de otras metodologías.

Lenguaje Unificado de Modelación ? U M L ¿Qué es el UML- Unified Modeling Language? Lenguaje Unificado de Modelación Ofrece un estándar para describir un “plano” del sistema. Incluye aspectos conceptuales tales como procesos de negocio y funciones del sistema y aspectos concretos como espresiones de lenguajes de programación, esquemas de BD y componentes de software reutilizables.

Visualizar Especificar Construir  UML Documentar

Aprobado como estándar por OMG en UML no es un método El UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos Aprobado como estándar por OMG en noviembre de 1997 El UML es una guía al desarrollador para realizar el análisis y diseño orientado a objetos, es un proceso

Orígenes de UML El esfuerzo de UML partió oficialmente en octubre de 1994, cuando Rumbaugh se unió a Booch en Rational. El “Método Unificado” en su Versión 0.8, se presentó en el OOPSLA’95 El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose

Creación del UML UML 2.0 UML 1.5 UML 1.1 UML 1.0 UML 0.9 OOSE Other methods UML 0.9 Web - June ´96 UML 1.5 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 Version 1.1 public feedback UML 1.0 UML partners Unified Method 0.8 OOPSLA ´95 Booch method OMT

¿Por qué UML 2.0? Las primeras versiones de UML estaban más orientadas hacia la modelación del software y ahora se requiere más la modelación del sistema. Necesidad de compartir modelos entre diferentes herramientas. Nuevas tecnologías: Arquitectura basada en componentes, MDA Las primeras versiones estaban más diseñadas para las personas y no para las máquinas, por lo que hay construcciones que no estaban suficientemente formalizadas.

Rational Software Corporation. (1995) Las Bases de UML Las Bases de UML Las Bases de UML Booch, Rumbaugh Jacobson Rational Software Corporation. (1995) JAMES RUMBAUGH Object Modelling Technique 1991(OMT) Object Oriented Analysis and Design with Applications 1994 GRADY BOOCH IVAR JACOBSON Object Oriented Software Engineering: A Use Case Driven Approach 1992 (OOSE)

Premisas de UML según Booch, Jacobson y Rumbaugh Modelar sistemas, a partir de los conceptos hacia los artefactos ejecutables, utilizando técnicas orientadas a objeto. Enfocarnos en las cuestiones de escala inherentes a sistemas complejos, críticos en su misión. Crear un lenguaje de modelación utilizable tanto por los humanos, como por las máquinas.

Contribuciones a UML Diagrama de Casos de uso OOSE/Jacobson Diagrama de Clases Diagrama de Objetos OOAD/Booch Diagrama de Secuencia Diagrama de Estado OMT/Rumbaugh Diagrama de Componentes Diagrama de Estructura Compuesta Diagrama de Paquetes Otras mejores prácticas Diagrama de Comunicación Diagrama de Actividad Diagrama de Tiempo Diagrama de Despliegue

Ventajas de UML Es un lenguaje formal ya que cada elemento del lenguaje tiene un significado fuerte que ayuda a modelar un aspecto particular del sistema. Es conciso con una notación simple. Es comprensible porque describe todos los aspecto importante del sistema. Es escalable por lo que permite describir proyectos de diferentes tamaños.

Ventajas de UML Contiene las mejores prácticas de la comunidad orientada a objetos de los últimos 15 años. 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.

Limitaciones de UML Carece de un semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva en ocasiones. No se presta con facilidad al diseño de sistemas distribuidos. En estos sistemas son importantes factores como transmisión, serialización, persistencia, etc. No se puede señalar si un objeto es persistente o remoto.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto de software desde cada una de las perspectivas de interés Modelos Diagramas

¿Qué es un producto de software? Un producto de software es el código máquina y los ejecutables de un sistema Un producto de software es el conjunto de artefactos que se necesitan para representarlo en forma comprensible para: Las máquinas. Los trabajadores. Los usuarios. Los interesados. ¿artefactos?

¿Artefactos? Término general aplicable a cualquier tipo de información creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema Ejemplos: Diagramas UML y su texto. Bocetos de interfaz. Planes de prueba.

Modelos y Diagramas Modelos y Diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos

Trazabilidad entre los modelos Modelo de Casos de Uso Modelo de Análisis Modelo de Diseño Secuencia cronológica Trazabilidad entre los modelos Modelo de Prueba Modelo de Implementación Modelo de Despliegue

Diagramas de UML Estructura Dinámica Física Gestión del modelo ¿Dónde aparece? Caso de uso 1.x Actividad Clase Objeto Informalmente 1.x Secuencia Comunicación Antes de Colaboración en 1.x Tiempo 2.0 Estructura interna Componente 1.x, pero cambia su significado en 2.0 Paquete Estado 1.X Despliegue Estructura Dinámica Física Gestión del modelo

Modelos y Diagramas Modelo de Casos de Uso Diagrama de Casos de Uso del Negocio Diagrama de Casos de Uso del Sistema Modelo de Casos de Uso Diagrama de Actividades Diagrama de Secuencia Diagrama de Comunicación Diagrama de Estado Diagrama de Paquetes

Diagramas de UML Casos de Uso y Diagramas de Casos de Uso Casos de uso Diagrama de casos de uso

Diagrama de casos de uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos Cliente Solicitar Préstamo

Diagramas de UML Diagramas de estructura estática Diagrama de clases Diagrama de Objetos

Diagrama de clases Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia La definición de clase incluye definiciones para atributos y operaciones El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones Profesor Departamento 0..1 1..*

Diagramas UML Diagramas del comportamiento Diagramas de Estado Diagramas de Actividad Diagramas de Secuencia Diagrama de Comunicación Diagrama de tiempo Diagrama de Secuencia Diagrama de Comunicación

Diagrama de estado

Diagrama de actividades Buscar bebida ¿hay café? Poner café en filtro Añadir agua al depósito Coger taza Poner filtro en máquina Encender Hacer café Servir café Beber Servir jugo ¿hay jugo? SÍ NO

Diagrama de secuencia : Encargado :WInPréstamos :Socio :Video prestar(video, socio) verificar situación socio verificar situación video registrar préstamo entregar recibo

Diagrama de comunicación

Diagramas de UML Diagramas de implementación Diagramas de componentes Diagramas de instalación/Distribución (Despliegue) Diagrama de componentes

Diagrama de componentes

Diagrama de despliegue

¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.

¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.

¿Cómo se relacionan los diagramas? Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. Solo para comprender la secuencia de pasos

¿Cómo se relacionan los diagramas? ¿Cómo se relacionan los diagramas? Solo para comprender la secuencia de pasos Tomado de: Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.

Resumen UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch

El Proceso Unificado de Desarrollo (Rational Unified Process- RUP)

Rational Unified Process RUP es un proceso para el desarrollo de software orientado a objeto que utiliza UML para describir un sistema Rational Software Corporation, 1998

Evolución de RUP Rational Unified Process 5.0 Pruebas de rendimiento y carga (Performance Awareness) Diseño OO de IU Rational Unified Process 5.0 1998 Ingeniería de Datos (Vigortech) Ingeniería de Negocios Administración de Configuración y Cambios (Pure-Atria) UML 1.2 Rational Objectory Process 4.1 Escuela de Requerimientos (Requisite Inc.) Proceso SQA (SQA Inc.) 1997 UML 1.0 Rational Objectory Process 4.0 1996 OMT Booch UML 0.8 Rational Approach Objectory Process 1995 1987 Ericsson method 1967

Estructura Estática de RUP Fases e Iteraciones Disciplinas del Proceso Actividades, flujo de trabajo Artefactos Modelos, reportes, 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?

Estructura Dinámica Concepción Define el alcance del proyecto y el 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.

Fases-Flujos de trabajo de RUP

Características del ciclo de vida de RUP Dirigido por Casos de Uso. Centrado en la arquitectura. Iterativo e incremental.

Dirigido por Casos de Uso Ciclo de vida de RUP Dirigido por Casos de Uso (Reflejar lo que los futuros usuarios necesitan y desean) Requisitos Análisis Diseño Implementación Prueba Caso de Uso Representa los requerimientos funcionales Guían el proceso de desarrollo porque los modelos que se crean llevan a cabo los casos de uso.

Dirigido por Casos de Uso Realización de Análisis Ciclo de vida de RUP Dirigido por Casos de Uso «trace» «trace» Caso de Uso Realización de Análisis Realización de Diseño «trace» «trace» Pruebas Unitarias X Pruebas Funcionales Caso de Prueba

Dirigido por Casos de Uso Ciclo de vida de RUP Dirigido por Casos de Uso

Centrado en la arquitectura Ciclo de vida de RUP Centrado en la arquitectura En la construcción, vista de: A) Estructura. B) Calefacción. C) Plomería. D) Electricidad. Estáticos Dinámicos Aspectos

Centrado en la arquitectura Ciclo de vida de RUP Centrado en la arquitectura (Visión común del sistema completo en la que desarrolladores y usuarios deben estar de acuerdo ) Describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. Se desarrolla mediante iteraciones comenzando por los CU relevantes desde el punto de vista de la arquitectura.

Centrado en la arquitectura Ciclo de vida de RUP Centrado en la arquitectura UML 2.0 UML 1.x Vista de despliegue Vista de componentes Vista física Vista lógica Vista de Casos de uso Vista estática Vista de diseño Vista de Casos de uso Vista de componentes Vista de despliegue Perfil Vista de estado Vista de Gestión del modelo Vista de actividades

Iterativo e incremental Ciclo de vida de RUP Iterativo e incremental Hito de los objetivos Hito de la arquitectura Hito de la funcionalidad operativa Hito de la versión del producto Dentro de cada fase hay hitos (artefactos a construir) asociados a resultados de cada iteración. La terminación de una iteración produce un nuevo incremento.

Iterativo e incremental Ciclo de vida de RUP Iterativo e incremental Enfoque Cascada Enfoque Iterativo e Incremental

Iterativo e incremental Ciclo de vida de RUP Iterativo e incremental Grado de Finalización de Artefactos

Beneficios de la iteración Reduce el coste del riesgo al coste de un solo incremento. Menos riesgo de no sacar el producto al mercado en fecha. Acelera el ritmo de desarrollo. Las necesidades del usuario y correspondientes requisitos no pueden definirse completamente al principio. Se requieren iteraciones sucesivas.

RUP RUP es un proceso que garantiza la elaboración de todas las fases de un producto de software orientado a objetos. RUP es dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. RUP utiliza el UML. UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos

UML y RUP Desarrollo en equipos Proceso Unificado Lenguaje de Modelamiento