INTRODUCCIÓN Alfredo Rodríguez Rojas

Presentación del tema: "INTRODUCCIÓN Alfredo Rodríguez Rojas"— Transcripción de la presentación:

1 INTRODUCCIÓN C@rlos Alfredo Rodríguez Rojas
Profesor Universidad Distrital – F.M.R.N. Presentación Adptada

2 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).

3 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

4 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, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. 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."

5 Claves en Desarrollo de SI
Notación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas Proceso

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

7 II. Notación (Visual) - Beneficios
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 “... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias” C:A.R. Hoare, Turing Award Lecture 1980. “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 UML 2.0 2005? 2003 UML 1.5 2000 UML 1.4 1999 UML 1.3
Revisiones menores 1998 UML 1.2 Nov ‘97 UML aprobado por el OMG

10 Participantes en UML 1.0 Rational Software MCI Systemhouse Microsoft
(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) MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys

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 Fusion Responsabilities 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 Stereotype = Estereotipo Constraint = Restricción de Integridad Tagged Values = Valores Etiquetados, es un par (nombre propiedad, valor) Los mecanismos de extensión pueden usarse para: Añadir nuevos elementos de modelado sin crear nuevos símbolos. En este caso el símbolo existente estará etiquetado con el correspondiente estereotipo. Esto permite que el metamodelo de UML no se vea alterado. Definir extensiones necesarias en un proceso de desarrollo o lenguaje de implementación específico. Asignar una semántica particular o información no semántica a elementos de modelado. Las restricciones de integridad pueden escribirse usando un lenguaje específico para representar restricciones (tal como OCL, Object Constraint Language, que expresa restricciones mediante fórmulas bien formadas, desarrollado por IBM) u otros lenguajes (por ejemplo, un determinado lenguaje de programación) o incluso en lenguaje natural. Tipos de enfoques: no-formales, semi-formales y formales Las principales mejoras al utilizar métodos formales son: Mayor rigor en la especificación Mejores condiciones para realizar la verificación y validación Mejores condiciones para automatización de procesos para la generación automática de prototipos y/o código final

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 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 En el año 1994 había más de 50 notaciones, se toma lo mejor de cada una y se tiende a un estándar. Las notaciones se mantienen (en principio) a través del ciclo del desarrollo (aunque debe variar el nivel de abstracción) Se persigue poder cubrir todos los dominios de aplicación incluidos aquellos sistemas grandes, complejos, tiempo real, distribuidos, intensivos en datos o computación, entre otros. Puede haber areas especializadas con lenguajes más adecuados, pero Uml pretende cubrir un rango muy amplio. UML es un lenguaje, no una metodología de desarrollo. Se definen las interrelaciones entre los constructores de UML. Esto conlleva a un mejor entendimiento de los conceptos y una mejor aplicabilidad de los mismos.

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 UML para construir Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.). Ingeniería Directa 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 UML Estático 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

22 Diagrama de Clases

23 Diagrama de Casos de Uso

24 Diagrama de Componentes

25 Diagrama de Despliegue

26 UML Dinámico 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

27 Diagrama de Estados

28 Diagrama de Actividades

29 Diagrama de Secuencia

30 Diagrama de Colaboración

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

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
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. 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).

38 … Casos de Uso: Relaciones
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>> Para la explicación de las relaciones entre casos de uso se han identificado como “caso de uso origen” y “caso de uso destino” sólo para indicar el sentido del símbolo (flecha de generalización).

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

40 … Casos de Uso: Relaciones
III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino Las relaciones <<include>> y <<extend>> corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interacción de otro caso de uso. Sin embargo, la intensión es diferente; la relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.

41 … Casos de Uso: Relaciones
III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones Ejemplo <<extend>>: En UML 1.3 se disponen de tres tipos de relaciones entre casos de uso, representadas por un símbolo de generalización desde un caso de uso a otro. Los tipos de relación son: Inclusión (con el estereotipo <<include>>), Extensión (con el estereotipo <<extend>>) y Generalización (sin estereotipo). En UML 1.3 se utiliza el estereotipo <<include>> en lugar de <<uses>>.

42 … Casos de Uso: Relaciones
III. El Paradigma OO: Requisitos … Casos de Uso: Relaciones Ejemplo <<include>> y <<extend>>: ¿Podría en este ejemplo haberse modelado el caso de uso “Transferencia por Internet” con una relación de generalización hacia el caso de uso “Transferencia”?. Si la idea de extensión (vista como especialización) forma parte esencial del concepto de generalización/especialización, ¿para qué tener dos tipos de relaciones? ... estos son algunos de lo muchos aspectos de UML que quedan a la interpretación del lector.

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

44 … Casos de Uso: Relaciones
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 En el documento UML no se proporcionan reglas específicas respecto de las modificaciones y ampliaciones posibles en el caso de uso hijo. Lo intuitivo es pensar que un caso de uso obtenido por especialización tiene en principio los mismos pasos de interacción que el caso de uso padre pero que puede insertar nuevos y/o reescribir los pasos heredados.

45 III. El Paradigma OO: Requisitos
Identificador CU-<id-requisito> Nombre <nombre del requisito funcional> Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>} Precondición <precondición del caso de uso> Secuencia Normal Paso Acción 1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso CU-x> 2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x> … Postcondición <postcondición del caso de uso> Excepciones Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x>, a continuación este caso de uso {continua, aborta} Rendimiento Cota de tiempo n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales> Esta es una posible plantilla para utilizar al especificar un caso de uso (adaptada desde )

46 Diagrama de Casos de Uso: Ejemplo Má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

51 Ejemplo CU Trámite

52 Ejemplo CU Reserva

53 Diagrama de Clases Modela los conceptos del dominio de la aplicación.
Permite visualizar las relaciones entre las clases que involucran el sistema Un diagrama de clases está compuesto por los siguientes elementos: Clases: atributos, operaciones y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Responsabilidades

54 Diagrama de Clases: Elementos Clase
Es la unidad básica que encapsula toda la información de un Tipo de Objeto (un objeto es una instancia de una clase).

55 Diagrama de Clases: Elementos Atributo
Los atributos describen a una clase. Pueden ser Públicos, Privados o Protegidos. public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia)

56 Diagrama de Clases: Elementos Operaciones (métodos)
private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la misma clase lo pueden acceder). protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia) Las operaciones o métodos de una clase describen la forma en la cual ésta interactúa con su entorno. Pueden ser Públicas, Privadas o Protegidas. public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

57 Diagrama de Clases: Elementos Relaciones entre Clases
Las clases interrelacionadas modelan un sistema en su dimensión estática. Existen tres tipos de relaciones básicas: Dependencia Generalización Asociación

58 Relaciones entre Clases: Dependencia (instanciación o uso)
Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana) La interpretación más frecuente es la de uso: una clase usa a otra como argumento de una operación. El objeto creado no se almacena en el objeto que lo crea.

59 Relaciones entre Clases: Generalización
Relaciona una abstracción general (superclase) con una más concreta del mismo tipo (subclase) Una clase puede tener cero, una (herencia simple) o más superclases (herencia múltiple) Una clase sin superclases es una clase raíz Una clase sin subclases es una clase hoja

60 Relaciones entre Clases: Generalización - Polimorfismo
Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones. Un objeto de una subclase puede sustituir a un objeto de la superclase en cualquier contexto. Lo inverso no es cierto Una operación de la subclase con igual signatura que una operación de la superclase la anula y sustituye. El polimorfismo es muy útil en la programación.

61 Relaciones entre Clases: Generalización

62 Relaciones entre clases: Asociación
Relación estructural entre las clases. En general es simétrica Tiene un nombre, que la describe (verbo, con dirección de lectura) Puede tener un rol que describe el papel específico que una clase juega en una asociación. Tiene multiplicidad, que especifica por cada clase el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación: 1 : uno 0..1 : cero o uno 3 : tres *: muchos 1..*: al menos uno 2,6,7: dos, seis o siete 2-4, : de dos a cuatro y de diez a doce

63 Relaciones entre clases: Asociación

64 Relaciones entre Clases Agregación y Composición
Relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. El objeto base utiliza al incluido para su funcionamiento, como un parámetro pasado “por referencia”. Composición Relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. El Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo“, como un parámetro pasado “por valor”.

65 Relaciones entre Clases: Agregación y Composición
(Por referencia) Composición (Por valor)

66 Diagrama de Clases: Elementos Responsabilidades
La distribución de responsabilidades en un sistema, se realiza identificando un conjunto de clases que colaboran entre sí para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase

67 Diagrama de Clases

68 Bibliografía y Referencias: Fundamental
James Rumbaugh, Ivar Jacobson, Grady Booch, “The Unified Modeling Language Reference Manual”, Addison Wesley, 1999 Craig Larman, “UML y Patrones”, Prentice Hall, 1999 OMG

69 Bibliografía y Referencias Complementaria
Rational Robert Muller, “Database Design For Smarties: Using UML for Data Modeling”, Morgan Kaufmann, 1999 Luis Guerrero, “Taller de UML”, DCC, Universidad de Chile, 2002, Patricio Salinas, “Tutorial de UML”, DCC, Universidad de Chile, 2000,

70 GRACIAS POR SU ATENCIÓN

71 PREGUNTAS