Upcoming SlideShare
×

200609

1,082 views
1,033 views

Published on

0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
1,082
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
33
0
Likes
0
Embeds 0
No embeds

No notes for slide

200609

1. 1. MODULOLENGUAJE UNIFICADO DE MODELADO UML ING. HAROLD CABRERA MEZA UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA SAN JUAN DE PASTO, 2006 1
2. 2. TABLA DE CONTENIDOINTRODUCCION .................................................................................................... 61. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO ..................... 71.1. QUÉ ES UML?................................................................................................. 71.1.2. UML NO ES UN MÉTODO ........................................................................... 81.1.3. MODELOS .................................................................................................... 91.1.4. ELEMENTOS COMUNES A TODOS LOS DIAGRAMAS .......................... 101.2. MODELADO ESTRUCTURADO ................................................................... 111.2.1. BLOQUES DE CONSTRUCCIÓN DE UML................................................ 111.2.2. CLASES...................................................................................................... 151.2.3. OBJETOS ................................................................................................... 171.2.4. ASOCIACIONES......................................................................................... 181.2.5. DIAGRAMAS .............................................................................................. 201.2.6. DIAGRAMAS DE CLASE ........................................................................... 231.2.7. CARACTERÍSTICAS AVANZADAS DE LAS CLASES Y RELACIONES . 261.2.8. INTERFACES, TIPOS Y ROLES ................................................................ 311.2.9 PAQUETES E INSTANCIAS ...................................................................... 351.2.10. HERENCIA Y POLIMORFISMO ............................................................... 362. CARACTERISTICAS DEL MODELADO UML ................................................. 382.1. DIAGRAMAS UTILIZADOS EN UML ............................................................ 38 2
3. 3. 2.1.1. DIAGRAMAS DE OBJETOS ...................................................................... 382.1.2. DIAGRAMAS DE CASOS DE USO............................................................ 402.1.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 452.1.4. DIAGRAMAS DE ACTIVIDADES ............................................................... 472.2. MODELADO DINÁMICO ............................................................................... 512.2.1 EVENTOS Y SEÑALES............................................................................... 512.3.2 MÁQUINAS DE ESTADO............................................................................ 532.4.3 TIEMPO Y ESPACIO ................................................................................... 552.4.4 DIAGRAMAS DE ESTADO ......................................................................... 562.3. MODELADO ARQUITECTÓNICO................................................................. 572.3.1. COMPONENTES, DESPLIEGUE, COLABORACIONES Y PATRONES... 572.3.2. DIAGRAMAS DE COMPONENTES ........................................................... 612.3.3. DIAGRAMAS DE DESPLIEGUE ................................................................ 622.3.4. SISTEMAS Y MODELOS ........................................................................... 633. DESARROLLO ORIENTADO A OBJETOS CON UML ................................... 663.2. FASE DE PLANIFICACIÓN Y ESPECIFICACIÓN DE REQUISITOS ........... 683.2.1 ACTIVIDADES ............................................................................................. 683.2.2. REQUISITOS .............................................................................................. 683.2.3. CONSTRUCCIÓN DEL MODELO DE CASOS DE USO............................ 743.2.4. PLANIFICACIÓN DE CASOS DE USO SEGÚN CICLOS DE 3
4. 4. DESARROLLO ..................................................................................................... 753.3. DISEÑO DE ALTO NIVEL ............................................................................. 763.3.1 ACTIVIDADES ............................................................................................. 773.3.2. MODELO CONCEPTUAL........................................................................... 773.3.3. DIAGRAMAS DE SECUENCIA DEL SISTEMA ......................................... 793.3.4. DIAGRAMAS DE ESTADOS ...................................................................... 813.4. DISEÑO DE BAJO NIVEL ............................................................................. 823.4.1 ACTIVIDADES ............................................................................................. 823.4.2. CASOS DE USO REALES ......................................................................... 823.4.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 833.4.4. CONSTRUCCIÓN DIAGRAMAS DE DISEÑO ........................................... 883.5. FASES DE IMPLEMENTACIÓN Y PRUEBAS .............................................. 90 4
9. 9. 1994),(Object-Oriented Design, With Applications), detallan un m odo ofreciendotambién diseño y análisis iterative, centrándose en el lado del diseño.1.1.3. ModelosUn modelo representa a un sistema software desde una perspectiva específica. Aligual que la planta y el alzado de una figura en dibujo técnico nos muestran lamisma figura vista desde distintos ángulos, cada modelo nos permite fijarnos enun aspecto distinto del sistema.Los modelos de UML que se tratan en esta parte son los siguientes:•Diagramas de clases: muestra un conjunto de clases, interfaces ycolaboraciones, así como sus relaciones, son los más comunes en el modeloorientado a objetos y cubren las vistas de diseño estático de un sistema.•Diagramas de Objetos: muestra un conjunto de objetos y sus relaciones,representan instancias de los elementos encontrados en los diagramas de clases,representado cubren las vistas de diseño estático de un sistema desde laperspectiva de casos reales.•Diagrama de Actividades: es un tipo especial de diagrama de estados quemuestra el flujo de actividades dentro de un sistema, cubren la vista dinámica deun sistema. Son especialmente importantes al modelar el funcionamiento de unsistema y resaltan el flujo de control de objetos.•Diagrama de Componentes: muestra la organización y las dependencias entreun conjunto de componentes, cubren la vista estática de un sistema.•Diagrama de Despliegue: muestra la configuración de nodos de procesamientoen tiempo de ejecución y los componentes que residen en ellos, cubren la vista dedespliegue estática de una arquitectura. 9
10. 10. Diagrama de Casos de Uso: muestra un conjunto de casos de uso, actores yrelaciones, cubren la vista de casos de uso estática de un sistema.•Diagrama de Secuencia: es un diagrama de interacción que resalta laordenación temporal de los mensajes.•Diagrama de Colaboración: es un diagrama de interacción que resalta laorganización estructural de los objetos que envían y reciben mensaje.•Diagrama de Estados: Muestra una máquina de estados, que consta deestados, transiciones, eventos y actividades, cubren la vista dinámica de unsistema, resaltan el comportamiento dirigido por eventos de un objeto.1.1.4. Elementos comunes a todos los diagramasNotasUna nota sirve para añadir cualquier tipo de comentario a un diagrama o a unelemento de un diagrama. Es un modo de indicar información en un formato libre,cuando la notación del diagrama en cuestión no nos permite expresar dichainformación de manera adecuada. Una nota se representa como un rectángulocon una esquina doblada con texto en su interior. Puede aparecer en un diagramatanto sola como unida a un elemento por medio de una línea discontinua. Puedecontener restricciones, comentarios, el cuerpo de un procedimiento, etc. Figura 1. 10
11. 11. DependenciasLa relación de dependencia entre dos elementos de un diagrama significa que uncambio en el elemento destino puede implicar un cambio en el elemento origen(por tanto, si cambia el elemento destino habría que revisar el elemento origen).Una dependencia se representa por medio de una línea de trazo discontinuo entrelos dos elementos con una flecha en su extremo. El elemento dependiente es elorigen de la flecha y el elemento del que depende es el destino (junto a él está laflecha).1.2. Modelado EstructuradoPara comprender UML, se necesita adquirir un modelo conceptual del lenguaje yesto requiere aprender tres elementos principales: los bloques básicos deconstrucción de UML, las reglas que dictan cómo se pueden combinar estosbloques básicos y algunos mecanismos comunes que se aplican a través de UML,Una ves comprendida estas ideas, se pueden leer modelos UML y crear algunosmodelos básicos.1.2.1. Bloques de Construcción de UMLEl vocabulario de UML incluye tres clases de bloques de construcciónElementos en UMLHay 4 tipos de elementos en UML, elementos estructurales, elementos decomportamiento, elementos de agrupación y elementos de anotación: . Figura 2. 11
12. 12. Elementos EstructuralesNombre Descripción SímboloInterfaz • Es una colección de operaciones que especifica un servicio de una clase o componente, representa el comportamiento completo de una clase o componenteColaboración • Se definen como 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 • las colaboración representan la implementación de patrones que forman un sistemaCaso de Uso • Es una descripción de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular • Se utiliza para estructurar el comportamiento en un modeloClase Activa • Es un clase objetos tienen uno o mas procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control • Son iguales a las clases excepto en que sus objetos representan elementos cuyos comportamiento es concurrente con otros elementosComponente • Es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto • Representa típicamente e empaquetamiento físico de diferentes elementos lógicos, como clases interfaces y colaboracionesNodo • Es un elemento físico que existe en Nodo1 tiempo de ejecución y representa un rescursos computacional que dispone de memoria y con frecuencia capacidad de procesamiento 12
13. 13. Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clasesactivas, componentes y nodos) son los elementos estructurales básicos que sepueden incluir en el modelo UML. También existen variaciones de estos sieteelementos, tales como actores, señales, procesos e hilos, y aplicaciones,documentos, archivos, bibliotecas, páginas y tablas.Los elementos de comportamiento son las partes dinámicas de los modelosUML. Estos son los verbos de un modelo y representan comportamiento en eltiempo y en el espacio. • 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 especifico • Máquina de Estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventosEstos dos elemento (interacciones y máquinas de estado) son los elementos decomportamiento que se pueden incluir de un modelo UML, estos elementos estánconectados normalmente a diversos elementos estructurales, principalmenteclases, colaboraciones y objetos.Los Elementos de agrupación son las partes organizativas de los modelos UML.Estos son las cajas en las que pueden descomponerse un modeloPaquete• Es un mecanismo de propósito general para organizar elementos en grupos.• En los paquetes se pueden agrupar los elementos estructurales, de comportamiento e incluso otros elementos de agrupaciónLos paquetes son los elementos de agrupación básicos con los cuales se puedeorganizar un modelo UML. También hay variaciones, tales como los framework,los modelos y los subsistemas 13
14. 14. RelacionesExisten cuatro tipos de la relaciones en UML • Dependencias • Asociaciones • Generalizaciones • RealizaciónEstas relaciones son los bloques básicos de construcción para las relaciones deUML.Relaciones en UMLDependencia: Es una relación semántica entre dos elementos, en la cual uncambio a un elemento pude afectar la semántica de otro elementoAsociaciones: Es una relación estructural que describe un conjunto de enlaces,los cuales son conexiones entre objeto y representa una relación estructural entreun todo y sus partesDiagramasUn 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). Los diagramas se dibujan para visualizar un sistema desdediferentes perspectivas, de forma que un diagrama es una proyección de unsistema, un diagrama representa una vista resumida de los elementos queconstituyen un sistema. (Los tipos de diagramas que utiliza UML se mencionan enel Numeral 1.1.2. de este módulo). 14
15. 15. 1.2.2. ClasesUna clase es una descripción de un conjunto de objetos que comparten losmismos atributos, operaciones, relaciones y semántica, las clases puedenrepresentar cosas que sean hardware, software o completamente conceptuales.Las clases forman parte de una distribución equilibrada de responsabilidades en elsistemaUML representa una representación gráfica de las clases como se muestra en lafigura ex, Nombre Figura Origen atributos Mover() Visualizar() operaciones Figura 3.Componentes de las ClasesUna clase es un descripción de un conjunto de objetos que comparten los mimosatributo, operaciones, relaciones y semántica, gráficamente una clase serepresenta como un rectángulo, en el cual se describen las características de losobjetos que representa, entre ellos tenemos1. Nombre: una clase a de contener un nombre que la identifique, compuesto por cualquier numero de letras y números exceptuado los dos puntos pues estos se utilizan para separar el nombre de una clase y el paquete que lo contiene.2. Atributos: es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Un atributo representa alguna propiedad del elemento que se está modelando que es compartida por todos los objetos de esa clase, además, una clase puede o no contener atributos. Por ejemplo un atributo de la clase estudiante es el nombre, apellido, fecha Nacimiento, etc. 15
16. 16. Estudiante nombre apellido atributos fecha Nacimiento Figura 4.3. Operaciones: Es una abstracción de de algo que se puede haber a un objeto y que es compartido por todos los objetos de la clase, las clases pueden tener o no operaciones. Ejemplo en la clase estudiante se puede a los objetos generados por ella, matricular, evaluar, aprobar y estas operaciones son comunes a todos los objetos que se describen a través de la clase estudiante. Estudiante Nombre Apellido Fecha nacimiento Matricular() Evaluar() Operaciones Aprobar() Figura 5.4. Responsabilidades: Es una obligación de las clases, al crear una clase, se esta expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento, de forma mas general los atributos y operaciones son las características por medio de la cuales se llevan a cabo las responsabilidades de la clase. Gráficamente las responsabilidades se pueden expresar en un comportamiento separado al final del icono de la clase. Estudiante nombre apellido fecha Nacimiento matricular() evaluar() aprobar() Responsabilidades Respetar el Reglamento Responsabilidades Estudiantil Figura 6. 16
17. 17. Usos Comunes de las ClasesLas clases se utilizan para modelar y representar el conjunto de elementos de unsistema de manera general (abstracciones), para determinar los problemas que seintenta resolver y así implementar una solución.Para definir las clases que intervienen dentro de un sistema se recomienda comopuntos de partida las siguientes consideraciones:• Identificar aquellas cosas que utilizan los usuarios o programadores para describir el problema o la solución• Identificar las responsabilidades de cada clase y asegurarse que cada clase existe• Identificar los atributos y operaciones necesarios para cumplir sus responsabilidades• Hacer del conjunto de clases y sus responsabilidades un modelo equilibrado donde no existan clase demasiado grandes ni pequeñas• Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de la clase que sean importantes, como también sus atributos y operaciones1.2.3. ObjetosUn objeto se representa de la misma forma que una clase. En el compartimientosuperior aparecen el nombre del objeto junto con el nombre de la clasesubrayados, según la siguiente sintaxis: nombre_del_objeto:nombre_de_la_clasePuede representarse un objeto sin un nombre específico, entonces sólo aparece elnombre de la clase. Figura 7. 17
18. 18. 1.2.4. AsociacionesEs una relación estructural que especifica que los objetos de un elemento estánconectados con los objetos de otro. Dada una asociación entre dos clases, sepuede navegar desde un objeto de una clase hasta el objeto de otra clase, yviceversa. Una asociación que conecta dos clases se dice binaria, sí conecta másde dos clases se denomina asociación n-arias, las asociaciones se utilizaráncuando se quieren representar relaciones estructurales.Características de las Asociaciones y operacionesNombre de la Asociación y DirecciónEl nombre de la asociación se utiliza para describir la naturaleza de la relación, esopcional y se muestra como un texto que está próximo a la línea. Se puede añadirun pequeño triángulo negro sólido que indique la dirección en la cual leer elnombre de la asociación. En el ejemplo se puede leer la asociación como “Directormanda sobre Empleado”. Figura 8.Los nombres de las asociaciones normalmente se incluyen en los modelos paraaumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiadoabundante la información que se presenta, con el consiguiente riesgo desaturación. En ese caso se puede suprimir el nombre de las asociacionesconsideradas como suficientemente conocidas. En las asociaciones de tipoagregación y de herencia no se suele poner el nombre. 18
19. 19. MultiplicidadLa multiplicidad es una restricción que se pone a una asociación, que limita elnúmero de instancias de una clase que pueden tener esa asociación con unainstancia de la otra clase. Puede expresarse de las siguientes formas:• Con un número fijo: 1.• Con un intervalo de valores: 2.5.• Con un rango en el cual uno de los extremos es un asterisco Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.• Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*.• Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).RolesUn rol es simplemente la cara que la clase de un extremo de la asociaciónpresenta a la clase del otro extremo. Figura 9. 19
20. 20. Para indicar el papel que juega una clase en una asociación se puede especificarun nombre de rol. Se representa en el extremo de la asociación junto a la claseque desempeña dicho rol.AgregaciónEl símbolo de agregación es un diamante colocado en el extremo en el que está laclase que representa el “todo”. Figura 10.1.2.5. DiagramasUn diagrama es una presentación gráfica de un conjunto de elementos, que lamayoría de la veces se dibuja como un conjunto de elementos relacionados, losdiagramas se utilizan para representar un sistema desde diferentes perspectivas,por esto UML a definido varios diagramas que permiten centrarse en diferentesaspectos del sistema independientemente.Un diagrama es una proyección gráfica de los elementos que configuran unsistema. Por ejemplo, se podría tener cientos de clases en el diseño de un sistemade recursos humanos de un empresa, pero no se podría ver la estructura o elcomportamiento de ese sistema observando un gran diagrama con todas susclases y relaciones, es entonces preferible realizar varios diagramas queespecifiquen las vistas relevantes solamente a ese subsistema definido, este tipode manejo de diagramas representativos por clases permite realizar agrupacionesque muestran el funcionamiento general del sistema de forma particular perodenotando el funcionamiento general del sistema con todos sus elementosconstitutivos. 20
21. 21. Con el modelado de sistemas se obtienen deferentes tipos de vistas, las vistasestáticas de los sistemas en UML se representan con 4 tipos de diagramas que sedescriben a continuaciónDiagramas Estructuraleslos cuales comprenden los siguientes diagramas• Diagramas de ClasesRepresenta un conjunto de clases, interfaces y colaboraciones, y las relacionesentre ellas. Los diagramas de clases los diagramas más comunes en el modeladode sistemas orientados a objetos. Estos diagramas se utilizan para describir lasvista de diseño estática de un sistema, incluyen clases activas se utilizan paracubrir la vista de procesos estática de un sistema• Diagramas de ObjetosRepresenta un conjunto de objetos y sus relaciones. Se utiliza para describirestructuras de datos y las instancias de los elementos encontrados en losdiagramas de clases. Cubren la vista de diseño estática o la vista de procesoestática de un sistema al igual que los diagramas de clases. Pero desde laperspectiva de casos reales prototipos.• Diagramas de ComponentesMuestra un conjunto de componentes y relaciones, se utilizan para describir lavista de implementación estática de un sistema, se relacionan con los diagramasde clases en que un componente normalmente se corresponde con una másclases. Interfaces o colaboraciones• Diagramas de despliegueMuestra un conjunto de nodos y sus relaciones, se utilizan para describir la vistade despliegue estática de una arquitectura, se relacionan con los diagramas decomponentes en que un nodo normalmente incluye uno o más componentes. 21
23. 23. modelar la función de un sistema así como para resaltar el flujo de control entreobjetos1.2.6. Diagramas de ClaseUn diagrama de clases de uso muestra un conjunto de interfaces, colaboracionesy sus relaciones. Gráficamente, un diagrama de clases es una colección de nodosy arcos.Los diagramas de clases contienen normalmente los siguientes elementos, clases,interfaces, colaboraciones, relaciones de dependencia, generalización yasociación. Los diagramas pueden también notas, restricciones, paquetes osubsistemas, los cuales se usan para agrupar los elementos de un modelo enpartes más grandes.Usos de los diagramas de clasesSe utilizan para modelar la vista estática de un sistema, muestra principalmentelos requisitos funcionales de un sistema y los servicios que el sistema debeproporcionar a sus usuarios finalesLos diagramas de clases se utilizan cuado se modela la vista de diseño de unsistema de la siguiente forma:• Para modelar el vocabulario de un sistemaEl modelado del vocabulario de un sistema implica tomar decisiones sobre queabstracciones son parte del sistema en consideración y cuales caen fuera de suslímites. Los diagramas de clases se utilizan para especificar estas abstracciones ysus responsabilidades• Para modelar colaboraciones simplesUna colaboración es una sociedad de clases, interfaces y otros elementos quecolaboran para proporcionar un comportamiento cooperativo mayor que la sumade todos los elementos. 23
24. 24. Cuando se crea un diagrama de clases, se esta modelando una parte de loselementos y las relaciones que configuran la vista de diseño del sistema, por estarazón cada diagrama de clases debe centrarse en una colaboración cada vez.Para modelar una colaboración se debe tener en cuenta:• Identificar los mecanismos que se quiere modelar, un mecanismo representa una función o comportamiento de la parte del sistema que se está modelando que resulta de la interacción de una sociedad de clases, interfaces y otros elementos.• Identificar las clases, interfaces y otras colaboraciones que participan en esta colaboración identificando las relaciones entre estos elementos.• Usar escenarios para recorrer la interacción entre estos elementos.• Identificar las responsabilidades y hacer un reparto equilibrada de ellas en los elementos que componen el sistemaPor ejemplo la siguiente figura muestra un conjunto de clases que muestran elsistema de facturación y control de ventas de una empresa, las clases se centranen la forma como se maneja la facturación de inmuebles y productos de consumo,aparece una clase abstracta llamada factura que muestra a su vez 2 hijosfacturacomestibles y facturainmuebles a su vez las dos clases se muestran comopartes de otra clase denominada vendedor. La clase ventas tiene una asociaciónuno a uno con vendedor y una asociación uno a muchos con controlvendedor nose muestran atributos ni operaciones para la clase ventas pero sí se muestran susresponsabilidades. 1 * Ventas controlventas 1 1 Responsabilidad vendedor Ventas promedio Buscar clientes 1 1 facturacomestibles facturainmuebles Factura Registrar venta() Registrar proveedor() Registrar cliente() Informes() Figura 11. 24
25. 25. • Para modelar un esquema lógico de base de datosEste esquema representa el plano que permite el diseño conceptual de la base dedatos sea para una base de datos relacional o una base de datos orientada aobjetos. Para modelar un esquema tenemos en cuenta:• Identificar las clases que van a ser persistentes en el diseño general de la bases de datos.• Crear un diagrama de clases que contenga estas clases y marcarlas como persistentes.• Expandir los detalles estructurales de estas clases, es decir, especificar los detalles de sus atributos y centrar su atención en la asociaciones que estructuran estas clases.• Identificar las relaciones de las bases de datos sea uno a uno, uno a varios y sus asociaciones.• Definir de manera clara las reglas de negocio relativas a la manipulación de datos dentro de la base de datosLa figura muestra un conjunto de clases extraídas de un sistema de informaciónque determina las relaciones entre los estudiantes, el profesor y el curso que elestudiante va a estudiar Universidad Nombre: texto Departamento 0..1 Dirección: texto Telefono: número tiene Nombre: texto añadirProfesor() añadirEstudiante() 1 1..* quitarProfesor () quitarEstudiante() obtenerProfesor () 1..* obtenerEstudiante() añadirDepartamento() 1..* quitarDepartamento() obtenerDepartamento() Asignado a 0..1 director Estudiante Curso Profesor * asiste * enseña Nombre: texto Nombre: texto Nombre: texto idEstudiante: número idCurso: número * 1..* Figura 12. 25
26. 26. El anterior diagrama muestra en detalle cada una de las clases con susrespectivos atributos, los cuales permiten construir la base de datos física,comenzando por la parte inferior izquierda se encuentra las clases estudiantes,curso y profesores, hay una asociaciónLas clases se han marcado como persistentes, es decir, sus instancias se hanconcebido para almacenar en una base de datos u otra forma de almacenamientopersistente.1.2.7. Características Avanzadas de las Clases y relacionesEl tipo más importante de clasificador en UML es la clase, una clase es unadescripción de un conjunto de objetos que comparten los mismos atributos,operaciones, relaciones y semántica. Sin embargo las clases no son el único tipode clasificador, existen otros tipos de clasificadores que ayudan a modelar:• Interfaz: es una colección de operaciones que especifican un servicio de una clase o componente Figura 13.• Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos primitivos predefinidos. <<type>> int (valores entre -32000 y 320000) Figura 14. 26
27. 27. • Señal: la especificación de un estímulo asíncrono enviado entre instancias <<signal>> DisparoAlarma Figura 15.• Componente: una parte física y reemplazable de un sistema que conforma y proporciona la realización de un conjunto de interfaces. Kernell32 Figura 16.• Nodo: un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, generalmente con alguna memoria y a menudo capacidad de almacenamiento. Figura 17.• Caso de uso: descripción de una secuencia de acciones, incluye variantes, que se ejecuta un sistema y produce un resultado observable para un actor particular Figura 18. 27
29. 29. Factura(root) Registrar venta() Registrar proveedor()Clase padre principal Registrar cliente() Informes() Facturacomestibles FacturainmueblesClases hijos Mostrarusuario() Mostrarusuario() (leaf) Clases hoja, no puede tener mas hijos Figura 20.Las clases tienen muchas operaciones entre sí, las que se “heredan” entre clasesse denominan polimórficas esto ocurre cuando los objetos han ejecutado unaoperación que esta definida en la clase que los contiene pero con la diferencia deque la operación cambia de significado dependiendo del contexto donde se esteejecutado.Generalidades de las relacionesAl modelar los elementos que constituyen el vocabulario de un sistema, tambiénhay que modelar cómo se relacionan entre sí estos elementos, las relaciones dedependencia, las generalizaciones y las asociaciones son los tres bloques deconstrucción de relaciones más importantes de UML. Observemos elcomportamiento de estas relaciones.Relaciones de Dependencia:Una dependencia es una relación de uso, la cual especifica que un cambio en laespecificación de un elemento puede afectar a otro elemento que lo utiliza, perono necesariamente a la inversa. Gráficamente, una dependencia se representa 29
30. 30. como una línea continua dirigida hacia el elemento del que se depende. Lasdependencias se deben aplicar cuando se quiera representar que un elementoutiliza a otroRelaciones de GeneralizaciónUna generalización es una relación entre un elemento (superclase o padre) y untipo mas efectivo de ese elemento (subclase o hijo). Por ejemplo, se puedeencontrar la clase general ventana junto a un tipo mas especifico ventaconmarco,con una relación de generalización del hijo al padre, el hijo ventaconmarcoheredará la estructura y comportamiento del padre ventana, en una generalizaciónla instancia del hijo pueden usarse donde quiera que se puedan usar lasinstancias del padre.La generalización se manifiesta en la herencia simple que a veces es suficiente ena mayoría de las veces, aunque, la herencia múltiple es mas adecuada,gráficamente se muestra de la siguiente forma: Figura 21.En la figura anterior se muestra la clase activo con tres hijos: CuentaBancaria,inmueble y valor dos de estos hijos (CuentaBancaria, Inmueble) tienen suspropios hijos por ejemplo Accion y Bono son ambos hijos de valorDos de estos hijos (CuentaBancaria, Inmueble) heredan de varios padresinmueble por ejemplo, es un tipo de activo, así como un tipo de Elemento-Asegurable y CuentaBancaria, es un tipo de activo así como unElementoConInteres y un ElementoAsegurable 30
31. 31. Relaciones de AsociaciónUna asociación es una relación estructural que especifica que los objetos de unelemento se conectan a los objetos de otro, por ejemplo, una clase bibliotecapodría tener una asociación uno a muchos con clase libro, indicando que cadainstanci de libro pertenece a una instancia de biblioteca, además, dado un libro, sepuede encontrar su biblioteca, y dando una biblioteca se puede navegar haciatodos los libros, gráficamente, un asociaciones se representa con una líneacontinua entre la misma o diferentes clases. Las relaciones se utilizan paramostrar relaciones estructurales.En la siguiente asociación simple se muestra como se hace la navegación entreobjetos por ejemplo al modelar una asociación entre 2 objetos como Usuario yClave se tiene que un dado un Usuario se puede encontrar las correspondientesClaves, pero dada una Clave no se podría identificar al Usuario correspondiente. 1 * Usuario Clave La línea representa una asociación y la fecha indica la dirección del recorrido Figura 22.1.2.8. Interfaces, Tipos y rolesInterfazEl manejo de las interfaces dentro del UML es importante ya que proporcionan almodelador un registro exacto de las fronteras existentes entre los diferentesprocesos del sistema, con lo cual se pretende observar al sistema en suscomponentes integrales para así determinar que procesos se pueden afectar sinque se afecten los otros.La construcción de interfaces permite también el manejo de librerías estándarreutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sinnecesidad de afectar el funcionamiento general del sistema. Se entiendo comointerfaz como una colección de operaciones que sirven para especificar un serviciode una clase o un componente. 31
32. 32. Cada interfaz ha de tener un nombre que la distingue de otras interfaces, elnombre de la interfaz puede ser simple o de camino cuando en este se indica elnombre de la interfaz y el paquete en el que se encuentre Nombre elemental IOrtografía Nombre de camino Red::IRouter Figura 23.Operaciones de las InterfacesAl contrario de las clases y los tipos, las interfaces no especifican ningunaestructura, las interfaces no incluyen atributos ni métodos, pero estas puedencontener cualquier número de operaciones. La siguiente notación hace referenciaa una interfaz donde se manifiesta de manera gráfica su nombre y operaciones adiferencia de la notación del círculo presentada anteriormente.Proporciona un mecanismo para modelar la conformidad estática y dinámica deuna abstracción con una interfaz en un contexto específico Nombre de la interfaz <<interface>> FlujoURL Abrirconexion() EstablecerURL() Operaciones de la interfaz Figura 24.Notese en la representación el nombre <<interface>> como identificador de lainterfase definida. 32
33. 33. Las relaciones entre interfaces se realizan de la misma manera como serelacionan con las clases puesto que las relaciones son del mismo tipo, pararecordar: relaciones de generalización, relaciones de asociación y relaciones dedependencia.Como se mostró anteriormente las interfaces se pueden denotar mostrándosecomo un círculo o con sus operaciones, dentro de un diagrama de interacciónentre clases los resultados para mostrar las relaciones entre las clases a través delas interfaces se expresa de la siguiente manera: Figura 25.La primera forma es la sencilla en la cual se muestra la conexión de dos clases através de un circulo que representa la interfaz con la cual se comunican dichasclases, la segunda forma muestra de manera mas detallada las operaciones conlas cuales interactúan las clases definidas antes y después de la interfase, nótesecomo se representan las relaciones de dependencia de la misma forma como semostró en las relaciones entre clases. 33
34. 34. Tipos y rolesUn rol representa un comportamiento de una entidad que participa en un contextoparticular, por ejemplo consideremos una instancia de una clase denominadaprofesor, este profesor puede ser de matemáticas, sociales, informática, física, etc,para cada rol generado de clase profesor, se deduce que las propiedades cadarol son exclusivas y en ningún momento pueden tomar propiedades de un rol queno le corresponda.Para representar el rol que representa un objeto dentro de una relación de clasesen notación UML se tiene por ejemplo: Figura 26. Figura 27.La figura anterior representa una asociación de clases con una interfaz especifica,como se ve existe una asociación de entre las clases persona y empresa en cuypcontexto persona juega un rol llamado e, cuyo tipo es empleado 34
35. 35. 1.2.9 Paquetes e InstanciasUn paquete es un mecanismo de próposito general para organizar elementos engrupos, graficamente un paquete se representa como una carpeta. Cada paquetea de contener un nombre que lo distingue de los demás. cliente Nombre del Paquete +FormualarioDePedido +FormularioDeSeguimiento -Pedido Elementos contenidos en el paquete Figura 28.Un paquete puede contener otros elementos incluyendo clases, interfaces,componentes, nodos, colaboraciones, casos de uso, diagramas en incluso otrospaquetes. Sí el paquete se destruye el elemento contenido en él es destruido,pues cada elemento cada elemento pertenece exclusivamente a un único paquete.Una instancia es una manifestación concreta de una abstracción a la que sepuede aplicar un conjunto de operaciones y que posee un estado que almacena elefecto de las operaciones. gráficamente una instancia se representa subrayandosu nombre teclasPulsadas: Colas Instancia con nombre : Marco Instancia anónima agente: Instancia huérfana Figura 29. 35
38. 38. 2. CARACTERISTICAS DEL MODELADO UML2.1. Diagramas Utilizados en UML2.1.1. Diagramas de ObjetosLos diagramas de objetos modelan las instancias de elementos contenidos en losdiagramas de clases. Un diagrama de objetos muestra un conjunto de objetos ysus relaciones en un momento concreto. En UML, los diagramas de clase seutilizan para visualizar los aspectos estáticos del sistema y los diagramas deinteracción se utilizan para ver los aspectos dinámicos del sistemas, y constan deinstancias de los elementos del diagrama de clases y mensajes enviados entreellos. En un punto intermedio podemos situar los diagramas de objetos, quecontiene un conjunto de instancias de los elementos encontrados en el diagramade clases, representando sólo la parte estática de una interacción, consistiendo enlos objetos que colaboraran pero sin ninguno de los mensajes intercambiadosentre ellos.Los diagramas de objetos se emplean para modelar la vista de diseño estática o lavista de procesos estática de un sistema al igual que se hace con los diagramasde clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vistasustenta principalmente los requisitos funcionales de un sistema. Los diagramasde objetos permiten modelar estructuras de datos estáticas,En general los diagramas de objetos se utilizan para modelar estructuras deobjetos, lo que implica tomar una instantánea de los objetos de un sistema en uncierto momento. Un diagrama de objetos representa una escena estática dentro dela historia representada por un diagrama de interacción. Los diagramas de objetosse utilizan para visualizar, especificar, construir y documentar la existencia deciertas instancias en el sistema, junto a las relaciones entre ellas. 38
39. 39. Figura 30.En la figura anterior se representa un conjunto de objetos extraídos de laimplementación de un robot. Como indica la figura, un objeto representa al propiorobot, (r es una instancia de Robot), y r se encuentra actualmente en estadomovimiento. Este objeto tiene un enlace con m, una instancia de Mundo, querepresenta una abstracción del modelo del mundo del robot. Este objeto tiene unenlace con un multiobjeto, un conjunto de instancias de Elemento, querepresentan entidades que el robot ha identificado, pero aún no ha asignado en suvista del mundo.En este instante, m está enlazado a dos instancias de Area. Una de ellas (a2)semuestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cadauna de estas paredes está etiquetada con su anchura actual, y cada una semuestra enlazada a sus paredes vecinas. Como sugiere este diagrama de objetos,el robot ha reconocido el área que lo contiene, que tiene paredes en tres lados yuna puerta en el cuarto.Como vemos los diagramas de objetos son especialmente útiles para modelarestructuras de datos complejas. Evidentemente puede existir una multitud deposibles instancias de una clase particular, y para un conjunto de clases con trelaciones entre ellas, pueden existir muchas más configuraciones posibles de 39
40. 40. estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrarsignificativamente conjuntos interesantes de objetos concretos o prototípicos.2.1.2. Diagramas de Casos de UsoEl diagrama de casos de uso representa la forma en como un Cliente (Actor)opera con el sistema en desarrollo, además de la forma, tipo y orden en como loselementos interactúan (operaciones o casos de uso). Un diagrama de casos deuso consta de los siguientes elementos: • Actor. • Casos de Uso. • Relaciones de Uso, Herencia y Comunicación.ElementosActor: Figura 31.Una definición previa, es que un Actor es un rol que un usuario juega conrespecto al sistema. Es importante destacar el uso de la palabra rol, pues con estose especifica que un Actor no necesariamente representa a una persona enparticular, sino más bien la labor que realiza frente al sistema.Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventasen que el rol de Vendedor con respecto al sistema puede ser realizado por unVendedor o bien por el Jefe de Local. 40
41. 41. Caso de Uso: Figura 32.Es una operación o tarea específica que se realiza tras una orden de algún agenteexterno, sea desde una petición de un actor o bien desde la invocación desde otrocaso de uso.Relaciones:Las relaciones se explicaron de manera especifica en el apartado 1.2.4 de estemodulo, ahora se explica de manera sencilla para observar su uso dentro de losdiagramas de casos de uso.• AsociaciónEs el tipo de relación más básica que indica la invocación desde un actor o casode uso a otra operación (caso de uso). Dicha relación se denota con una flechasimple.• Dependencia o InstanciaciónEs una forma muy particular de relación entre clases, en la cual una clasedepende de otra, es decir, se instancia (se crea). Dicha relación se denota con unaflecha punteada. 41
43. 43. Como una primera aproximación identificamos a los actores que interactúan con elsistema: Figura 33.Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puedecambiar la información de un Item o bien puede Imprimir un informe: Figura 34.Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba. Figura 35. 43
44. 44. Otro aspecto es la impresión de comprobantes, que puede ser realizada despuésde depositar algún item por un cliente o bien puede ser realizada a petición de unoperador. Figura 36.Entonces, el diseño completo del diagrama casos de uso es: Figura 37. 44
45. 45. 2.1.3. Diagramas de InteracciónLos diagramas de interacción se utilizan para modelar los aspectos dinámicos deun sistema, lo que conlleva modelar instancias concretas o prototípicas de clasesinterfaces, componentes y nodos, junto con los mensajes enviados entre ellos,todo en el contexto de un escenario que ilustra un comportamiento. En el contextode las clases describen la forma en que grupos de objetos colaboran para proveerun comportamiento.En los diagramas de interacción se muestra un patrón de interacción entre objetos.Hay dos tipos de diagrama de interacción, ambos basados en la mismainformación, pero cada uno enfatizando un aspecto particular: Diagramas deSecuencia y Diagramas de Colaboración.Diagrama de SecuenciaUn diagrama de Secuencia muestra una interacción ordenada según la secuenciatemporal de eventos. En particular, muestra los objetos participantes en lainteracción y los mensajes que intercambian ordenados según su secuencia en eltiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan losobjetos y actores participantes en la interacción, sin un orden prefijado. Cadaobjeto o actor tiene una línea vertical, y los mensajes se representan medianteflechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se puedencolocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.)bien en el margen izquierdo o bien junto a las transiciones o activaciones a las quese refieren. Objetos c : Cliente p : ProxyODBC <<create>> :Transacción establecerAcciones(a,d,o) establecerValores(d,3,4) Tiempo establecerValores(a,”CO”) éxito Línea de vida <<destroy>> Foco de control Figura 38. 45
46. 46. Los diagramas de secuencia tienen 2 características que los distinguen de losdiagramas de colaboración, en primer lugar está la línea de vida de un objeto quees la línea discontinua vertical que representa la existencia de un objeto a lo largode un periodo de tiempo. La mayoría de los objetos que aparecen en un diagramade secuencia existirán mientras dure la interacción, los objetos se colocan en laparte superior del diagrama con sus líneas de vida dibujadas de arriba hastaabajo. Pueden crearse objetos durante la interacción, sus líneas de vidacomienzan con la recepción de mensajes estereotipado como create. Los objetospueden destruirse durante la interacción, sus líneas de vida acaban con larecepción del mensaje estereotipado como destroy, además, se muestra la señalvisual de una gran X que marca el final de sus vidas.Diagrama de ColaboraciónUn diagrama de colaboración destaca la organización de los objetos queparticipan en una interacción, un diagrama de colaboración se construyecolocando en primer lugar los objetos que participan en la colaboración comonodos de un grafo. A continuación se representa los enlaces que conectan esosobjetos como arcos de grafo, por último, estos enlaces se adorna con losmensajes que envían y reciben los objetos, esto da la lector una señal visual claradel flujo de control en el contexto de la organización estructural de los objetos quecolaboran c : Cliente Objeto 1: <<create>> 2: establecerAcciones(a,d,o) enlace 3: <<destroy>> <<local>> mensaje <<global>> :Transacción P : ProxyODBC 2.1:establecerValores(d,3,4) 2.2: establecerValores(a,”Co”) Figura 39.Los diagramas colaboración tienen dos características que los distinguen de losdiagramas de secuencia, el primero para indicar cómo se enlaza un objeto a otro,se puede asociar un objeto al extremo mas lejano de un enlace con la palabralocal que indica que el objeto designado es local al emisor. En segundo lugar estael numero de secuencia, para indicar la ordenación temporal de los mensajes, se 46
49. 49. BifurcacionesUn flujo de control no tiene porqué ser siempre secuencial, puede presentarcaminos alternativos. Para poder representar dichos caminos alternativos obifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá unatransición de entrada y dos o más de salida. En cada transición de salida secolocará una expresión booleana que será evaluada una vez al llegar a labifurcación, las guardas de la bifurcación han de ser excluyentes y contemplartodos los casos ya que de otro modo la ejecución del flujo de control quedaríainterrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabraELSE, para indicar una transición obligada a un determinado estado cuando elresto de guardas han fallado. Veamos un ejemplo de bifurcación.Bifurcación secuencial Figura 42.División y uniónNo sólo existe el flujo secuencial y la bifurcación, también hay algunos casos enlos que se requieren tareas concurrentes. UML representa gráficamente elproceso de división, que representa la concurrencia, y el momento de la unión denuevo al flujo de control secuencial, por una línea horizontal ancha. Podemos vercómo se representa gráficamente.Figura 43. 49
50. 50. CallesCuando se modelan flujos de trabajo de organizaciones, es especialmente útildividir los estados de actividades en grupos, cada grupo tiene un nombre concretoy se denominan calles. Cada calle representa a la parte de la organizaciónresponsable de las actividades que aparecen en esa calle. Gráficamente quedaríacomo se muestra a continuación clientes ventas almacén Solic Producto Procesar Pedido Extraer Pedido Enviar Pedido Recibir Pedido Fact. Cliente Pagar Factura Cerrar Pedido Figura 44. 50