Presentación Adptada

1. INTRODUCCIÓN C@rlos Alfredo Rodríguez Rojas Profesor Universidad Distrital – F.M.R.N. crodriguez@udistrital.edu.co PresentaciónAdptada

2. Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

3. Construcción de una casa Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

4. Construcción de un rascacielos

5. Claves en Desarrollo de SI Notación Herramientas Proceso

6. Orden Item envío Proceso de Negocios Abstracción - Modelado Visual (MV) “El modelado captura las partes esenciales del sistema” Sistema Computacional

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

8. Historia de UML • Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. 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

9. Historia de UML UML2.0 2005? 2003 UML 1.5 2000 UML 1.4 1999 Revisiones menores UML 1.3 1998 UML 1.2 UML aprobado por el OMG Nov ‘97

10. MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys Participantes en UML 1.0 • Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) • Digital Equipment • Hewlett-Packard • i-Logix (David Harel) • IBM • ICON Computing (Desmond D’Souza) • Intellicorp and James Martin & co. (James Odell)

11. UML “aglutina” enfoques OO Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditions Shlaer-Mellor UML Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Responsabilities Fusion Operation descriptions, message numbering

12. Aspectos Novedosos • Definición semi-formal del Metamodelo de UML • Mecanismos de Extensión en UML: • Stereotypes • Constraints • Tagged Values Permiten adaptar los elementos de modelado, asignándoles una semántica particular

13. Inconvenientes en UML • Definición del proceso de desarrollo usando UML. UML no es una metodología • No cubre todas las necesidades de especificación de un proyecto software. Por ejemplo, no define los documentos textuales • Ejemplos aislados • “Monopolio de conceptos, técnicas y métodos en torno a UML y el OMG”

14. Perspectivas de UML • UML es el lenguaje de modelado orientado a objetos estándar predominante ahora y en los próximos años • Razones: • Participación de metodólogos influyentes • Participación de importantes empresas • Estándar del OMG • Evidencias: • Herramientas que proveen la notación UML • “Edición” de libros (más de 300 en www.amazon.com) • Congresos, cursos, “camisetas”, etc.

15. UML: “Unificado” • Cruza los métodos y notaciones anteriores • Cruza los ciclos de desarrollo • Cruza los dominios de aplicación • Cruza las plataformas y lenguajes de implantación • Cruza los procesos de desarrollo • Cruza los conceptos internos

16. UML Unified Modeling Language • Lenguaje de Modelado Visual de Propósito general • Usos: • Especificar, visualizar, construir y documentar artefactos de un sistema software. • Se diseñó de manera de independizarlo del método de desarrollo, y se intenta que sea aplicable a todas las etapas del ciclo de vida del software

17. UML para visualizar • Símbolos con semántica bien definida. • UML transciende al lenguaje de programación. • Modelo explícito, que facilita la comunicación.

18. UML para especificar • Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. • UML cubre la especificación del análisis, diseño e implementación de un sistema software.

19. Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.). UML para construir IngenieríaDirecta ModeloUML CÓDIGO Ingeniería Inversa

20. UML para documentar • UML cubre la documentación de un sistema: • Requisitos • Arquitectura • Diseño • Código fuente • Planificación • Pruebas • Prototipos • Versiones

21. Vista Diagramas Conceptos Principales Vista Estática Diagrama de Clases Clase, Asociación, Generalización Dependencia, Realización, Interfase Vista de Casos de Uso Diagrama de Casos de Uso Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso Vista de Implementación Vista del despliegue (deployment) Diagrama de Componentes Componente, Interfaz, Dependencia, Realización Diagrama de Despliegue Nodo, Componente, Dependencia, Locación UML Estático

22. Diagrama de Clases

23. Diagrama de Casos de Uso

24. Diagrama de Componentes

25. Diagrama de Despliegue

26. Vista Diagramas Conceptos Principales Vista de Máquina de Estados Diagrama de Estados (statechart) Estado, Evento, Transición, Acción Vista de actividades Diagrama de Actividades Estado, Actividad, Transición de compleción, Juntura (join), Bifurcación (fork) Vista de Interacción Diagrama de Secuencia Interacción, Objeto, Mensaje, Activación Diagrama de Colaboración Colaboración, Interacción, Rol de colaboración, Mensaje UML Dinámico

27. Diagrama de Estados

28. Diagrama de Actividades

29. Diagrama de Secuencia

30. Diagrama de Colaboración

31. Vista Vista Diagramas Diagramas Conceptos Principales Conceptos Principales Vista de la gestión del modelo Todas Todos Diagrama de Clases Restricción, Estereotipo, Valores tagged (etiquetados) Paquete, Subsistema, Modelo UMLGestión del Modelo Extensibilidad

32. Vista de la Gestión del Modelo

33. Extensibilidad

34. Diagrama de Casos de Uso • Modela la funcionalidad de un sistema percibido desde el usuario externo (actor). • Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema. • Pueden describirse en varios niveles de detalle. • Un caso de uso se implementa como una colaboración en la vista de interacción.

35. Diagrama de Casos de Uso: Elementos Actor: • rol que juega un usuario con respecto al sistema. • un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. • Caso de Uso: • Operación o tarea específica que se realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso

36. Diagrama de Casos de Uso: Relaciones Asociación: • Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). • Dependencia o Instanciación: • Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).

37. Diagrama de casos de Uso: Relaciones de Generalización • Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). • Se diferencian por el estereotipo <<uses>> (uso) o (<<extends>>) (herencia). • extends: Se recomienda utilizar cuando un caso de uso es similar a otro (en sus características). • uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

38. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Inclusión: una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> reemplazó al denominado <<uses>>

39. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Ejemplo <<include>>:

40. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Extensión: el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

41. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Ejemplo <<extend>>:

42. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Ejemplo <<include>> y <<extend>>:

43. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Otro ejemplo <<include>> y <<extend>>:

44. III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones • Herencia: el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

45. III. El Paradigma OO: Requisitos

46. Diagrama de Casos de Uso: EjemploMáquina Recicladora El sistema debe : • Registrar el número de ítemes ingresados. • Imprimir un recibo cuando el usuario lo solicita, que incluye (a) una descripción de lo depositado, (b) el valor de cada item y (c) el total • El usuario/cliente presiona el botón de comienzo • Existe un operador que desea saber lo siguiente: (a) Cuántos ítemes han sido retornados en el día y (b) al final de cada día, un resumen de todo lo depositado. • El operador debe además poder cambiar información asociada a ítemes y dar una alarma en el caso de que (a) un item se atore o (b) no hay más papel.

47. Máquina Recicladora: Identificación de Actores

48. Máquina Recicladora: Diagrama Completo

49. Ejemplo CU Admisnistrador

50. Ejemplo CU Reserva