200609

1,082 views
1,033 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,082
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
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
  5. 5. PRIMERA UNIDADINTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO 5
  6. 6. INTRODUCCIONUnas de las etapas vitales para un diseñador de software, es el análisis y diseñode sistemas, el análisis de sistemas es el proceso de clasificación e interpretaciónde hechos, diagnóstico de problemas y manejo de la información para hacermejoras al sistema, siendo el diseño la fase de planificación, reemplazo ocomplementación de un sistema organizacional existen. Para estas fases deldesarrollado de software se han desarrollado diferentes modelos con los cuales sehan obtenido resultados satisfactorios, mas no óptimos puesto que se hansesgado unos con otros.Es entonces cuando se plantea la necesidad de crear un mismo lenguaje quepermita modelar sistemas, de manera que se pueda en cualquier momentoconstruir software partiendo de un solo esquema de modelado, tanto estructuralcomo orientado a objetosEl Lenguaje Unificado de Modelado (Unified Modelin Language UML), es unlenguaje estándar para escribir planos de software, UML se puede utilizarse paravisualizar, especificar, construir y documentar los artefactos de un sistema queinvolucra una gran cantidad de software. UML prescribe un conjunto de notacionesy diagramas estándar para modelar sistemas orientados a objetos, y describe lasemántica esencial de lo que estos diagramas y símbolos significan.UML se puede usar para modelar distintos tipos de sistemas: sistemas desoftware, sistemas de hardware, y organizaciones del mundo real. UML ofrecenueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,que cubre todas las vistas necesarias para desarrollar y luego desplegar talessistemas.El curso académico denominado Lenguaje de Modelado -UML- Electiva, estaorientado a hacia el manejo adecuado de las herramientas que ofrece el lenguajede modelado orientado a objetos, desde la construcción de los diagramas deinteracción del sistema hasta la aplicación del modelo en un caso real dedesarrollo. 6
  7. 7. 1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO1.1. Qué es Uml?El Lenguaje Unificado de Modelado (Unifield Modelin Language UML), es unlenguaje estándar para escribir planos de software, UML se puede utilizarse paravisualizar, especificar, construir y documentar los artefactos de un sistema queinvolucra una gran cantidad de software. UML prescribe un conjunto de notacionesy diagramas estándar para modelar sistemas orientados a objetos, y describe lasemántica esencial de lo que estos diagramas y símbolos significan.UML se puede usar para modelar distintos tipos de sistemas: sistemas desoftware, sistemas de hardware, y organizaciones del mundo real. UML ofrecenueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,que cubre todas las vistas necesarias para desarrollar y luego desplegar talessistemas .UML es sólo un lenguaje y por tanto es tan solo una parte de un método dedesarrollo de software, además, es independiente del proceso, aunque parautilizar óptimamente se debería usar en procesos que fuese dirigido por los casosde uso, centrado en la arquitectura, interactivo e incrementalUML es una consolidación de muchas de las notaciones y conceptos más usadasorientados a objetos. Empezó como una consolidación del trabajo de GradeBooch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologíasorientadas a objetos más populares, en 1996, el Object Management Group(OMG), publicó una petición con propósito de un metamodelo orientado a objetosde semántica y notación estándares. UML, en su versión 1.0, fue propuesto comouna respuesta a esta petición en enero de 1997. Hubo otras cinco propuestasrivales. Durante el transcurso de 1997, los seis promotores de las propuestas,unieron su trabajo y presentaron al OMG un documento revisado de UML, llamadoUML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de1997. El OMG llama a este documento OMG UML versión 1.1. El OMG estabaactualmente en proceso de mejorar una edición técnica de estaespecificación, prevista su finalización para el 1 de abril de 1999. 7
  8. 8. 1.1.2. UML no es un métodoInicialmente los métodos son una técnica para llevar a cabo una acción, Uml es uncompendio de modelos que pueden ser interpretados de forma directa a una granvariedad de lenguajes de programación como Java, C++ o Visual Basic, e inclusoa tablas en una base de datos relacional o una base de datos orientadas a objetosUML se construye con modelos estándar sobre análisis y diseño de sistemasorientados a objetos de las cuales las más populares se incluyen las siguientes:Catálisis: Un método orientado a objetos que fusiona mucho del trabajo recienteen métodos orientados a objetos, y además ofrece técnicas especificas paramodelar componentes distribuidos.Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por IvarJacobson.Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en marchapor Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos,modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando elmundo en Datos (Prentice Hall). Shlaer/Mellor continúan actualizando su métodocontinuamente (la actualización más reciente es el OOA96 report), yrecientemente publicaron una guía sobre como usar la notación UML conShlaer/Mellor.Fusión: Desarrollado en Hewlett Packard a mediados de los noventa como primerintento de un método de diseño orientado a objetos estándar. Combina OMT yBooch con tarjetas CRC y métodos formales.(www.hpl.hp.com/fusion/file/teameps.pdf)OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaughy otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado aObjetos" (Prentice Hall, 1991). Un método que propone análisis y diseñointeractivo, más centrado en el lado del análisis.Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de"Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 8
  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
  22. 22. Diagramas de ComportamientoLos cuales están compuestos por los siguientes diagramasDiagramas de casos de usoEn el modelado orientado a objetos los diagramas de casos de uso son los querepresentan en general el funcionamiento del sistema siendo estos los masutilizados como base del desarrollo de un modelo real, representa casos de uso,actores y relaciones, se utilizan especialmente para organizar y modelar elcomportamiento de un sistema.Diagramas de SecuenciaEs un diagrama de interacción que resalta la ordenación temporal de losmensajes, este presenta un conjunto de objetos y los mensajes enviados por ellos.Los objetos suelen ser instancias con nombre, pueden representar instancias deotros elementos, tales como colaboraciones, componentes y nodos, se utilizanpara describir las vista dinámica de un sistema.Diagramas de colaboraciónEs un diagrama de interacción que resalta la organización estructural de losobjetos que envían y reciben mensajes, pueden representar instancias de otroselementos como colaboraciones, componentes y nodos. Se utilizan para describirla vista dinámica de un sistema.Diagramas de estadoRepresenta una máquina de estados constituida por estados, transacciones,eventos y actividades, se utilizan para representar la vista dinámica de un sistemason especialmente importantes para modelar el comportamiento de una interfaz,clase o una colaboración, resaltan en comportamiento dirigido por eventos de unobjeto.Diagrama de ActividadesMuestra el flujo de actividades en un sistema, muestra el flujo secuencial oramificado de actividades y los objetos en los que actúa, son importantes para 22
  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
  28. 28. • Subsistema: agrupación de elementos, algunos de los cuales constituyen una especificación del comportamiento de los otros elementos contenidos <<subsystem>> subsistema de servicio al cliente Figura 19.Los clasificadores descritos anteriormente proporcionan al modelado de sistemasuna vista general de comportamiento del sistema mostrándolo en detalle en susatributos y operacionesGeneralidades de las clasesEs necesario saber que para el modelado de sistemas con Uml, las clasesmuestran en la definición de sus atributos ciertos tipos de símbolos, los cualesdeterminan si los elementos asociados a cada clase son públicos o privados porejemplo:Si la marca de elemento es un +, indica que este elemento es de acceso público ypor lo tanto se pueden operar desde cualquier instancia del sistema. Por locontrario si el signo es -, indica que este elemento solo es de uso exclusivo de laclase que lo contiene. Otro caso en los cuales los elementos de la clase son pordecirlo de alguna semi privados, solo se relacionan con las clases que han sidodescendientes de la clase padre se marcan con el símbolo #.Cuando se usa una clase, es probable que se desee características de otrasclases y también permitir que otras clases más específicas hereden característicasde ella. También se puede especificar que una clase no puede tener hijos, a esteelemento se le llama hoja y se especifica escribiendo la propiedad leaf bajo elnombre de la clase. Otra característica de las clases es cuando esta no tienepadres, este tipo de clases se denomina raíz y se denota escribiendo debajo delnombre de la clase root.Podemos observar el siguiente ejemplo de notación: 28
  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
  36. 36. Las instancias no aparecen aisladas, casi siempre están ligadas a unaabstracción. La mayoría de las instancias que se modelan en UML seráninstancias de clases (llamadas objetos), aunque se pueden tener instancias deotros elementos, como componentes, nodos, casos de usos y asociaciones.En sentido general, un objeto es algo que ocupa espacio en el mundo real oconceptual y al que se le pueden hacer cosas. Por ejemplo, una instancia de unnodo es normalmente un computador que se encuentra físicamente en unahabitación; una instancia de un componente ocupa algo de espacio en el sistemade archivos; una instancia de un registro de un cliente consume algo de memoriafísica, análogamente, una instancia de un billete de avión es algo sobre lo que sepueden hacer cálculos.1.2.10. Herencia y polimorfismoPolimorfismoUna de las características fundamentales de la OOP es el polimorfísmo, que no esotra cosa que la posibilidad de construir varios métodos con el mismo nombre,pero con relación a la clase a la que pertenece cada uno, con comportamientosdiferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos declases diferentes. Estos objetos recibirían el mismo mensaje global peroresponderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objetoENTERO significaría suma, mientras que para un objeto STRING significaríaconcatenación ("pegar" strings uno seguido al otro)HerenciaEn programación orientada a objetos, la herencia es un mecanismo que haceposible que una clase herede todo el comportamiento y atributos de otra clase; através de la herencia, una clase tiene inmediatamente toda la funcionalidad de unaclase existente, debido a esto, las nuevas clases se pueden crear indicandoúnicamente en que se diferencian de la clase existente, es decir, que toma ladefinición previa de la cual es subclase, y que solo se le agrega característicasespeciales que la difieren de la clase de la cual procede. La relación de herenciase representa mediante un triángulo en el extremo de la relación que correspondea la clase más general o clase “padre”. 36
  37. 37. SEGUNDA UNIDADCARACTERISTICAS DEL MODELADO UML 37
  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
  42. 42. GeneralizaciónEste tipo de relación es uno de los más utilizados, cumple una doble funcióndependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia(<<extends>>).Este tipo de relación esta orientado exclusivamente para casos de uso (y no paraactores).extends: Se recomienda utilizar cuando un caso de uso es similar a otro(características).uses: Se recomienda utilizar cuando se tiene un conjunto de características queson similares en más de un caso de uso y no se desea mantener copiada ladescripción de la característica.De lo anterior cabe mencionar que tiene el mismo paradigma en diseño ymodelamiento de clases, en donde esta la duda clásica de usar o heredar.Ejemplo:Como ejemplo esta el caso de una Máquina Recicladora:Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. Elsistema debe controlar y/o aceptar lo siguiente: • Registrar el número de ítemes ingresados. • Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total • El usuario/cliente presiona el botón de comienzo • Existe un operador que desea saber lo siguiente: a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día. • El operador debe además poder cambiar: a. Información asociada a ítemes. b. Dar una alarma en el caso de que: • Item se atora. • No hay más papel. 42
  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
  47. 47. precede de un numero iniciando con el numeral 1, que se incrementasecuencialmente por cada nuevo mensaje en el flujo de control2.1.4. Diagramas de ActividadesUn diagrama de actividades muestra el flujo de actividades, siendo un actividaduna ejecución general entre los objetos que se esta ejecutando en un momentodado dentro de una máquina de estados, el resultado de un actividad es unaacción que producen un cambio en el estado del sistema o la devolución de unvalor. Las acciones incluyen llamadas a otras operaciones, envío de señales,creación o destrucción de objetos o simples cálculos. Gráficamente un diagramade actividades será un conjunto de arcos y nodos. Desde un punto de vistaconceptual, el diagrama de actividades muestra cómo fluye el control de unasclases a otras con la finalidad de culminar con un flujo de control total que secorresponde con la consecución de un proceso más complejo. Por este motivo, enun diagrama de actividades aparecerán acciones y actividades correspondientes adistintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo:Hacer un pedido.Contenido del diagrama de actividadesBásicamente un diagrama de actividades contiene:• Estados de actividad• Estados de acción• Transiciones• ObjetosEstados de actividad y estados de acciónLa representación de ambos es un rectángulo con las puntas redondeadas, encuyo interior se representa bien una actividad o bien una acción. La forma deexpresar tanto una actividad como una acción, no queda impuesta por UML, sepodría utilizar lenguaje natural, una especificación formal de expresiones, unmetalenguaje, etc. La idea central es la siguiente: “Un estado que represente unaacción es atómico, lo que significa que su ejecución se puede considerarinstantánea y no puede ser interrumpida” En la siguiente figura, podemos verejemplos de estados de acción. 47
  48. 48. Figura 40.En cambio un estado de actividad, sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Ademásestos estados sí pueden ser interrumpidos y tardan un cierto tiempo encompletarse. En los estados de actividad podemos encontrar otros elementosadicionales como son: acciones de entrada (entry) y de salida (exit) del estado encuestión, así como definición de submáquinas, como podemos ver en la figurasiguiente ProcesarFactura(Fact) Entry / SacarPrimeraFactura(Fact) Figura 41.TransicionesLas transiciones reflejan el paso de un estado a otro, bien sea de actividad o deacción. Esta transición se produce como resultado de la finalización del estado delque parte el arco dirigido que marca la transición. Como todo flujo de control debeempezar y terminar en algún momento, podemos indicar esto utilizando dosdisparadores de inicio y fin tal y como queda reflejado en el ejemplo siguienteFigura 41. Estado de Acción 48
  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
  51. 51. 2.2. Modelado dinámico2.2.1 Eventos y señalesUn evento es la especificación de un acontecimiento significativo que ocupa unlugar en el tiempo y en el espacio. En el contexto de la máquinas de estado, unevento es la aparición de un estímulo que puede disparar una transición deestado. Un señal es un tipo de evento que representa la especificación de unestímulo asíncrono que es transmitido entre instancias.SeñalesUna señal representa un objeto con nombre que es enviado (lanzado)asíncronamente por un objeto y recibido(capturado) por otro. El tipo más comúnde señal interna que se presenta dentro de los lenguajes de programación son lasexcepciones.Una señal puede enviarse como la acción de una transición de estado en unamáquina de estados, o como el envío de un mensaje en una interacción.. En UML,la relación entre una operación y los eventos que puede enviar se modela conrealcion de dependencia, estereotipada como send.Las señales y las excepciones se modelan como clases estereotipadas, se puedeutilizar una dependencia, estereotipada como send para indicar que la operaciónenvía una señal particular. Señal AgenteDeMovimiento Posición Velocidad <<signal>> <<send>> colisión moverA() fuerza : Float parámetros Figura 44. 51
  52. 52. EventosUn evento de llamada representa una invocación de una operación, un eventopuede disparar una transición de estado de una máquina de estados. Cuando unobjeto invoca una operación sobre otro objeto que tiene una máquina de estados,el control pasa del emisor al receptor, el evento dispara la transición, la operaciónacaba, el receptor pasa a un nuevo estado y el control regresa al emisor.Gráficamente se muestra al evento con sus parámetros, como el disparador deuna transición de estado. evento iniciarpilotoAutomático(normal) Manual Automático parámetro Figura 45.Un evento de tiempo es un evento que representa el paso del tiempo, en UML semodela un evento de tiempo con la palabra alter seguida de alguna expresión quese evalúa para producir algún periodo de tiempo.Un evento de cambio es un evento que representa un cambio en el estado o ecumplimiento de alguna condición, se modela con la palabra when seguida dealguna expresión booleana. when (11:49 PM) /AutoTest() alter (2 Segundos) Inactivo /cortarConexión() Activo Evento de cambio Evento de tiempo Figura 46. 52
  53. 53. 2.3.2 Máquinas de EstadoUna máquina de estados es un comportamiento que especifica las secuencias deestados por las que pasa un objeto a lo largo de su vida en respuesta a eventos.Un Estado es una condición o situación en la vida de un objeto durante la cualsatisface alguna condición, realiza una actividad o espera algún evento. Un eventoes la especificación de un aconecimietno significativo que ocupa un lugar en eltiempo y el espacio, es la estimulación que puede disparar una transición deestadosUn transición es una relación entre dos estados que indica que un objeto que estéen el primer estado realizará ciertas acciones y entrará el segundo estado cuandoocurra un evento específico y se satisfagan unas condiciones específicas y unaactividad es una ejecución no atómica en curso, dentro de una máquina deestados.EstadosUn estado es una condcion o situación enla vida de un objeto durante la cualsatisface alguna condición, realiza una actividad o espera un evento. Un objetopuede estar en cualquier estado durante una cantidad de tiempo determinado, porejemplo un calentador de agua puede estar en cualquiera de los cuatro estados:inactivo, en preparación (esperando alcanzar la temperatura adecuada),activo(cuando el calentador alcanza la temperatura ideal para calentar el agua), ypagado. Un estado tiene varias partes, nombre, acciones de entrada salida,transiciones internas, subastados y eventos diferidos. Como se muestra acontinuación un estado se representa con un rectángulo con las esquinasredondeadas. apagar Estado final Estado inicial Inactivo teclaPulsada Funcionando Terminado nombre nombreFigura 47. estado 53
  54. 54. Como se observa en la grafica anterior en la máquina de estados de un objeto sepueden definir dos estados especiales, en primer lugar e punto inicial que indica elpuno de comienzo por defecto para la máquina de estados o el subestado. Ensegundo lugar, el estado final, que indica la ejecución de la máquina de estado odel estado que lo contiene ha finalizadoTransicionesUna transición es una relación entre dos estados que indica que un objeto queesté en el primer lugar estado realizará ciertas acciones y entrará en el segundoestado cuando ocurra un evento específico y se satisfagan unas condicionesespecíficas, cuando se produce este cambio de estado, se dice que la transiciónse ha disparado, hasta que se dispara la transición se dice que el objeto está enel estado origen, después de dispararse se dice que esta en el estado destino. Evento de tiempo Envío de señal Evento de disparo Transición sin disparador alter (2 Segundos) /send c.estaActivo autotransición ruido Inactivo Inactivo Inactivo objetoEn(p)[representaAmenaza]/ t.añadirObjeto(p) contactar Inactivo Inactivo Evento de disparo con parámetros acción condicion de gurda Figura 48.Una transición tiene cinco partes, estado origen, evento disparado, condición deguarda, acción y estado de destino; una transición se representa con una líneacontinua dirigida desde el estado origen hacia el destino y una autotransición esuna transición cuyos estados origen y destino son los mimos 54
  55. 55. 2.4.3 Tiempo y EspacioUna marca de tiempo denota el instante en el que ocurre un evento, gráficamente,una marca de tiempo es una expresión obtenida a partir del nombre dado almensaje; una expresión de tiempo es una expresión que al evaluarse genera unvalor de tiempo absoluto o relativo. Una restricción de tiempo se representa comocualquiera otra restricción, es decir, una cadena de texto entre llaves ynormalmente conectada a un electo mediante una relación de dependencia. Lalocalización es la asignación de un componente de un nodo. Gráficamente, lalocalización se representa como un valor etiquetado, es decir, una cadena de textoentra llaves colocada debajo del nombre del elemento, o mediante la inclusión decomponentes dentro de nodos. Restricción de tiempo {cada 1ms} c1 : notasDePrueva c : ControladorMIDI : ColecciónDeNotas Restricción de tiempo {executeTime <10 ms} c2 : notasDePrueba() n: Nota c3 : a ñadir(k) b: BufferDeEventosMIDI t : TransmisionMIDIFigura 49. t1 : quitar() {cada 1 ms} Restricción de tiempoEn el gráfico anterior se observa la manera como se representa el tiempo y elsiguiente gráfico se muestra la localizaciónFigura 50. Localización por inclusión 55 t : TransmisionMIDI Valor etiquetado de localización {location=Enrutador}
  56. 56. 2.4.4 Diagramas de EstadoEs un tipo especial de diagrama y comparte las propiedades comunes al resto delos diagramas, lo que distingue a un diagrama de estados de los otros tipos dediagramas es su contenido, normalmente los diagramas de estados contienen:• Estados simples y compuestos• Transiciones, incluyendo eventos y accionesObservemos un diagrama de estados a continuación con todos sus componentes Estado inicial sonando Inactivo cabeceraOK Transición sin Conectando Procesando disparadorenviarFax colgar verificaciónOK evento evento entry/descolgar Transmisión Limpiando error/imprimirError exit/desconectar estado acción acción Estado compuesto Figura 51. 56
  57. 57. 2.3. Modelado Arquitectónico2.3.1. Componentes, despliegue, colaboraciones y patronesComponentesUn componente es una parte física y reemplazable de un sistema que conformaun conjunto de interfaces. Gráficamente, un componente se representa como unrectángulo con pestañas, un componente debe tener un nombre que lo distinga delresto de componentes. El nombre de un componente puede ser simple o decamino que consta del nombre del componente precedido del nombre del paqueteen el que se encuentra, usualmente un componente se dibuja solamente con sunombre pero se pueden adornar con valores, etiquetas o con algúncomportamiento que indique sus detalles. Como se muestra en la siguiente figura Agentefraudes.dll Componente con nombre simple agenteFraudes PoliticaFraudes BusquedaDePatrones clases Figura 52. Interfaz Imagen.java Imagen.java ObservadorDeImagen Figura 53. Relación de dependencia realización 57
  58. 58. DespliegueUn nodo es un elemento físico que existe en tiempo de ejecución y representa unrecurso computacional que generalmente tiene alguna memoria y a menudocapacidad de procesamiento, gráficamente un nodo se representa como un cubo. .El nombre de un componente puede ser simple o de camino que consta delnombre del componente precedido del nombre del paquete en el que seencuentra, usualmente un nodo se dibuja solamente con su nombre pero sepueden adornar con valores, etiquetas o con algún comportamiento que indiquesus detalles. Como se muestra en la siguiente figura nodo con nombre simple ventas pos.exe Contactos.exe componentes Figura 54.ColaboracionesUna colaboración es una sociedad de clases, interfaces y otros elementos quecolaboran para proporcionar un comportamiento cooperativo mayor que la sumade los comportamientos de sus elementos. Una colaboración es también laespecificación de cómo un elemento tal como un clasificador o un operación, esrealizado mediante un conjunto de clasificadores y asociaciones que juegan rolesespecíficos utilizados de una forma específica, gráficamente, una colaboración serepresenta como una elipse con borde discontinua. El nombre de una colaboraciónpuede ser simple o de camino que consta del nombre de la colaboraciónprecedido del nombre del paquete en el que se encuentra, usualmente un nodo sedibuja solamente con su nombre pero se pueden adornar con valores, etiquetas ocon algún comportamiento que indique sus detalles. Como se muestra en la 58
  59. 59. siguiente figura Nombre Paso de mensajes entre nodos Figura 55.PatronesUn patrón es una solución común a un problema común en un contexto dado. Lospatrones ayudan a visualizar, especificar, construir y documentar los artefactos deun sistema con gran cantidad de software. Hay dos tipos de patrones, patrones dediseño(Mecanismos) y frameworks.MecanismosUn mecanismo simplemente muestra un conjunto de abstracciones que colaboranentre si par llevar a cabo algún comportamiento común, estos mecanismo semuestran como colaboraciones simples, ya que solamente dan el nombre a unasociedad de clases. frameworks <<framework>> recepción de pedidos facturación comprobaciónFigura 56. mecanismos 59
  60. 60. Los mecanismos pueden nombrar una plantilla formada por un conjunto de deabstracciones que colaboran entre sí para llevar a cabo algún comportamientocomún, se representan como colaboraciones parametrizadas que se muestran deforma parecida a las clases plantilla, observe la siguiente figura rol platilla ColaTares Sujeto Sujeto Observador ligadura Observador BarraDesplazamiento Observador colaboraciones rol Figura 57.FrameworksUn frameworks es un patrón arquitectónico que proporciona una plantillaextensible para aplicaciones dentro de un dominio.La siguiente figura ilustra un frameworks, llamado AdministradorCiclo entre otrascosas, este frameworks incluye una colaboración EventosComunes que contieneun conjunto de clases evento, junto con un mecanismo GestorDeEventos paraprocesar estos eventos de forma cíclica. Un cliente que utilice este frameworks talcomo un Marcapasos podría construir sobre las abtracciones en EventosComunescreando subclases y también podría emplear una instancia del mecanismoGestorDeEventos 60
  61. 61. frameworks ligaduras Pacificador <<frameworks>> AdministradorCiclico Cliente Gestor GestorDeEvento s EventosComunes colaboraciones Figura 58.2.3.2. Diagramas de ComponentesLo que distingue a un diagrama de componentes de otros tipos de diagramas essu contenido. Normalmente contienen componentes, interfaces y relaciones entreellos. Y como todos los diagramas, también puede contener paquetes utilizadospara agrupar elementos del modelo.Un diagrama de componentes muestra las organizaciones y dependencias lógicasentre componentes software, sean éstos componentes de código fuente, binarioso ejecutables. Desde el punto de vista del diagrama de componentes se tienen enconsideración los requisitos relacionados con la facilidad de desarrollo, la gestióndel software, la reutilización, y las restricciones impuestas por los lenguajes deprogramación y las herramientas utilizadas en el desarrollo. Los elementos demodelado dentro de un diagrama de componentes serán componentes ypaquetes.Dado que los diagramas de componentes muestran los componentes software queconstituyen una parte reusable, sus interfaces, y su interrelaciones, en muchosaspectos se puede considerar que un diagrama de componentes es un diagrama 61
  62. 62. de clases a gran escala. Cada componente en el diagrama debe ser documentadocon un diagrama de componentes más detallado, un diagrama de clases, o undiagrama de casos de uso.Un paquete en un diagrama de componentes representa un división física delsistema. Los paquetes se organizan en una jerarquía de capas donde cada capatiene una interfaz bien definida. Un ejemplo típico de una jerarquía en capas deeste tipo es: Interfaz de usuario; Paquetes específicos de la aplicación; Paquetesreusables; Mecanismos claves; y Paquetes hardware y del sistema operativo.Un diagrama de componentes se representa como un grafo de componentessoftware unidos por medio de relaciones de dependencia (generalmente decompilación). Puede mostrar también que un componente software contiene unainterfaz, es decir, la soporta. Un ejemplo se muestra a continuación find.html página find.exe nateng.dll componente biblioteca Figura 60.2.3.3. Diagramas de DespliegueCuando se trata de hardware y el software del sistema, se utiliza los diagramas dedespliegue para razonar sobre la tipología de procesadores y dispositivos sobrelos que reejecuta el software. Los diagramas de despliegue se utilizan paravisualizar los aspectos estáticos de estos nodo físicos y sus relaciones y paraespecificar sus detalles para la construcción, como se muestra a continuación 62

×