4. Definición : El U M L es un lenguaje gráfico para la especificación, visualización, construcción y documentación de modelos orientados a objetos que representan sistemas intensivos en software. = U nified M odeling L anguage U M L no es un método sino un lenguaje de modelamiento El Lenguaje Unificado de Modelado
5.
6. U M L toma lo mejor de varios métodos Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Embly Gamma et. al. Shlaer-Mellor Odell Booch Pre y Post condiciones Máquinas de estado Responsabilidades Descripción de operaciones, numeración de mensajes Singleton clases Marcos de trabajo, patrones, notas Ciclo de vida de objetos Clasificación
7. - Proporciona a los desarrolladores un lenguaje de modelamiento ampliamente aceptado y listo para usar. - Integra las mejores prácticas del desarrollo de software. - Permite el intercambio de modelos entre las diferentes herramientas de software. - Es independiente del lenguaje de programación y de métodos y procesos particulares de desarrollo de software. - Proporciona sus propios mecanismos de extensión - Agrupa los conceptos de orientación a objetos definiendo su significado. Características del U M L
8.
9. - Los lenguajes de modelado orientados al objeto comenzaron a aparecer a mediados de la década de '70. - El número de lenguajes que modelaban objetos aumentó de menos de 10 a más de 50 durante el período entre 1989-1994. Breve historia del U M L - Muchos de los que utilizaban estos lenguajes no encontraban satisfacción completa en ninguno de ellos, esto motivó la llamada "Guerra de los Métodos" .
10. . . . La “Guerra de los Métodos” Exist í an muchos métodos y cada uno tenía un lenguaje de modelado propio. Esto dificultó el aprendizaje, aplicación, construcción, uso de herramientas, etc. Pugna entre los distintos gur ú s que defend í an sus propios métodos y simbologías. Se observa la necesidad de una notación estándar. . . . Breve historia del U M L
11. El desarrollo del U M L comenzó en finales de 1994 en que Grady Booch y Jim Rumbaugh de Rational Software Corporation, comenzaron su trabajo sobre la unificación de los métodos de Booch y de OMT (Object Modeling Technique). A finales de 1995, Ivar Jacobson y su compañía de Objectory se unieron a Rational y combinaron sus métodos. Booch, Rumbaugh, y Jacobson, definieron el U M L 0,9 y 0,91 en junio y octubre de 1996. . . . Breve historia del U M L
12. . . . Breve historia del U M L Sep ‘97 U M L 1.1 Ene ‘97 U M L 1.0 Jun ‘96 U M L 0.9 Oct ‘95 Método Unificado 0.8 Microsoft Oracle IBM, HP Etc. Ivar Jacobson se une a Rational en otoño ‘95 James Rumbaugh se une a Rational en Oct ‘94 OMT Booch Use Case (OOSE) Otros métodos
13. 1997 (Adoptada por OMG) 1998 (revisión editorial sin cambios significativos) 1999 (revisión menor p ú blicamente disponible) 2000 (planificada una revisión menor) 2001 (planificada una revisión menor) 2002 (planificada una revisión mayor) Versiones del U M L <<document>> U M L 1.1 <<document>> U M L 1.2 <<document>> U M L 1.5 <<document>> U M L 1.3 <<document>> U M L 2.0 <<document>> U M L 1.4 <<document>> ISO Publica especificación
14. Vistas de un modelo “ Un modelo es una descripción completa de un sistema desde una perspectiva concreta” Vista lógica Vista de proceso s Vista de despliegue Vista de implementación Vista de requerimientos Diagrama de Clases Diagrama de Objetos Diagrama de Estado Diagrama de Secuencia Diagrama de Colaboración Diagrama de Actividad Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue
15. Modelando con U M L Use Case Diagrams Use Case Diagrams Diagramas de Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Despliegue State Diagrams State Diagrams Diagramas de Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo
16.
17.
18.
19.
20.
21.
22. Análisis y Diseño Orientado a Objeto s OOD Agregar detalles y decisiones de diseño Perspectiva del Desarrollador OOA Modelo de desarrollo de requerimientos Perspectiva del Usuario
33. Reducción de Riesgo a través de Iteraciones Riesgo inicial Campo de acción inicial del proyecto Definir la iteración para consignar el mayor riesgo Planificar y desarrollar la iteración Estimar la iteración Eliminación del riesgo Revisión de la Evaluación de riesgo Revisión del plan del proyecto Iteración N
37. Requisitos Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso Proceso dirigido por los Casos de Uso Análisis & Diseño Implement ación Prueba s Casos de Uso integran el trabajo
38.
39.
40.
41.
42.
Hinweis der Redaktion
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia Durante 1996, los autores del U M L invitaron a la comunidad de desarrolladores a realizar sus aportes. Mientras tanto, la industria del software quería definir un lenguaje de modelamiento estándar. En junio de 1995, el OMG reunió a todos metodologistas importantes dando lugar al primer acuerdo mundial de buscar estándares de la metodología, bajo la batuta del OMG . Durante 1996, varias organizaciones consideraron U M L como estratégico a su negocio. Racional estableció el consorcio de los socios de U M L para una definición de U M L 1,0 . Entre ellos: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, y Unisys. Esta versión se sometió al OMG para su aceptación como nuevo estándar en enero de 1997 y se unieron ObjecTime de IBM, Platinium Technology, Ptech, Taskon, Reich Technology y Softeam quienes produjeron la versión 1,1 del U M L la cual fue adoptada como estándar a fines de 1997.
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia VISTA DE REQUERIMIENTOS Es el enlace de las otras vistas Describe aspectos de comportamiento no de construccion Muestra la funcionalidad del sistema como es percibida por los actores externos Utiliza los diagramas de casos de uso y diagramas de actividad VISTA LOGICA Muestra el diseño de la funcionalidad Muestra la estructura (elementos que lo integran) mediante diagramas de clases y objetos Muestra la interaccion de los elementos mediante diagramas de Estado, Secuencia, Colaboracion y Actividad VISTA DE COMPONENTES O IMPLEMENTACION La vista logica era solo una abstraccion La vista de componentes muestran los archivos (ejecutables, fuentes, librerias)en los que se traducen los elementos logicos Muestra la dependencia entre estos elementos Consiste en diagramas de componentes VISTA DE DESPLIEGUE O IMPLANTACION Muestra como el software se despliega en el hardware Indica donde se ubica el software y como se comunican entre si Consiste en diagramas de despliegue VISTA DE PROCESOS O DE CONCURRENCIA combinacion de vista logica, componentes e implantacion Muestra el manejo de la concurrencia de los procesos (comunicacion y sincronizacion, hilos de control, procesos paralelos) Es importante para sistemas distribuidos y de tiempo real Consiste en diagramas de componentes y despliegue, y diagramas de estado, secuencia, colaboracion y actividad.
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia Algo más ... W. Gibbs, &quot;Software's Chronic Crisis&quot;, cientifico americano, Sept. 1994, pp. 86-95: &quot;[...] a pesar de 50 años de progreso, la industria del software permanece años - tal vez décadas - atrasada con respecto a las disciplinas de ingeniería necesarias para cumplir las demandas de una sociedad en la edad de la información.” http://www.standishgroup.com/chaos.html : “ Las invstigaciones del grupo Standish muestran que 31.1% de los proyectos se cancelarán antes de que se completen. Otros resultados indican que 52.7% de los proyectos costarán 189% de la estimación original. El costo de estas fallas y excesos son sólo la punta del iceberg. Los costos de oportunidades perdidas son inconmensurables, pero podrían llegar a los trillones de dólares. Basta mirar a la ciudad de Denver para darse cuenta del alcanc de este problema. El fracaso en la producción de software confiable para manejar equpaje en el nuevo aeropuerto le está costando a la cuidad US$1.1 millones al día. Basado en esta investigación, The Standish Group estiman que en 1995 compañías y agencias de gobierno de EE.UU. gastarán US$81 billones en proyectos de software cancelados. Y otros US$59 billones en proyectos de software completados, pero que excederán las estimaciones iniciales .&quot;
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia El análisis orientado a objetos es un método de análisis en el cual los requerimientos son expresados en términos de los objetos encontrados en el problema. El análisis se focaliza en el QUE del problema. El diseño orientado a objetos involucra la trasnformación del modelo de análisis en un modelo de diseño refinándolo, agregando detalles y capturando las decisiones de diseño. El diseño agrega el COMO .
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia El proceso que describiremos es genérico: es acomodable a una amplia variedad de dominios de programas y proyectos de distintos tamaños .
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia La fase de comienzo establece la viabilidad de un producto nuevo al punto que los recursos son consignados al proyecto y un plan de proyecto es puesto en su lugar.
Ing. Oscar Ascón Valdivia Aquí el dominio del problema significa el sistema a construir. La elaboración es donde la mayoria de las actividades de análisis son realizadas. El propósito del analisis es entender el problema y el problema debe ser bien entendido antes de entrar en la fase de construcción. La elaboración no puede ser considerada terminada hasta que la fundación de una arquitectura apropiada haya sido establecida de una manera integrada, y haya sido ejecutada exitosamente para probar que lo es para el problema que se tiene entre manos. Note que al comienzo de esta fase, varias exploraciones, folletos del prototipo pueden ser generados para intentar con distintos enfoques a arquitecturas distintas o bien buscando mitigar riesgos específicos. Sin embargo, la elaboarción no estará terminada hasta que la arquitectura haya sido construida, probada, integrada y puesta como linea de base.
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia Durante la elaboración, establecemos el “esqueleto” del sistema. Durante la construcción le ponemos la carne a los huesos.
Ing. Oscar Ascón Valdivia Esta fase puede ser muy simple o muy compleja dependiendo de lo que involucre el producto específico. El nuevo desarrollo de un producto ya existente puede ser muy sencillo. Reemplazar completamente un sistema de rastreo de misiles puede ser muy complejo.
Ing. Oscar Ascón Valdivia La documentación de una iteración prematura significa documentar parte del código -- probablemente no el manual del usuario. Durante las últimas iteraciones la documentación es aplicada hacia el código. La documentación para el usuario también es iterativa -- Ud. no puede hacerla cuando el código ya esta terminado!
Ing. Oscar Ascón Valdivia El riesgo es impredecible; así no todo el riesgo (encontrado) de una iteración es eliminado o reducido. También, pueden aparecer riegos nuevos . Por lo tanto es importante poner al día el plan después de cada iteración.
Ing. Oscar Ascón Valdivia
Ing. Oscar Ascón Valdivia Actividades de análisis y diseño ocurren durante las diferentes fases del ciclo de desarrollo. Aquí el diseño es arquitectura y algunos diseños (nivel bajo) ocurren durante la implementación. Los nombres escogidos para cada fase no provienen de las clásicas actividades de desarrollo tales como análisis y diseño. Los nombres fueron escogidos deliberadamente con el fin de dar énfasis a que estas actividades tienen lugar en grados variados en cada fase e iteración. La figura superior ilustra cómo el énfasis relativo cambia de fase en fase. Note también que el comienzo y fin de las actividades no se igualan a los límites de las fases. El planeamiento tiene lugar en todas las fases. El análisis tiene lugar primeramente en la elaboración de una fase, aunque algún análisis de dominio preliminar pueda ser realizado durante el inicio. El grueso del trabajo de arquitectura es realizado en la fase de elaboración. La implementación incluye pruebas de unidad y ocurre principalmente en las fases de elaboración (elementos arquitectónicos) y construcción. Las actividades de mantenimiento cambian componentes de software después de habes sidos demarcados, i.e., están bajo control de manejo del cambio. De esta manera el mantenimiento comienza de acuerdo a lo establecido en la primera linea base que normalmente ocurre durante la elaboración. Probar y evaluar las actividades demuestra que la linea base del programa se topa con los criterios de evaluación que estan evolucionando y son implementaciones aceptables de la visión del proyecto. El entorno y el manejo de cambio incluyen la integración del entorno de desarrollo y la administración del sistema de manejo de cambio.
El proceso propuesto tiene mucho en común con el modelo de proceso propuesto por Barry Bohem en 1988: “El modelo espiral”. Los cuadrantes de la espiral son: Determinar objetivos, alternativas y restricciones Evaluar alternativas, identificar y resolver riesgos, construir proptotipos Desarrollo y verificación del producto Planificación de las siguientes fases