Uml

12,879 views

Published on

Published in: Education, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,879
On SlideShare
0
From Embeds
0
Number of Embeds
122
Actions
Shares
0
Downloads
414
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces ( links ) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección El Diagrama de Colaboración ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema
  • El Diagrama de Objetos en realidad no se provee como un tipo de diagrama separado. En Diagramas de Secuencia, Diagramas de Colaboración y en Diagramas de Actividad se modelan objetos.
  • Uml

    1. 1. <ul><li>UNIVERSIDAD NACIONAL DE ASUNCIÓN FACULTAD POLITÉNICA </li></ul><ul><li>LICENCIATURA EN CIENCIAS INFORMÁTICAS SECCIÓN C – TURNO TARDE Lic. Claudio N. Barúa A. </li></ul>
    2. 2. Unified Modeling Language (UML) Lenguaje Unificado de Modelado <ul><li>Conceptos </li></ul><ul><li>Básicos </li></ul><ul><li>Teoría y Práctica </li></ul>
    3. 3. Modelado <ul><li>Un empresa que puede desarrollar este software de forma predecible y puntual con un uso eficiente y efectivo de recursos, tanto humanos como materiales, tiene un negocio sostenible*. </li></ul><ul><li>Una empresa de software con éxito es aquella que produce de una manera consistente software de calidad que satisface las necesidades de los usuarios. </li></ul>* El Lenguaje Unificado de Modelado . G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley, 1999
    4. 4. Modelado <ul><li>Un modelo es una simplificación de la realidad. </li></ul><ul><li>Como tal la ingeniería software debe basarse en el modelado como una parte central de toda la actividades que conducen a la producción de software de calidad. </li></ul><ul><li>Podemos definir el proceso software como ``El conjunto de actividades del desarrollo software y las relaciones entre ellas''. Estas actividades varían según la organización y el tipo de sistema, pero en general la gestión del proceso software exige el disponer de un modelo. </li></ul><ul><li>Construimos modelos para comunicar la arquitectura y el comportamiento deseado en nuestro sistema. </li></ul><ul><li>Construimos modelos para visualizar y controlar la arquitectura del sistema y para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificación y reutilización. </li></ul>
    5. 5. Construimos modelos porque: <ul><li>Los modelos nos ayudan a visualizar cómo es o como queremos que sea un sistema. </li></ul><ul><li>Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. </li></ul><ul><li>Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. </li></ul><ul><li>Lo modelos documentan las decisiones que hemos adoptado. </li></ul><ul><li>Construimos modelos de sistemas complejos porque no podemos comprender el sistema en su totalidad. </li></ul><ul><li>En general los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos. </li></ul>
    6. 6. Modelos y Diagramas <ul><li>Un model o captur a una vista de un sistema del mundo real . Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completa-mente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle . </li></ul><ul><li>Diagram a : 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 </li></ul><ul><li>OMG UML 1.4 Specification </li></ul>*Desarrollo de Software Orientado a Objeto usando UML, Patricio Letelier Torres, http://www.dsic.upv.es/~uml/curso.ppt
    7. 7. Diseño funcional y diseño O. O. <ul><li>En la visión tradicional del desarrollo del software (perspectiva algorítmica) el bloque principal de construcción de todo el software es el procedimiento o función. Esta visión conduce a los desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros más pequeños. Este enfoque produce sistemas frágiles y se ha comprobado que a medida que los sistemas crecen y cambian, su mantenimiento resulta muy complejo. </li></ul><ul><li>En la orientación a objetos el bloque de construcción es el objeto o clase. Un objeto es “algo” extraído del vocabulario del problema o del vocabulario de la solución. Todo objeto tiene identidad (puede distinguirse de otros objetos), estado (generalmente hay datos asociados a él) y comportamiento (se le puede hacer “cosas” y el puede hacer “cosas”). </li></ul><ul><li>Tomando un enfoque orientado a objetos vemos el sistema como una colección de objetos, en vez de como una descripción de funciones. </li></ul>
    8. 8. Diseño orientado a objetos <ul><li>Hasta los años 70 la estrategia de diseño software más utilizada se basaba en descomponer el diseño en componentes funcionales con la información del sistema almacenada en un área compartida de datos (diseño funcional). </li></ul><ul><li>Sin embargo David Parnas (1972) sugirió una estrategia alternativa a principios de los 70, el diseño orientado a objetos . </li></ul><ul><li>Su idea era encapsular cada una de las variables globales de la aplicación en un único módulo junto con sus operaciones asociadas, mediante las cuales se podía tener acceso a esas variables.   </li></ul>
    9. 9. <ul><li>El diseño orientado a objetos propone una estrategia de diseño basada en la ocultación de información, que ve el sistema software como un conjunto de objetos que interaccionan entre sí con su propio estado privado, en vez de un conjunto de funciones que comparten un estado global. </li></ul><ul><li>Es ampliamente aceptado que los diseños y desarrollos orientados a objetos son más fáciles de mantener ya que los objetos se pueden entender y modificar como entidades autónomas. Así, el cambiar la implementación de un objeto añadiendo servicios no debería afectar a otros objetos del sistema. Además, con frecuencia existe una correspondencia clara entre las entidades del mundo real y los objetos que las controlan en el sistema, lo que mejora el entendimiento y por tanto el mantenimiento del diseño. </li></ul><ul><li>Los objetos son componentes reusables porque son encapsulaciones independientes del estado y de las operaciones. Basándonos en esto, los diseños se pueden desarrollar utilizando objetos que han sido creados en diseños anteriores, reduciendo costos de diseño, programación y validación. </li></ul>
    10. 10. Historia de UML <ul><li>La notación UML se deriva de y unifica, las tres metodologías de análisis y diseño O.O. más extendidas: </li></ul><ul><li>Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones. </li></ul><ul><li>Técnica de modelado orientada a objetos de James Rumbaugh (OMT: O bject- M odeling T echnique). </li></ul><ul><li>Aproximación de Ivar Jacobson (OOSE: O bject- O riented S oftware E ngineering) mediante la metodología de casos de uso ( use case ). </li></ul><ul><li>El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE. </li></ul><ul><li>De las tres metodologías iniciales, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG (), que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño O.O. </li></ul><ul><li>UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño(cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo). </li></ul>
    11. 11. Historia de UML *Desarrollo de Software Orientado a Objeto usando UML, Patricio Letelier Torres, http://www.dsic.upv.es/~uml/curso.ppt Nov ‘97 UML aprobado por el OMG 1998 1999 2000 UML 1.2 UML 1.3 UML 1.4 2005? UML 2.0 Revisiones menores UML 1.5 2003
    12. 12. ¡ UML ! <ul><li>UML es un lenguaje estándar para escribir planos de software. </li></ul><ul><li>Puede visualizar, especificar, construir y documentar los componentes de un sistemas OO que involucra una gran cantidad de software. </li></ul><ul><li>UML es apropiado para modelar sistemas de información en empresas hasta aplicaciones web. Es un lenguaje muy expresivo , cubre todas las vistas necesarias para desarrollar y desplegar sistemas. </li></ul>
    13. 13. Donde utilizamos UML <ul><li>Está pensado para sistemas con gran cantidad de software: </li></ul><ul><li>Sistemas de información de empresas </li></ul><ul><li>Banco y servicios financieros </li></ul><ul><li>Telecomunicaciones, transporte </li></ul><ul><li>Defensa/industria aeroespacial </li></ul><ul><li>Electrónica médica </li></ul><ul><li>Ámbito científico </li></ul><ul><li>También se pueden modelar workflows en un sistema jurídico, diseño de hardware, etc. </li></ul>
    14. 14. Un modelo conceptual de UML <ul><li>Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje. Esto requiere aprender tres elementos principales: </li></ul><ul><li>Bloques básicos de construcción de UML: </li></ul><ul><li>Reglas que dictan cómo se pueden combinar esos bloques. </li></ul><ul><li>Y algunos mecanismos comunes que se aplican a través de UML. </li></ul>relaciones
    15. 15. Elementos en UML <ul><li>Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados. </li></ul>
    16. 16. Elementos Estructurales <ul><li>Son los nombres de los modelos UML. En su mayoría son las partes estáticas de un modelo, y representan cosas conceptuales o materiales. </li></ul><ul><li>Clase : es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. </li></ul>+toString() : String
    17. 17. Interfaz Representación Gráfica <ul><li>Interfaz : es una colección de operaciones que especifica un servicio de una clase o componente. Por lo tanto, una interfaz describe el comportamiento visible externamente de ese elemento. Una interfaz puede representar el comportamiento completo de una clase o componente, o sólo una parte de este comportamiento. </li></ul><ul><li>Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca sus implementaciones. </li></ul><ul><li>Una interfaz raramente se encuentra aislada, más bien, suele estar conectada a la clase o componente que la realiza. </li></ul>
    18. 18. Colaboración <ul><li>Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. </li></ul><ul><li>Por lo tanto las colaboraciones tienen dimensión tanto estructural como de comportamiento. Una clase dada puede participar en varias colaboraciones. </li></ul><ul><li>Representación de una colaboración </li></ul>
    19. 19. Diagrama de Colaboración Práctica 3 *Desarrollo de Software Orientado a Objeto usando UML, Patricio Letelier Torres, http://www.dsic.upv.es/~uml/curso.ppt
    20. 20. Caso de uso <ul><li>Es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. </li></ul><ul><li>Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboración. </li></ul><ul><li>Representación de un caso de uso </li></ul>
    21. 21. Ejemplo de caso de uso *Desarrollo de Software Orientado a Objeto usando UML, Patricio Letelier Torres, http://www.dsic.upv.es/~uml/curso.ppt
    22. 22. Clase activa <ul><li>Es una clase cuyos objetos tienen uno o más procesos o hilos que constituyen flujos de control independientes pero concurrentes con otros flujos de control (con los que muy probablemente se deberán sincronizar). </li></ul><ul><li>Una clase activa es igual que una clase, excepto en que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. </li></ul><ul><li>Representación de una clase activa </li></ul><ul><li>(borde más grueso) </li></ul>Factura - fecha : Date … + imprimir() : void
    23. 23. Componentes <ul><li>A diferencia de los anteriores, elementos conceptuales o lógicos, los componentes y nodos representan elementos físicos. </li></ul><ul><li>Un componente es una parte física de un sistema que ofrece un conjunto de interfaces y proporciona la implementación de dicho conjunto. En un sistema, se pueden encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+, JavaBeans, así como componentes que sean artefactos del proceso de desarrollo, tales como archivos de código fuente. </li></ul><ul><li>Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases interfaces y colaboraciones. </li></ul><ul><li>Representación de un componente </li></ul>
    24. 24. Nodo <ul><li>Un nodo es un elemento físico que existe en tiempo de ejecución, representando un recurso computacional que, por lo general, dispone de algo de memoria y con frecuencia capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y puede también migrar de un nodo a otro. </li></ul><ul><li>Representación de un nodo </li></ul><ul><li>Aunque los anteriores son los siete elementos estructurales básicos, existen variaciones a partir de ellos, por ejemplo actores y señales (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas (tipos de componentes). </li></ul>
    25. 25. Resumen de elementos
    26. 26. Elementos en UML <ul><li>Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados. </li></ul>
    27. 27. Elementos de comportamiento <ul><li>Interacción : es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. Una interacción involucra muchos otros elementos, incluyendo mensajes, secuencias de acción y enlaces. </li></ul><ul><li>conducir </li></ul><ul><li>Máquina de estados : es un comportamiento que especifica la secuencia de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos. Una máquina de estados involucra a otros elementos, incluyendo estados, transiciones, eventos y actividades. </li></ul>Los elementos de comportamiento son las partes dinámicas de los modelos UML Representación de los elementos de comportamiento
    28. 28. Elementos en UML <ul><li>Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados. </li></ul>
    29. 29. Elementos de agrupación <ul><li>Son las partes organizativas de los modelos UML. </li></ul><ul><li>Hay un elemento de agrupación principal, los paquetes . Un paquete es un mecanismo de propósito general para organizar elementos en grupos. </li></ul><ul><li>Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupación pueden incluirse en un paquete. </li></ul><ul><li>Al contrario de los componentes (que existen en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). </li></ul>utilidades Representación de un paquete
    30. 30. Elementos en UML <ul><li>Estos elementos son lo bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados. </li></ul>
    31. 31. Elementos de anotación <ul><li>Son las partes explicativas de los modelos UML. </li></ul><ul><li>Hay un tipo principal llamado Nota . Una nota es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos. </li></ul><ul><li>Las notas se utilizan para adornar los diagramas con restricciones o comentarios que se expresan mejor en texto informal o formal. </li></ul>Representación de una nota
    32. 32. Un modelo conceptual de UML <ul><li>Uno de los bloques básicos de construcción de UML son las </li></ul><ul><li>Una relación es una conexión entre elementos. </li></ul><ul><li>Para diferenciar las distintas relaciones se utilizan diferentes tipos de líneas. </li></ul><ul><li>Las relaciones más importantes son las dependencias , las generalizaciones y las asociaciones . Existe también la relación de Realización </li></ul>relaciones
    33. 33. Dependencia <ul><li>Es una relación semántica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (el dependiente). </li></ul><ul><li>Las dependencias generalmente representan relaciones de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que la utiliza, pero no necesariamente a la inversa. </li></ul><ul><li>La mayoría de las veces se utilizan en el contexto de las clases o paquetes , para indicar que una clase utiliza a otra como argumento en la signatura de una operación. </li></ul>Representación de una dependencia PlanDelCurso agregar(c : Curso) eliminar(c : Curso) Curso
    34. 34. Generalización <ul><li>Es una relación entre un elemento general (llamado super-clase o clase padre) y un caso más específico de ese elemen-to (llamado subclase o clase hija). La generalización se llama a veces relación “es-un-tipo-de”: un elemento (clase TransporteTerrestre) es-un-tipo-de un elemento más general (clase Transporte). La generalización significa que los objetos hijos se pueden emplear en cualquier que pueda aparecer el padre, pero no a la inversa. Es decir, el hijo puede sustituir al padre. </li></ul><ul><li>El hijo hereda atributos y operaciones del padre. </li></ul><ul><li>El hijo puede agregar atributos y operaciones. </li></ul><ul><li>Puede tener operaciones polimórficas </li></ul>Representación de una generalización
    35. 35. Asociación <ul><li>Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. </li></ul><ul><li>Las asociaciones y dependencias pueden ser reflexivas. </li></ul><ul><li>Si existe una asociación entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto de la otra clase. </li></ul><ul><li>La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes. Representa una relación del tipo “tiene-un”. Ejemplo: </li></ul><ul><li>Un TransporteTerrestre “tiene” ruedas. </li></ul>
    36. 36. Realización <ul><li>Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización: entre interfaces y las clases o componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. </li></ul><ul><li>La realización es lo suficientemente diferente de la dependencia, la generalización y la asociación como para ser tratada como un tipo aparte de relación. Semánticamente la realización es una mezcla entre dependencia y generalización. </li></ul>Representación de una realización
    37. 37. Ejemplo de relaciones
    38. 38. Resumen de símbolos para relaciones
    39. 39. Modelo conceptual de UML <ul><li>Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje. Esto requiere aprender tres elementos principales: </li></ul><ul><li>Bloques básicos de construcción de UML </li></ul>relaciones
    40. 40. Diagramas de UML 1.5 <ul><ul><li>Diagrama de Casos de Uso </li></ul></ul><ul><ul><li>Diagrama de Clases </li></ul></ul><ul><ul><li>Diagrama de Objetos </li></ul></ul><ul><ul><li>Diagramas de Comportamiento </li></ul></ul><ul><ul><ul><li>Diagrama de Estados </li></ul></ul></ul><ul><ul><ul><li>Diagrama de Actividad </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Interacción </li></ul></ul></ul><ul><ul><ul><ul><li>Diagrama de Secuencia </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Diagrama de Colaboración </li></ul></ul></ul></ul><ul><ul><li>Diagramas de implementación </li></ul></ul><ul><ul><ul><li>Diagrama de Componentes </li></ul></ul></ul><ul><ul><ul><li>Diagrama de Despliegue </li></ul></ul></ul><ul><li>Un diagrama es la representación gráfica de un conjunto de elementos, visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). </li></ul><ul><li>Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema. En teoría un diagrama puede contener cualquier combinación de elementos y relaciones, sin embargo en la práctica solo surge un pequeño número de combinaciones. </li></ul>
    41. 41. Diagramas UML <ul><li>Si vemos el modelo de una forma estática: </li></ul><ul><li>Diagrama de clases </li></ul><ul><li>Diagrama de objetos </li></ul><ul><li>Diagrama de componentes </li></ul><ul><li>Diagrama de despliegue </li></ul><ul><li>Si analizamos el modelo de una forma dinámica (comportamiento): </li></ul><ul><li>Diagrama de casos de uso </li></ul><ul><li>Diagrama de secuencia </li></ul><ul><li>Diagrama de colaboración </li></ul><ul><li>Diagrama de estados </li></ul><ul><li>Diagrama de actividades </li></ul>A continuación analizaremos los dos diagramas más importantes: de clases y de objetos
    42. 42. Diagrama de clases <ul><li>Un diagrama de clases presenta un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. </li></ul><ul><li>Es el modelo más común en el modelado de sistemas orientados a objetos. </li></ul><ul><li>Se utilizan para describir la vista de diseño estática de un sistema. </li></ul><ul><li>La definición de clase incluye definiciones para atributos y operaciones. </li></ul><ul><li>Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. </li></ul><ul><li>Las clases se pueden utilizar para capturar el vocabulario del sistema que se está modelando. </li></ul><ul><li>Se pueden utilizar clases para representar cosas que sean software, hardware o puramente conceptuales. </li></ul>
    43. 43. Diagrama de clases
    44. 44. Diagrama de Objeto <ul><li>Un diagrama de objetos representa un conjunto de objetos y sus relaciones. </li></ul><ul><li>Se utilizan para describir estructuras de datos, instantáneas de las instancias de los elementos encontrados en los diagramas de clases. </li></ul><ul><li>Cubren la vista de diseño estática o la vista de procesos estática de un sistema desde la perspectiva de casos reales o prototípicos. </li></ul><ul><li>Los diagramas de objetos modelan las instancias de los elementos contenidos en los diagramas de clases. </li></ul><ul><li>Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. </li></ul>
    45. 45. Diagrama de Objeto c: Compañía Valor del atributo Enlace Enlace d1: Departamento nombre = “Ventas” d2: Departamento nombre = “I+D” d3: Departamento nombre = “Reparaciones” p: Persona nombre = “Francisco” id = 1234 cargo = “vendedor” :InformacionContacto dirección = “Avda. España 1234” Objeto anónimo
    46. 46. Un modelo conceptual de UML <ul><li>Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje. Esto requiere aprender tres elementos principales: </li></ul><ul><li>Bloques básicos de construcción de UML: elementos, relaciones y diagramas. </li></ul><ul><li>Reglas que dictan cómo se pueden combinar esos bloques. </li></ul><ul><li>Y algunos mecanismos comunes que se aplican a través de UML. </li></ul>
    47. 47. Reglas de UML <ul><li>Los bloques de construcción de UML no pueden combinarse de cualquier manera. Como cualquier lenguaje UML tiene unas reglas que especifican a qué debe parecerse un modelo bien formado. </li></ul><ul><li>Un modelo bien formado es aquel que es semánticamente autoconsistente y está en armonía con todos sus modelos relacionados. </li></ul><ul><li>UML tiene reglas semánticas para: </li></ul><ul><li>Nombres : cómo llamar a los elementos, relaciones y diagramas. </li></ul><ul><li>Alcance : el contexto que da significado específico a un nombre. </li></ul><ul><li>Visibilidad : cómo se pueden ver y utilizar esos nombres por otros. </li></ul><ul><li>Integridad : cómo se relacionan apropiada y consistentemente unos elementos con otros. </li></ul><ul><li>Ejecución : qué significa ejecutar o simular un modelo dinámico. </li></ul>
    48. 48. Mecanismos comunes <ul><li>Existen cuatro mecanismos comunes que se aplican de forma consistente a través de todo el lenguaje: </li></ul><ul><li>Especificaciones </li></ul><ul><li>UML no es sólo un lenguaje gráfico, sino que detrás de cada notación gráfica hay una especificación que proporciona una explicación textual de la sintaxis y semántica del bloque de construcción. </li></ul><ul><li>Por ejemplo, detrás del icono de una clase hay una especificación que proporciona información de sus atributos, operaciones, signaturas y comportamiento de la clase (visualmente el icono de la clase puede mostrar sólo parte de la especificación). </li></ul><ul><li>La notación gráfica de UML se utiliza para visualizar el sistema, la especificación se utiliza para enunciar los detalles de dicho sistema. </li></ul>
    49. 49. Adornos <ul><li>La mayoría de los elementos UML tienen una única y clara notación gráfica que proporciona una representación visual de los aspectos más importantes del elemento. Pero la especificación puede incluir otros detalles algunos de los cuales se pueden incluir como adornos gráficos en la notación base. </li></ul><ul><li>Por ejemplo se pueden incluir adornos en el icono de una clase indicando la visibilidad de la operaciones. </li></ul>
    50. 50. Divisiones comunes <ul><li>Al modelar sistemas orientados a objetos, el mundo puede dividirse por lo menos en un par de formas: clase-objeto e interfaz-implementación. </li></ul><ul><li>Una clase es una abstracción, un objeto es una manifestación concreta de dicha abstracción. Todos los bloques de construcción de UML (y no solo las clases) presentan esta dicotomía. </li></ul><ul><li>Por ejemplo se puede tener casos de uso e instancias de casos de uso, componentes e instancias de componentes. </li></ul><ul><li>Una interfaz declara un contrato, una implementación representa la realización concreta de ese contrato responsable de hacer efectiva de forma fidedigna la semántica completa de la interfaz. </li></ul><ul><li>Casi todos los bloques de construcción presentan esta otra dicotomía. Por ejemplo, se pueden tener casos de uso y las colaboraciones que los realizan, así como operaciones y los métodos que las implementan. </li></ul>
    51. 51. Mecanismos de extensibilidad <ul><li>UML proporciona un lenguaje estándar para escribir planos software, pero no es posible que un lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles de todos los modelos en todos los dominios y en todos los momentos. Por esta razón UML es abierto-cerrado, siendo posible extender el lenguaje de manera controlada. </li></ul><ul><li>Los mecanismos de extensión incluyen : estereotipos, valores etiquetados y restricciones. </li></ul>
    52. 52. Resumen <ul><li>Los cuatro diagramas estructurales de UML permiten visualizar, especificar, construir y documentar los aspectos estáticos de un sistema: </li></ul><ul><li>Un diagrama de clases presenta un conjunto de clases, interfaces y colabora-ciones, y las relaciones entre ellas. </li></ul><ul><li>Un diagrama de objetos representa un conjunto de objetos y sus relaciones. Se utilizan para describir estructuras de datos, instantáneas de los elementos encontrados en los diagramas de clases. Cubre los mismos aspectos que los diagramas de clases pero desde una perspectiva de casos reales o prototípicos. </li></ul><ul><li>Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Los diagramas de componentes se utilizan para describir la vista de implementación estática de un sistema. Los diagramas de componentes se relacionan con los diagramas de clases, ya que un componente normalmente se corresponde con una o más clases, interfaces o colaboraciones. </li></ul><ul><li>Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones. Los diagramas de despliegue se utilizan para describir la vista de despliegue estática de un sistema. Los diagramas de despliegue se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o más componentes. </li></ul>
    53. 53. Resumen <ul><li>Los siguientes diagramas de comportamiento de UML se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema. </li></ul><ul><li>Los diagramas de casos de uso organizan los comportamientos del sistema. Representa un conjunto de casos de uso y actores (un tipo especial de clases) y sus relaciones. </li></ul><ul><li>Diagramas de interacción : Se da este nombre colectivo a los diagramas de secuencia y los diagramas de colaboración. Ambos diagramas son isomorfos, es decir, se puede convertir de uno a otro sin pérdida de información. </li></ul><ul><ul><li>Un diagrama de secuencia es un diagrama de interacción que resalta la ordenación temporal de los mensajes. Presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos. </li></ul></ul><ul><ul><li>Un diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes. Un diagrama de colaboración muestra un conjunto de objetos , enlaces entre estos objetos y mensajes enviados y recibidos por estos objetos. </li></ul></ul><ul><ul><li>En ambos casos, los objetos normalmente son instancias con nombre o anónimas de clases, pero también pueden representar instancias de otros elementos, como colaboraciones, componentes y nodos. </li></ul></ul>
    54. 54. Resumen <ul><li>Un diagrama de estado representa una máquina de estados, constituida por estados, transiciones, eventos y actividades. Son especialmente importantes para modelar el comportamiento de una interfaz, una clase o una colaboración. Los diagramas de estados resaltan el comportamiento dirigido por eventos de un objeto, lo que es especialmente útil al modelar sistemas reactivos. </li></ul><ul><li>Un diagrama de actividades es un tipo especial de diagrama de estados que muestra el flujo secuencial o ramificado de actividades en un sistema o conjunto de actividades. </li></ul><ul><li>Son especialmente importantes para modelar la función del sistema, así como para resaltar el flujo de control entre objetos. </li></ul>
    55. 55. Bibliografía <ul><li>El Lenguaje Unificado de Modelado . G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley, 1999 </li></ul><ul><li>Uml Para Programadores Java . R. Martin. Pearson Educación, 2004 </li></ul><ul><li>UML y Patrones, introducción al análisis y diseño orientado a objetos . C. Larman. Prentice Hall, 1999 </li></ul><ul><li>http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html </li></ul><ul><li>http://tvdi.det.uvigo.es/~avilas/UML/node1.html </li></ul><ul><li>http://www.clikear.com/manuales/uml/index.aspx </li></ul><ul><li>http://www.dcc.uchile.cl/~psalinas/uml/ </li></ul><ul><li>http://arodm.blogspot.com/2008/09/uml-relaciones-compocicion-agregacion.html </li></ul><ul><li>http://www.programacion.com/tutorial/uml/ </li></ul><ul><li>http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r43098.PDF </li></ul><ul><li>http://www.dsic.upv.es/~uml/curso.ppt </li></ul>

    ×