Este documento introduce el lenguaje UML (Unified Modeling Language) para modelado orientado a objetos. Explica los conceptos básicos de modelos de desarrollo de software, análisis y diseño orientados a objetos, y procesos de análisis y diseño preliminar y detallado. Además, describe los diferentes tipos de diagramas que provee UML para modelar diferentes aspectos de un sistema, como el comportamiento, estructura y dinámica.
0 calificaciones0% encontró este documento útil (0 votos)
78 vistas109 páginas
Este documento introduce el lenguaje UML (Unified Modeling Language) para modelado orientado a objetos. Explica los conceptos básicos de modelos de desarrollo de software, análisis y diseño orientados a objetos, y procesos de análisis y diseño preliminar y detallado. Además, describe los diferentes tipos de diagramas que provee UML para modelar diferentes aspectos de un sistema, como el comportamiento, estructura y dinámica.
Este documento introduce el lenguaje UML (Unified Modeling Language) para modelado orientado a objetos. Explica los conceptos básicos de modelos de desarrollo de software, análisis y diseño orientados a objetos, y procesos de análisis y diseño preliminar y detallado. Además, describe los diferentes tipos de diagramas que provee UML para modelar diferentes aspectos de un sistema, como el comportamiento, estructura y dinámica.
Este documento introduce el lenguaje UML (Unified Modeling Language) para modelado orientado a objetos. Explica los conceptos básicos de modelos de desarrollo de software, análisis y diseño orientados a objetos, y procesos de análisis y diseño preliminar y detallado. Además, describe los diferentes tipos de diagramas que provee UML para modelar diferentes aspectos de un sistema, como el comportamiento, estructura y dinámica.
Descargue como PDF, TXT o lea en línea desde Scribd
Descargar como pdf o txt
Está en la página 1de 109
Introduccin a UML
Lenguaje para modelar objetos
Juan Manuel Cueva Lovelle Catedrtico de E.U. de Lenguajes y Sistemas Informticos Departamento de Informtica Universidad de Oviedo (Espaa) Octubre 1999 Tabla de contenidos 1. Modelos de desarrollo de software 2. Anlisis y diseo Orientado a Objetos 3. Proceso de Anlisis y Diseo preliminar 4. Proceso de Diseo detallado 5. Qu es UML? 6. Documentos de Anlisis 7. Especificacin de Requisitos 8. Casos de Uso 9. Escenarios 10. Diagramas de Secuencia 11. Diagramas de Colaboracin 12. Diagramas Estticos 13. Diagramas de Actividad 14. Diagramas de Estados 15. Diagramas de Implementacin Bibliografa [Bock/Odell 94] C. Bock and J. Odell, A Foundation For Composition, Journal of Object-oriented Programming, October 1994. [Booch 94] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings (1994). Versin castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de Santos (1996). [Booch 99] G.Booch., J. Rumbaugh, I. Jacobson The unified modeling language. User guide. Addison-Wesley (1999). Versin castellana: El lenguaje Unificado de Modelado.Addison-Wesley (1999). [Cook 94] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice-Hall Object-Oriented Series, 1994. [Eriksson 98] H-E Eriksson & M. Penker. UML Toolkit. Wiley, 1998. [Fowler 97] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, ISBN 0-201-32563-2, Addison-Wesely, 1997. [Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented Software Enginneering. A use Case Driven Approach., ISBN 0-201-54435-0, Addison-Wesely, 1992. [Lee 97] R. C.Lee & W. M. Tepfenhart. UML and C++, Prentice-Hall, 1997 [Rumbaught 91] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented modeling and design. Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos. Metodologa OMT. Prentice-Hall (1996) [UML] UML Notation Guide, Version 1.1, Sep-97, www.rational.com/uml Juan Manuel Cueva Lovelle 6-1 Mtodo y metodologas Un mtodo es un proceso disciplinado para generar un conjunto de modelos que describen varios aspectos de un sistema de software en desarrollo, utilizando alguna notacin bien definida Una metodologa es una coleccin de mtodos aplicados a lo largo del ciclo de vida del desarrollo de software y unificados por alguna aproximacin general o filosfica La mayor parte de las metodologas puede catalogarse en uno de los grupos siguientes: Diseo estructurado descendente Yourdon y Constantine Wirth Dahl, Dijkstra y Hoare Diseo dirigido por datos Jackson Warnier y Orr Diseo orientado a objetos son las que siguen el modelo de objetos Booch OMT (Rumbaugh et al.) Objectory (Jacobson et al.) Schlaer-Mellor Coad/Yourdon Fusion (Coleman et al.) Juan Manuel Cueva Lovelle 6-2 Notacin Una notacin es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (anlisis) y los detalles de una arquitectura (diseo) de forma no ambigua La accin de dibujar un diagrama no constituye ni anlisis ni diseo Una notacin no es un fin por si misma El hecho de que una notacin sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasiones La notacin son como los planos para un arquitecto o un ingeniero Una notacin no es ms que un vehculo para capturar los razonamientos acerca del comportamiento y la arquitectura de un sistema Las notaciones deben ser lo ms independientes posibles de los lenguajes de programacin, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notacin y los lenguajes de programacin El propsito de este tema es describir la sintaxis y semntica de la notacin que se utiliza para el anlisis y diseo orientado a objetos Juan Manuel Cueva Lovelle 6-3 Modelos, metamodelos y herramientas Un metamodelo es la descripcin de un modelo Un modelo es el resultado del anlisis y diseo Una herramienta es el soporte automtico de una notacin Metamodelo Notacin Herramientas Juan Manuel Cueva Lovelle 6-4 Comparacin de metodologas Con el paso del tiempo las metodologas de anlisis y diseo orientado a objetos han ido convergiendo en Conceptos de modelado similares Procesos similares Las principales diferencias estn en la notacin Diferentes iconos para la representacin de los artefactos del diseo Diferentes diagramas para expresar las relaciones entre clases y objetos La experiencia indicar que es lo que se debe utilizar y lo que se debe dejar de lado 5-1 Juan Manuel Cueva Lovelle Desarrollo de software Modelo en cascada Requisitos Anlisis Diseo preliminar y detallado Implementacin & prueba unitaria Integracin Mantenimiento 5-2 Juan Manuel Cueva Lovelle Desarrollo de software Modelo en espiral Esfuerzo Tiempo Anlisis Diseo Implementacin Prueba 5-3 Juan Manuel Cueva Lovelle Anlisis y diseo orientado a objetos Implementacin Requisitos 5-4 Juan Manuel Cueva Lovelle Anlisis Orientado a Objetos Preguntas que se deben plantear Cul es el comportamiento que se desea en el sistema? Qu objetos existen en el sistema? Cules son las misiones de los objetos para llevar a cabo el comportamiento deseado del sistema? Diseo Orientado a Objetos Preguntas que se deben plantear Modelo lgico Qu clases existen y como se relacionan estas clases? Qu mecanismos se utilizan para regular la forma en que los objetos colaboran? Modelo fsico Dnde debera declararse y construirse cada clase y objeto? A qu procesador debera asignarse un proceso, y para un procesador dado, cmo deberan planificarse sus mltiples procesos? Juan Manuel Cueva Lovelle 6-5 El modelo del desarrollo orientado a objetos Se definen distintas dimensiones del modelo El modelo esttico describe la estructura esttica del sistema El modelo lgico define la arquitectura del sistema desde el punto de vista de las abstracciones principales y mecanismos Diagramas de clases Diagramas de objetos El modelo fsico define la arquitectura del sistema desde el punto de vista de la composicin concreta hardware y software Diagrama de mdulos Diagrama de procesos Modelo dinmico describe la evolucin dinmica y las interacciones entre objetos Diagramas de transicin de estados Diagramas de interaccin o de seguimiento de sucesos OMT aade el modelo funcional (eliminado posteriormente) Diagrama de flujo de datos Por cada dimensin se define una serie de diagramas que denotan una vista de los modelos del sistema Cuando el modelo es estable cada uno de los diagramas permanece semnticamente consistente con el resto de los diagramas 5-5 Juan Manuel Cueva Lovelle Proceso de Anlisis y Diseo Preliminar Aunque el proceso es iterativo los pasos fundamentales son los siguientes: 1. Ttulo de la aplicacin El ttulo de una aplicacin debe reflejar de la mejor forma posible sus fines y su funcionalidad 2. Documentos de anlisis Son la documentacin que aporta el cliente que encarga la aplicacin Tambin es la documentacin elaborada de forma informal en reuniones de trabajo para entender las solicitudes del cliente 3. Especificacin de Requisitos o Requerimientos Es la especificacin ms tcnica y elaborada de los documentos de anlisis Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de construccin del software 4. Diagramas de Casos de Uso Es un diagrama que muestra sistemas, casos de uso y actores Es una documentacin que describe cada caso de uso, cada sistema y cada actor Es importante codificar cada caso de uso Los casos de uso slo muestran aspectos muy generales 5. Escenarios y sub-escenarios A cada caso de uso le corresponden varios escenarios donde se pueden mostrar los detalles Cada escenario puede dividirse en sub-escenarios para bajar ms el nivel de detalle Los escenarios se codifican siguiendo los valores de los casos de uso 6. Diagramas de Secuencia Se corresponden con los escenarios y sub-escenarios pero con mucho ms detalle Siguen la misma codificacin que los escenarios y sub-escenarios Algunos diagramas de secuencia pueden refinarse ms en la fase de diseo detallado 7. Diccionario de datos Contiene todas las clases Se pueden ir definiendo los miembros de las clases (datos y mtodos) Se ir refinando paso a paso en cada iteracin Las herramientas lo van construyendo automticamente Tambin se pueden utilizar fichas CRC para obtener el diccionario de datos 5-6 Juan Manuel Cueva Lovelle Proceso de Diseo Detallado Es continuacin del anlisis y diseo preliminar, pero como es un proceso iterativo en muchos casos ser necesario volver al anlisis y diseo preliminar 8. Diagramas de Colaboracin 9. Diagramas Estticos 10. Diagramas de Actividad 11. Diagramas de Estados 12. Diagramas de implementacin DOO AOO POO Especificaciones del dominio del problema a resolver Caractersticas de los lenguajes, marcos de aplicacin y entornos de desarrollo Metodologas de descomposicin en objetos y notaciones para expresar los modelos lgico y fsico En algunos casos en el diseo preliminar es necesario hacer algunos diagramas del diseo detallado pero de forma sencilla El diseo preliminar puede ser interesante para poder dar una idea de los costes y de los tiempos de desarrollo de una aplicacin 5-7 Juan Manuel Cueva Lovelle UML es el sucesor de la ola de mtodos de A y DOO que aparecieron a finales de los 80 y principios de los 90 UML unifica principalmente los mtodos de Booch, Rumbaught (OMT) y Jacobson. Pero pretende dar una visin ms amplia de los mismos UML est en proceso de estandarizacin por el OMG (Object Management Group) [OMG] UML es un lenguaje de modelado, no un mtodo. Un mtodo incluye Lenguaje de modelado: Es la notacin (en su mayora grfica) que utilizan los mtodos para expresar los diseos. Proceso: Son los pasos que se aconsejan dar para realizar un diseo Booch 91 Booch 93 Unified Method 0.8 UML 1.0 OMT - 2 OMT - 1 OOSE UML 0.9 & 0.91 OOPSLA 95 Junio 96 & Oct 96 Publicacin de UML 1.1 Septiembre 97 Otros mtodos realimentacin pblica Publicacin de UML 1.0, Enero 97 Compaeros UML Expertos Industrializacin Estandarizacin Unificacin Fragmentacin UML 1.1 Unified Modeling Language (UML) [UML] 5-8 Juan Manuel Cueva Lovelle Ejemplo de ttulo TRASGU: Gestin de hardware y software Consta de nombre propio Breve descripcin de la aplicacin Ejemplo de Documento de Anlisis Se debe realizar un sistema capaz de mantener una base de datos con todos los equipos hardware y software de una empresa, de manera que se pueda obtener informacin acerca del nmero de licencias instaladas y de los equipos en los que estn instaladas dichas licencias. Adems debe ser posible controlar el hardware, las modificaciones efectuadas en los equipos, las averas de dichos equipos, la composicin de cada uno de los ordenadores y el software que est instalado en ellos. Por otro lado cada equipo y cada software que posee la empresa tiene asociados una serie de manuales de los que es necesario seguir la pista, pudiendo, en cada momento, saber qu manuales tiene cada equipo y tambin cada programa. Por tanto existen tres elementos importantes implicados en el sistema: 1. El software. 2. El hardware. 3. Los manuales. Es necesario seguirles la pista a estos tres elementos y saber en todo momento las relaciones entre ellos para poder localizar, mediante el ordenador el manual de un componente instalado en un ordenador. Para el Software es necesario saber el nombre del producto, la versin, la marca o casa que lo fabrica, la fecha de compra, el precio de compra, el proveedor, el soporte (disquetes, CD-ROM, etc.), el nmero de elementos del soporte, la localizacin fsica del soporte, el nmero de instalaciones, los equipos en los que est instalado, el nmero de licencias adquiridas, los manuales que acompaan el producto y la localizacin fsica de dichos manuales. Las localizaciones fsicas pueden ser sustituidas por los cdigos si se codifican tanto los soportes fsicos como los manuales. El sistema debe ser capaz de contestar a las preguntas: 1. Licencias existentes, en uso y necesarias (si procede) de cada una de las aplicaciones que se estn usando en la empresa. 2. Ordenador u ordenadores (si hay varios) en que reside una aplicacin. 3. Composicin del paquete original (disquetes, CD-ROM, etc. y manuales). 4. Proveedor que sirvi el programa, fecha y precio de adquisicin. Un detalle importante a tener en cuenta es que existe la posibilidad de que exista software llave-en-mano, y en este caso adems hay que saber si se dispone o no de los cdigos fuente, la casa que lo desarroll, quin posee los derechos de copia, el precio, el tiempo de desarrollo y el nombre de la persona responsable del proyecto. Los software se quedan obsoletos y, por tanto, es necesario actualizarlos. Se debe tener en cuenta que es necesario que el sistema ofrezca una resea histrica del producto (versiones anteriores) y por tanto es necesario saber el estado de cada uno de ellos (activo, actualizado, desechado, en preparacin, pedido, etc.) En el caso de los antivirus y otros programas similares, es necesario obtener regularmente una adaptacin, por lo que es importante que el sistema nos avise de la inminencia de la caducidad de dichos sistemas. 5-9 Juan Manuel Cueva Lovelle Ejemplo de Documento de Anlisis (continuacin ...) De cada ordenador se necesita saber su composicin (monitor, teclado, ratn y unidad central). De esta ltima es necesario saber su composicin (VGA, disco duro, disquete, placa madre, procesador(es), memoria RAM, memoria cach, etc.). Cada uno de los cuatro componentes principales estar codificado adecuadamente para permitir el intercambio de dichos equipos entre los diferentes puestos de ordenador, de manera que la asociacin no sea fija. De ellos es necesario saber (cuando exista) la marca, el modelo, el nmero de serie, y otras caractersticas particulares (por ejemplo, del monitor la resolucin, si es o no Energy, etc.) Adems de ordenadores existen otros equipos: impresoras, plotters, scaners y unidades de almacenamiento (ZIP, CD y Magneto-pticos) de los cuales es necesario saber, al menos, la marca, el modelo, el nmero de serie y una breve descripcin de sus caractersticas. De cada uno de los equipos es necesario tener un resea histrica de sus averas y cambios, as como una estimacin de su precio (en funcin del precio de compra de cada uno de sus componentes). En el caso de los ordenadores es necesario saber el software que tienen instalado (comenzando por el sistema operativo) y debe ser posible seguir la pista de los manuales de cada una de sus partes componentes. De los manuales slo es necesario controlar su cdigo, su ISBN (si lo posee), su precio (si es aparte del paquete) y su ttulo. Pero es imprescindible poder obtener informacin del software y hardware que est relacionado con ellos. Los manuales deben de ser actualizados segn se vaya cambiando el software y el hardware . El programa debe ser capaz de gestionar el sistema desde diferentes puntos de vista: responsable de informtica, mantenimiento y usuario. El responsable de informtica es el encargado de comprar todos los componentes (equipos, software y manuales). Adems da estos equipos de alta y debe poder apoyarse en el sistema para gestionar los pedidos. Para esta ltima labor debe poder anotar en el sistema que ha pedido un componente a un proveedor (por tanto que est pendiente de recibir), confirmando en la recepcin este pedido, adems tendr la capacidad de poder anular un pedido o si se da el caso anularlo 5-10 Juan Manuel Cueva Lovelle Ejemplo de Documento de Anlisis (continuacin ...) Adems debe poder obtener informes de inventario de los equipos tasados por el precio de compra menos una amortizacin del 25% anual (que dejara al equipo sin valor pasados cuatro aos) para los procesadores y del 10% anual para el resto de los equipos. Adems debe poder obtener informe de la composicin de cada equipo, del estado de disponibilidad de cada uno de ellos y de el estado con respecto a la garanta del equipo. El responsable de informtica es la nica persona que puede dar de alta, modificar y dar de baja los equipos. La baja de un equipo se dar en el momento en que se avise de la avera y si el equipo no tiene arreglo lo daremos de baja permanente. Adems debe poder obtener toda la informacin que tienen el resto de los usuarios del sistema (responsable de mantenimiento y usuarios), y tendr acceso a un buzn de sugerencias sobre el sistema. El responsable de informtica se encarga adems de reservar un equipo cuando se solicita por cualquier usuario, para ello tiene que obtener los informes de disponibilidad y composicin de equipos. El responsable de mantenimiento debe poder anotar en todo momento las averas de cada equipo (fecha, hora de comienzo, hora de fin, nombre del mecnico y descripcin). Debe poder anotar que un equipo no tiene reparacin. Adems debe poder obtener informes acerca del tiempo de inactividad de los equipos y acceso al buzn de sugerencias. El usuario debe poder obtener informacin de los manuales, software y hardware asociado y disponibilidad de un equipo en concreto . Tendr acceso al buzn de sugerencias. Se debe tener en cuenta que: * El sistema trabajar en un entorno multiusuario. * Las bases de datos sern un modelo estndar. * Cada equipo estar compuesto por un monitor, un teclado, un ratn, y una unidad central. *La unidad central estar formada por una serie de componentes que se describirn de manera textual en un campo al efecto. 5-11 Juan Manuel Cueva Lovelle Ejemplo de Especificacin de Requisitos R1. El sistema gestiona una base de datos con todos los equipos hardware y programas software de la empresa R2. La gestin de equipos hardware incluir las altas, bajas, modificaciones de los equipos, las averas, la composicin de cada equipo y el software instalado R2.1 Los manuales correspondientes a cada equipo y cada programa deben de poder localizarse R3. La gestin del software debe incluir altas, bajas, y consultas R3.1 Sobre cada programa software deber conocerse los manuales, soportes magnticos (disquetes, CD-ROM), nmero de licencias, nmero de instalaciones, localizacin fsica de los manuales. R3.2 Ligado a cada programa software debe conocerse el proveedor, fecha y precio de adquisicin R.3.3 Puede existir software llave-en-mano y deber conocerse si se dispone del cdigo fuente y donde esta situado, as como la empresa que lo desarroll, los derechos de copia, el precio, el tiempo de desarrollo, la herramienta de desarrollo, y el nombre de la persona responsable de l desarrollo R4. Las localizaciones fsicas de equipos, programas y manuales se codificarn ... 5-12 Juan Manuel Cueva Lovelle Anlisis Orientado a Objetos Casos de uso Un caso de uso es una tcnica de modelado utilizada para describir lo que un nuevo sistema debe hacer o lo que un sistema existente ya hace. Un modelo de casos de uso se construye mediante un proceso iterativo durante las reuniones entre los desarrolladores del sistema y los clientes (y/o los usuarios finales) conduciendo a una especificacin de requisitos sobre la que todos coinciden. Un caso de uso captura algunas de las acciones y comportamientos del sistema y de los actores El modelado con casos de uso fue desarrollado por Ivar Jacobson [Jacobson 92] Escenarios A veces se utiliza escenario como sinnimo de caso de uso Sin embargo en UML un escenario se refiere a los pasos que se desarrollan dentro de un caso de uso Fichas CRC Son muy tiles para la enseanza del AOO, DOO y POO No estn contempladas en UML 5-13 Juan Manuel Cueva Lovelle Anlisis mediante Casos de Uso El sistema que se desea modelar se representa encerrado en un rectngulo Los actores son los que interactan con el sistema. Representan todo lo que necesite intercambiar con el sistema. Un actor es una clase Se diferenciar entre actores y usuarios. Un usuario es una persona que utiliza el sistema Un actor representa el papel (rol) que una persona desempea Por ejemplo una persona puede ser usuario y administrador en un sistema, unas veces actuar como usuario y otras como administrador, pero deben contemplarse ambos actores. Los Casos de Uso es un camino especfico para utilizar el sistema Para cada Caso de Uso, Actor y Sistema se realiza una descripcin detallada Los Casos de Uso tan slo indican opciones generales El diagrama de Casos de Uso es un diagrama sencillo que tiene como finalidad dar una visin global de toda la aplicacin de forma que se pueda entender de una forma rpida y grfica tanto por usuarios como por desarrolladores Caso de uso Sistema Actor Interaccin Lmites del sistema
Caso de uso 2 Caso de uso 3 Caso de uso 4 Caso de uso 5 Caso de uso 6 Actor 1 Actor 2 Actor 3 Caso de uso 1 Caso de uso 7 5-14 Juan Manuel Cueva Lovelle Diagramas de casos de uso en UML Caso de uso << usa >> <<extiende >> Actor El diagrama de casos de uso es parte de UML Un caso de uso es la tpica interaccin entre un usuario y un sistema informtico Un actor es el papel que el usuario juega con respecto al sistema. Un actor no tiene que ser un humano, puede ser por ejemplo otro sistema externo que pide informacin al sistema actual La relacin <<extiende>>se utiliza cuando un caso de uso es similar a otro caso de uso pero se le aade alguna caracterstica nueva La relacin <<usa >>se utiliza cuando se tiene una parte del comportamiento comn a ms de un caso de uso, y no se desea almacenar una copia en cada caso de uso de la descripcin de este comportamiento. 5-15 Juan Manuel Cueva Lovelle Ejemplo de Casos de Uso Responsable de mantenimiento
PEDIDOS INFORMES AVERIAS RESERVAS SUGERENCIAS INFORME PARA USUARIO ACTIVIDAD Responsable de informtica Usuario 5-16 Juan Manuel Cueva Lovelle Descripcin de los Casos de Uso 1 . PEDI DOS Escenar i o gener al donde se r eal i zan t odas l as oper aci ones r el at i vas a pedi dos: hacer , r eci bi r , anul ar y devol ver pedi dos. Todo es r eal i zado por el Res pons abl e de I nf or mt i ca. 2 . I NFORMES Todos l os i nf or mes que s on neces ar i os par a el f unci onami ent o de l a empr es a: i nf or me de pedi do, de amor t i zaci ones , de i nact i vi dad, de compos i ci n de equi pos bs i cos , de compos i ci n de ot r os equi pos , de i nvent ar i o s of t war e y manual es , de gar ant as y de di s poni bi l i dad. Es t os i nf or mes s on r eal i zados par a el Res pons abl e de I nf or mt i ca. 3. AVERI AS Engl oba t odas l s oper aci ones r el at i vas a l as aver as t ant o el avi so que puede s er r eal i zado por cual qui er act or ( Res pons abl e de I nf or mt i ca, de Mant eni mi ent o o Us uar i o) , como el par t e de aver a que es r eal i zado por el Res pons abl e de Mant eni mi ent o y ent r egado al Res pons abl e de I nf or mt i ca. 4 . RESERVAS Es t ant o l a pet i ci n de r eser va de un equi po con unas car act er st i cas det er mi nadas , que puede s er r eal i zada por cual qui er us uar i o al Res pons abl e de I nf or mt i ca, como l a conces i n de una r es er va que r eal i za es t e l t i mo a un usuar i o. 5 . SUGERENCI AS Es una l nea de comuni caci n ent r e l os di f er ent e agent es que i nt er acci onan con el si st ema. 6 . I NFORMES PARA EL USUARI O Es un i nf or me es peci al ment e r eal i zado par a el us uar i o donde es te puede encont r ar t oda l a i nf or maci n que pueda neces i t ar en un moment o det er mi nado s obr e un equi po, s u di s poni bi l i dad, s of t war e o un manual . 7. ACTI VI DAD Real i zado por el Res pons abl e de I nf or mt i ca engl oba t odo l o r el at i vo al buen f unci onami ent o del mat er i al de l a empr es a: dar de baj a t empor al ment e un equi po cuando es t a en r epar aci n, dar de baj a per manent ement e un equi po cuando no t i ene ar r egl o y act ual i zar t ant o s of t war e como l os manual es . 5-17 Juan Manuel Cueva Lovelle Anlisis mediante escenarios Se enumeran escenarios fundamentales para el funcionamiento del sistema Se estudia cada escenario utilizando guiones como los que se usan en el cine Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, as como los mecanismos que relacionan los objetos De los escenarios iniciales se puede pasar a otros escenarios secundarios Los escenarios tambin se pueden utilizar para probar el sistema en la fase de pruebas El estudio de los escenarios con detalle permite ir enriqueciendo el Diccionario de datos No es necesario hacer todos los escenarios y sub-escenarios posibles si se observa que no enriquecen el diccionario de datos Numeracin: 1.1. Titulo: Hacer pedido Precondiciones: Sugerencias de compra, caducidad de licencias, bajas permanente hardware, Quien Lo Comienza: Responsable de Informtica. Quien Lo Finaliza: Responsable de Informtica. Postcondiciones: Descripcin: Son las operaciones de compra de todos los componentes (hardware, software y manuales) que realiza el responsable de informtica. Adems da estos equipos de alta y debe apoyarse en el sistema para gestionar los pedidos correctamente para lo que debe anotar en el sistema que ha pedido un componente a un proveedor ( por tanto que est pendiente de recibir). Numeracin: 1.2. Titulo: Anular pedido Precondiciones: Cambio de precio, cambio de necesidades de la Empresa. Quien Lo Comienza: Responsable de Informtica Quien Lo Finaliza: Responsable de Informtica Postcondiciones: Descripcin: Esta operacin la realiza el responsable de informtica cuando toma la decisin de anular un pedido que haba realizado con anterioridad. Numeracin: 1.3 Titulo: Recibir pedido Precondiciones: Haber realizado la peticin de un pedido. Quien Lo Comienza: Responsable de Informtica Quien Lo Finaliza: Responsable de Informtica Postcondiciones: Descripcin: El responsable de informtica confirma la recepcin de los pedidos. 5-18 Juan Manuel Cueva Lovelle Herramienta Rational Rose [ROSE] Tiene una seccin para ir introduciendo los Casos de Uso (Use Case View) Permite el manejo de actores, que se traducirn al sistema como clases Cada sistema recibe un nombre (no aparece el rectngulo) 5-19 Juan Manuel Cueva Lovelle Ejemplo de Casos de Uso con Rational Rose 5-20 Juan Manuel Cueva Lovelle EJERCICIOS PROPUESTOS 5.1 Realizar el anlisis y el diseo preliminar del juego del ajedrez. Se puede jugar dos personas entre s o una persona contra el ordenador. En este ltimo caso debe ser posible seleccionar el nivel de dificultad entre una lista de varios niveles. El juego de ajedrez permitir al jugador elegir el color de las piezas. La aplicacin deber permitir detectar los movimientos ilegales de las piezas, tiempos utilizados cada jugador, registro de jugadas y piezas perdidas. Tambin determinar si se alcanzan tablas, y permitir abandonar la partida a un jugador. 5.2 Realizar el anlisis y diseo preliminar de una aplicacin que realiza estudios de mercado para situar grandes superficies (hipermercados). Se supone que cada gran superficie necesita un mnimo de poblacin que pueda acceder a dicho hipermercado en menos de un tiempo dado. La red de carreteras se puede representar mediante un grafo. 5.3 Realizar el anlisis y diseo preliminar para gestionar los fondos bibliogrficos y de socios de una biblioteca. 5.4 Realizar el anlisis y diseo preliminar para gestionar un centro de enseanza Juan Manuel Cueva Lovelle 6-1 Diagramas de Secuencia Se denominan Diagramas de Secuencia en UML Diagramas de Interaccin en Booch Diagramas de seguimiento de sucesos en OMT Se hace un diagrama de secuencia por cada escenario Permiten en las fases iniciales de anlisis y diseo Razonar ms en detalle como es el comportamiento de un escenario Obtener nuevas clases y objetos en el escenario (enriquecimiento del diccionario de datos) Detectar cuales son los mtodos de las clases, al observar como se relacionan los objetos entre s para llevar a cabo la tarea encomendada en el escenario Se utilizan en las fases de prueba para validar el cdigo Si se desea ms detalle se utilizan los diagramas de Colaboracin Juan Manuel Cueva Lovelle 6-2 Diagramas de interaccin Traza de la ejecucin de un escenario Notacin de Booch Un diagrama de interacciones se usa para realizar una traza de la ejecucin de un escenario en el mismo contexto que un diagrama de objetos de la notacin Booch. Los diagramas de interaccin toman los elementos esenciales de los diagramas de objetos y los reestructuran para enfocarlos a la lectura de los mensajes en orden El orden se indica mediante la posicin vertical, siendo el primer mensaje el de la parte superior y el ltimo el de la parte inferior. Por tanto no necesitan nmeros de secuencia Los diagramas de interaccin son mejores que los diagramas de objetos para capturar la semntica de los escenarios en un momento temprano del ciclo de desarrollo Segn se avanza se pone ms nfasis en los diagramas de objetos Juan Manuel Cueva Lovelle 6-3 Diagrama de interaccin Guiones y centros de control Ejemplo en notacin de Booch Un guin son las instrucciones generales de cada mensaje del diagrama de interaccin Los guiones se escriben a la izquierda del diagrama de interaccin en lenguaje natural (espaol) o en un lenguaje de programacin Ni los diagramas de objetos ni los diagramas de interaccin indican por s solos el centro de control a medida que pasan los mensajes En el diagrama de interaccin se utilizan rectngulos en las lneas verticales de cada objeto para indicar el tiempo relativo durante el cual el flujo de control est centrado en ese objeto Juan Manuel Cueva Lovelle 6-4 Escenarios y seguimiento de sucesos Notacin OMT Juan Manuel Cueva Lovelle 6-5 Diagramas de secuencia en UML Juan Manuel Cueva Lovelle 6-6 Ejemplo de diagrama de secuencia con Rose Juan Manuel Cueva Lovelle 6-7 Diagramas de Colaboracin Se denominan Diagramas de Colaboracin en UML Diagramas de objetos en Booch Permiten profundizar en el nivel de detalle en los diagramas de Secuencia Expresan las colaboraciones de los objetos en tiempo de ejecucin Juan Manuel Cueva Lovelle 6-8 Diagramas de objetos Muestra la existencia de objetos y sus relaciones en la vista lgica de un sistema Notacin de Booch En el anlisis se usan los diagramas de objetos para indicar la semntica de los escenarios primarios y secundarios que proporcionan la traza del comportamiento del sistema En el diseo se usan diagramas de objetos para ilustrar la semntica de los mecanismos del diseo lgico Cada objeto se denota con su nombre y opcionalmente con sus atributos Los objetos interaccionan a travs de enlaces con otros objetos Objeto cliente es el objeto que invoca una operacin Objeto servidor es el objeto que suministra la operacin Con una flecha se indica la direccin de la invocacin, as como la operacin, y un nmero de orden (opcional) Juan Manuel Cueva Lovelle 6-9 Diagrama de objetos Ejemplo en notacin de Booch Se ilustra el escenario que muestra la traza de ejecucin de la determinacin del coste neto de recoleccin de una cosecha especfica El orden de las acciones est numerado Puede haber relaciones que no se utilicen para pasar mensajes en un escenario determinado Juan Manuel Cueva Lovelle 6-10 Diagramas de objetos Papeles (roles) y flujo de datos Notacin de Booch Se pueden especificar los papeles (roles) del diagrama de clases en el diagrama de objetos Se pueden indicar tambin las claves y restricciones del diagrama de clases en el diagrama de objetos Se muestra explcitamente la direccin del flujo de datos que ayuda a explicar la semntica de un escenario particular Se indica la direccin del flujo de datos con una flecha y un crculo Se puede usar tanto un objeto como un valor para el flujo de datos Juan Manuel Cueva Lovelle 6-11 Diagramas de objetos Visibilidad Notacin de Booch En ciertos escenarios es til reflejar la forma exacta en que un objeto tiene visibilidad sobre otro Las marcas de visibilidad son G - El objeto servidor es global al cliente P - El objeto servidor es parmetro de alguna operacin del cliente F - El objeto servidor es parte del cliente (field, campo) L - El objeto servidor es un objeto declarado local en el mbito del diagrama de objetos La ausencia del adorno de visibilidad indica que est sin especificar Juan Manuel Cueva Lovelle 6-12 Diagramas de objetos Objetos activos y sincronizacin Notacin de Booch Los objetos son activos si incorporan su propio hilo de control Todos los objetos son secuenciales a menos de que se diga lo contrario sincronismo simple: slo hay un nico hilo de control Se puede indicar el estilo de concurrencia de un objeto: Sncrono: el cliente espera hasta que el servidor acepte el mensaje Paso de mensajes con abandono inmediato: el cliente abandona el mensaje si el servidor no lo atiende inmediatamente Sincronizacin de intervalo (de espera o timeout): el cliente abandona el mensaje si el servidor no puede atenderlo dentro de un espacio de tiempo determinado Asncrono: el cliente enva el evento al servidor para que lo procese, el servidor pone el mensaje en una cola, y el cliente contina su actividad sin esperar al servidor Juan Manuel Cueva Lovelle 6-13 Diagramas de objetos Presupuestos de tiempo y especificaciones Notacin de Booch Para aplicaciones crticas respecto al tiempo se pueden trazar escenarios indicando tiempos exactos Se usan valores de tiempo en vez de nmeros de secuencia que indican tiempo relativo (por ejemplo en segundos) con el signo ms delante Especificaciones. Al igual que para los diagramas de clases cada entidad del diagrama de objetos puede tener su especificacin en texto Los diagramas de objetos deben especificar su contexto Contexto: global | categora | clase | operacin Juan Manuel Cueva Lovelle 6-14 Ejemplo: Control de inventario Diagrama de objetos Notacin de Booch 1 (Alguien pide) Coste de un Ensamblaje Ensamblaje debe devolver Coste 2 Ensamblaje Crea un Iterador Ensamblaje envia susElementos:Bag 3 Comienza un bucle 3.1 Ensamblaje TomaSig-uiente Elemento Iterador envia Elemento 3.2 Ensamblaje pide Coste del Elemento Elemento envia coste Juan Manuel Cueva Lovelle 6-15 Diagramas de colaboracin UML Ejemplo de diagrama de colaboracin en UML Juan Manuel Cueva Lovelle 6-16 Ejemplo de diagrama de colaboracin en Rose Juan Manuel Cueva Lovelle 6-17 Diagramas Estticos Se denominan Diagramas Estticos en UML Diagramas de Clases en Booch Diagrama de Clases en OMT Estos diagramas son los ms importantes del diseo orientado a objetos, son la piedra angular de nuestro diseo. Contienen toda la informacin de todas las clases y sus relaciones con otras clases Aunque son los ms importantes no se llega a ellos directamente dado que tienen un gran nivel de abstraccin dado que contemplan el modelo globalmente sin particularizarse en ningn escenario concreto Cuando se construyen los diagramas anteriores (Casos de uso, Secuencia, Colaboracin) las herramientas van obteniendo nombres de clase y generando los atributos y operaciones de cada clase siguiendo las indicaciones dadas por las especificaciones de requisitos en los casos de uso y escenarios En el momento de hacer el primer diagrama esttico ya se tiene una lista de clases con algunos de sus atributos y operaciones. Sin embargo es necesario reflexionar y abstraer sobre la organizacin de esas clases estudiando las relaciones de herencia, agregacin, etc. El diagrama Esttico se refinar en las sucesivas iteraciones del modelo Juan Manuel Cueva Lovelle 6-18 Ejemplo de Diagrama Esttico con Rose Juan Manuel Cueva Lovelle 6-19 Clases Booch representa las clases por una nube con contorno discontinuo, colocndose en su interior el nombre de la clase y separados por una lnea estn los atributos, las operaciones, las restricciones y los adornos La nube significa que las fronteras de una abstraccin no son ntidas Las lneas discontinuas indican que los clientes slo operan sobre objetos y no sobre la clase Los atributos y las operaciones pueden ser visibles o no segn el detalle deseado Un atributo es un dato que se almacenar en los objetos que son instancias de la clase Un mtodo es la implementacin de una operacin para la clase Un adorno de clase es una propiedad por ejemplo indicar que la clase es abstracta (no puede tener instancias, slo se puede heredar de ella) En UML las clases se pueden representar de tres formas: Sin detalle Detalles a nivel de anlisis y diseo Detalle a nivel de implementacin Los atributos en UML se pueden describir como: visibilidad : tipo = valor-inicial { propiedad } donde visibilidad puede ser: + publico # protegido - privado Booch OMT UML Juan Manuel Cueva Lovelle 6-20 Clases y objetos en UML Clase Objetos Los compartimentos de una clase pueden tener nombres Juan Manuel Cueva Lovelle 6-21 Estereotipos en UML Un estereotipo es una forma de clasificar las clases a alto nivel Los estereotipos se muestran con un texto entre doble ngulo << y >>, por ejemplo: <<control>> Los estereotipos tambin se pueden definir con un icono Muchas extensiones del ncleo de UML se pueden describir mediante una coleccin de estereotipos Tambin se puede razonar que los tipos clase, asociacin, y generalizacin son subtipos de estereotipos del metamodelo Los estereotipos tambin se pueden colocar a grupos de la lista de elementos de una clase Juan Manuel Cueva Lovelle 6-22 Tipos versus Clases de implementacin en UML Las clases se pueden especializar usando estereotipos en Tipos y Clases de implementacin Un Tipo caracteriza un papel (rol) cambiante que un objeto puede adoptar y despus abandonar Una Clase de implementacin define fsicamente la estructura de datos y procedimientos que se implementar en un lenguaje de programacin (C++, Java,...) Un objeto puede tener mltiples tipos (que pueden cambiar dinmicamente) pero slo una Clase de Implementacin (que es fija). Un Tipo se muestra con el esterotipo <<type>> Una Clase de implementacin se muestra con el estereotipo <<implementation class>> La implementacin de un tipo por medio de una clase de implementacin se modela por medio de una relacin Realiza, que se indica con una flecha hueca con trazos discontinuos. Este smbolo implica herencia de operaciones pero no de estructura. Juan Manuel Cueva Lovelle 6-23 Interfaces en UML Una I nterfaz es una especificacin para las operaciones externas visibles de una clase, componente, o otra entidad (incluyendo unidades globales como los paquetes), pero siempre sin especificar la estructura interna Cada interfaz especifica a menudo slo una parte limitada del comportamiento de una clase real Una interfaz no tiene implementacin Una Interfaz es formalmente equivalente a una clase abstracta sin atributos y sin mtodos, con slo operaciones abstractas Un interfaz se puede representar de dos formas: Circulo unido por una lnea a una clase con las operaciones de interfaz al lado del crculo Rectngulo con la palabra reservada <<interface>>y la seccin de operaciones Una clase que usa las operaciones de una interfaz se une por medio de una flecha de lnea discontinua a los crculos o al rectngulo de la interfaz Tambin se puede utilizar la relacin Realiza desde una clase a una interfaz que soporta Juan Manuel Cueva Lovelle 6-24 Relaciones entre clases Booch Las asociaciones se pueden etiquetar con un nombre o frase Una clase puede asociarse consigo misma (asociacin reflexiva) La cardinalidad o multiplicidad especifica el nmero de asociaciones entre dos clases 1 (exactamente uno) N (cero o ms) 1..N (uno o ms) 3..7 (rango especificado) 7 (nmero exacto) Si no se indica se considera sin especificar Juan Manuel Cueva Lovelle 6-25 Relaciones entre clases (OMT) Un a lnea sin smbolos de multiplicidad denota asociacin uno a uno Un crculo blanco indica cero o uno Un crculo negro indica cero o ms Tambin se puede utilizar un nmero 7 (valor exacto), 2+ (2 o ms), 3-5 (un intervalo). Asociacin ternaria La notacin de crculos blancos y negros no se usa para asociaciones n-arias Juan Manuel Cueva Lovelle 6-26 Asociaciones entre clases (UML) Juan Manuel Cueva Lovelle 6-27 Utilidades de clase Las utilidades de clase representan la encapsulacin de abstracciones no orientadas a objetos que proporcionan servicios algortmicos Pueden estar constituidas por los servicios de subprogramas libres, servicios de manejo de sistemas de gestion de bases de datos (SQL inmerso), clases estticas de C++, llamadas a funciones API de Windows, Las clases pueden asociarse y utilizar utilidades de clase En algunos casos pueden parametrizarse y ser instanciadas NO SE PUEDE HEREDAR DE LAS UTILIDADES DE CLASE ! En UML se coloca el esterotipo <<utility>>en el diagrama de clase En Booch la utilidad de clase lleva sombra UML Booch Juan Manuel Cueva Lovelle 6-28 Control de exportacin (control de acceso) La mayor parte de los lenguajes OO permiten especificar los permisos de acceso a los datos y a los mtodos de una clase Los accesos se pueden marcar en la relacin apropiada con los siguientes smbolos Booch UML <sin marcas> + Acceso pblico | # Acceso protegido || - Acceso privado ||| {implementation} Se utiliza en la implementacin Booch Juan Manuel Cueva Lovelle 6-29 Propiedades Califican la relacin entre clases, en C++ hay tres propiedades: S V F <<static>> <<virtual>> <<friend>> Booch Booch UML La designacin de un objeto o funcin de una clase La designacin de una clase base compartida en una trama de herencias con forma de rombo La designacin de una clase que concede a otra derechos de acceso a sus partes no pblicas <<friend>> A B UML Juan Manuel Cueva Lovelle 6-30 Contencin fsica La agregacin es un caso particular de la asociacin que denota posesin La agregacin es una relacin todo/parte La contencin fsica puede ser de dos tipos: por valor indica que la construccin y destruccin de estas partes ocurre por construccin y destruccin del agregado. Asegura que los tiempos de vida del todo y su parte son iguales por direccin o referencia indica que slo contiene un puntero. Los tiempos de vida del todo y su parte son independientes Booch Por valor Por referencia UML Juan Manuel Cueva Lovelle 6-31 Ejemplo: Control de inventario Modelo esttico Versin preliminar 1.0 Cdigo en C++ y diagrama de clases en notacin Booch #include string.h #include set.h class Num_elem; class Elemento{ public: virtual double Coste() const=0; private: const Num_elem& suNumeroElemento; String suDescripcion; }; class Ensamblaje: public Elemento{ public: virtual double Coste() const; private: Set<Elemento*> susElementos; }; class Pieza: public Elemento{ public: virtual double Coste() const; private: double suCoste; }; Juan Manuel Cueva Lovelle 6-32 Diagrama de clases detallado Versin 2.0 Juan Manuel Cueva Lovelle 6-33 Anidamiento de clases Las clases pueden anidarse fsicamente en otras clases La mayor parte de los lenguajes OO no permiten heredar las clases anidadas El anidamiento es una decisin tctica de diseo Rara vez existe una razn que obligue a anidar clases o categoras de clases hasta profundidades de uno o dos niveles No hay que confundir anidamiento con agregacin Booch B UML A Juan Manuel Cueva Lovelle 6-34 Composicin en UML Adems de la agregacin UML aade la composicin Con la composicin las partes slo se puede pertenecer a un todo Si se elimina el todo se eliminan las partes Distintas formas de mostrar la composicin en UML Juan Manuel Cueva Lovelle 6-35 Papeles (roles) y claves Un papel (o rol) denota el proposito o capacidad por la que una clases se asocia con otra Se nombra el papel de una clase mediante una etiqueta ligada a una asociacin, colocada adyacentemente a la clase que ofrece ese papel Una clavees un atributo de la asociacin entre clases cuyo valor identifica un objeto de manera nica Las claves aparecen como identificadores entre corchetes Una clave debe ser un atributo del objeto situado en el extremo destino de la asociacin Son posibles las claves mltiples, pero los valores de clave deben ser nicos Juan Manuel Cueva Lovelle 6-36 Restricciones Una restriccin es la expresin de alguna condicin semntica que se debe preservar Una restriccin es un invariante de clase o de relacin que hay que cumplir mientras el sistema est en un estado estable La notacin es una expresin entre llaves ({exp.}) adyacente a la clase o relacin a la que se aplica la restriccin Pueden escribirse expresiones de restriccin que nombren a otras asociaciones o elementos de clases Booch UML Juan Manuel Cueva Lovelle 6-37 Asociaciones atribuidas y notas Una asociacin atribuida es una asociacin que tiene una clase como atributo Estas clases atributo permiten modelar permiten modelar las propiedades de las asociaciones La clase atributo se une mediante una lnea discontinua a la lnea que representa la asociacin Una nota es un comentario que se puede aadir a cualquier elemento del diagrama con el objetivo de recordar suposiciones y decisiones del desarrollador El icono en forma de nota se une al elemento que afecta mediante una lnea discontinua Es interesante especificar en las notas los requisitos a los que responde la implementacin, permitiendo el seguimiento de los requisitos en el ciclo de vida del software Booch Esto es un ejemplo de nota en UML UML Juan Manuel Cueva Lovelle 6-38 Especificaciones Una especificacin es una forma no grfica que se usa para proporcionar la definicin completa de una entidad de la notacin Una entidad de la notacin puede ser una clase, una asociacin, una operacin individual o un diagrama completo Elementos comunes Nombre: identificador Definicin: texto Especificaciones de clases Responsabilidades: texto Atributos: lista de atributos Operaciones: lista de operaciones Restricciones: lista de restricciones Mquina de estados: referencia a la mquuina de estados Control de exportacin: public |implementacin Cardinalidad: expresin Parmetros: lista de parmetros Persistencia: transitorio |persistente Concurrencia: secuencial | vigilada |sncrona |activa Complejidad espacial: expresin Especificaciones de operaciones Clase de retorno: referencia a una clase Argumentos: lista de argumentos Calificacin: texto Control de exportacin: public|private|protected|implementacin Protocolo: texto Precondiciones: texto|referencia cd. fuente|ref. diag. objetos Postcondiciones: texto|referencia cd. fuente|ref. diag. objetos Excepciones: lista de excepciones Concurrencia: secuencial | vigilada | sncrona Complejidad espacial: expresin complejidad temporal: expresin Juan Manuel Cueva Lovelle 6-39 Atributos de enlaces y asociaciones Ejemplos OMT Un atributo de enlacees una propiedad del enlace de una asociacin Los atributos del enlace son una propiedad de la asociacin y no de las clases enlazadas Tambin puede haber atributos de enlace para asociaciones ternaria En el ejemplo se relacionan las clases Jugador, Equipo y Partido. As un jugador juega a lo largo de su vida profesional en distintos equipos en distintos partidos. En esta relacin ternaria se le pueden asociar los atributos goles y tarjetas Atributos de enlace versus atributos de clases Es preferible que los atributos estn en el enlace que en la clase pues permite ms flexibilidad a cambios del modelo de clases Asociacin muchos-a-muchos con atributos de enlace Atributos de enlace para asociaciones uno-a-muchos Atributos de enlace para una asociacin ternaria Atributos de enlace modelados como clases Juan Manuel Cueva Lovelle 6-40 Ejemplos de asociaciones UML Juan Manuel Cueva Lovelle 6-41 Claves, restricciones, atributos derivados y homomorfismos Ejemplos OMT Una clave candidata es un conjunto mnimo de atributos que define de forma nica un objeto o enlace El identificador de un objeto es siempre una clave candidata de una clase Para las asociaciones son claves candidatas una o ms combinaciones de objetos relacionados El uso de claves es tpico del manejo de bases de datos, pero es un concepto lgico en los diagramas de clases En el ejemplo Alumno+Universidad es la clave candidata Las restricciones limitan los valores que pueden tomar las entidades Son necesarias varias iteraciones para darse cuenta de las restricciones del modelo Las restricciones generales se expresan por medio del lenguaje natural o ecuaciones Se representan por una lnea discontinua que une las clases o relaciones, colocndose un comentario entre llaves En el ejemplo una asociacin es un subconjunto de otra Los atributos derivados o calculadosse obtienen a partir del clculo de otros atributos que tambin pueden ser derivados o calculados Se marcan con / Las clases derivadas o calculadas se obtiene a partir de otras clases que a su vez pueden ser tambin derivadas o calculadas Se indican con una marca en la esquina superior izzquierda Las asociaciones derivadas o calculadasse obtienen a partir de otras asociaciones que asu vez pueden ser tambin derivadas o calculadas Se indican con una marca en la lnea de la asociacin Un homomorfismoestablece una correspondencia entre dos asociaciones Juan Manuel Cueva Lovelle 6-42 Papeles (roles), ordenacin y calificacin Ejemplos OMT En una relacin entre clases cada una de ellas juega un papel que se identifica con un nombre situado de forma adyacente a la clase en cada uno de los extremos de la lnea que expresa la relacin Puede haber ms de una relacin entre dos clases, y cada clase jugar distintos papeles para cada relacin Cuando la parte muchos de una asociacin est ordenada se puede indicar con el smbolo {ordenado} al lado del papel que juega la clase Una asociacin entre clases puede tener restricciones a la multiplicidad por medio de atributos calificados Juan Manuel Cueva Lovelle 6-43 Restricciones en UML Juan Manuel Cueva Lovelle 6-44 Ejemplo OMT Diagrama de clases de un sistema de ventanas Juan Manuel Cueva Lovelle 6-45 Clases abstractas y herencia mltiple Ejemplos OMT Ejemplo de clase abstracta y operaciones abstractas Herencia mltiple con clases solapadas Herencia mltiple a partir de clases disjuntas Juan Manuel Cueva Lovelle 6-46 Herencia en UML Juan Manuel Cueva Lovelle 6-47 Diagrama de clases (Booch) Muestra la existencia de clases y sus relaciones en el modelo lgico del sistema Juan Manuel Cueva Lovelle 6-48 Diagrama de clases (OMT) Bsico Juan Manuel Cueva Lovelle 6-49 Diagrama de clases (OMT) Avanzado Juan Manuel Cueva Lovelle 6-50 UML Resumen de la notacin (a) Juan Manuel Cueva Lovelle 6-51 UML Resumen de la notacin (b) Juan Manuel Cueva Lovelle 6-52 Diagramas de Actividad Los Diagramas de Actividad representan como se dirigen los flujos de los procesos internos (en oposicin a los eventos externos) No estn disponibles en Booch ni en OMT Cada diagrama de actividad se corresponde con los flujos que ocurren dentro de Una clase Una operacin de una clase Un caso de uso Se utilizarn Diagramas de Actividad en situaciones donde todos o la mayora de los eventos representan la totalidad de acciones generadas internamente (es decir procedimientos de control de flujo) Diagramas de Estados en situaciones donde ocurren eventos asncronos Los elementos del diagrama de actividad se denominan Actividades y se representan por un rectngulo redondeado Actividad Juan Manuel Cueva Lovelle 6-53 Ejemplo de Diagrama de Actividad Juan Manuel Cueva Lovelle 6-54 Decisiones Calles o pasillos de actividades (swinlanes) Juan Manuel Cueva Lovelle 6-55 Relaciones de flujo acciones-objetos Juan Manuel Cueva Lovelle 6-56 Iconos de control A) Smbolos de envo y recepcin de seales B) Eventos aplazados Juan Manuel Cueva Lovelle 6-57 Diagramas de Estados Se denominan Diagramas de Transicin de Estados en Booch Diagramas de Estados en OMT Diagramas de Estados en UML Los diagramas de estados muestran la secuencia de estados por los que pasa un objeto durante su vida y que se corresponden con los estmulos recibidos, junto con sus respuestas y acciones Cada diagrama de estados se corresponde con una clase o con un mtodo Juan Manuel Cueva Lovelle 6-58 Diagramas de transicin de estados Muestran a las clases desde la lgica del sistema Notacin de Booch Un diagrama de transicin de estados muestra el espacio de estados de una clase determinada, los eventos que provocan una transicin de un estado a otro y las acciones que resultan de ese cambio de estado Un estado de un objeto representa los resultados acumulados de su comportamiento Es necesario un nombre para cada estado. Adems se pueden poner las acciones asociadas a cada estado Un evento es algn suceso que puede causar un cambio de estado en el sistema Un evento puede disparar una accin Hay un estado inicial por defecto Puede haber o no estado final o de parada La mquina de estados deja de existir cuando se destruye el objeto que la contiene Juan Manuel Cueva Lovelle 6-59 Diagramas de transicin de estados Ejemplo en la notacin de Booch Diagrama de estados de la clase ControladorEntorno Se comienza con el estado Ocioso Con el evento Definir-Clima hay un cambio de estado Se ha supuesto que este evento slo puede ocurrir de da Se alterna entre los estados Dia y Noche Se controla la temperatura tanto de dia como de noche Si se recibe el evento Terninar-Clima se vuelve al estado Ocioso Juan Manuel Cueva Lovelle 6-60 Diagramas de transicin de estados Acciones, transiciones condicionales y estados anidados Ejemplo en notacin de Booch Se pueden asociar acciones a los estados indicando la accin que ocurre cuando se entra o sale del estado Ejemplo: en el estado Calentando entrada Calentador::activar salida Calentador::desactivar Se pueden representar transiciones de estado condicionales (o vigiladas) por medio de una expresin booleana entre llaves Ejemplo: en la transicin Demasiado-frio [tiempo de encendido>=5 minutos] Se pueden detallar los estados utilizando estados anidados Los estados continentes se llaman superestados Los estados anidados se llaman subestados Las transiciones desde y hacia subestados dento de un superestado se hacen utilizando flechas romas Ejemplo: Transicin de Encendido a Preparado No debera denominarse Fallo un estado y un evento Juan Manuel Cueva Lovelle 6-61 Diagramas de transicin de estados Historia, estados ortogonales y especificaciones Ejemplo en notacin de Booch Historia. Se utiliza cuando se quiere pasar por un estado una sla vez dentro de un superestado con subestados En el ejemplo Por el estado Crear-Informe slo se pasa la primera vez Se utiliza una H en el superestado y un crculo relleno con una flecha que seala al estado por el que se pasa slo una vez Estados ortogonales o concurrentes. La notacin de Booch no los utiliza pues ese comportamiento se refleja en los diagramas de objetos Especificaciones. Tambin se pueden especificar en modo texto la definicin completa de un diagrama de transicin de estados. Aunque en general no deben de aadir informacin nueva Juan Manuel Cueva Lovelle 6-62 Notacin del modelo dinmico OMT Juan Manuel Cueva Lovelle 6-63 Diagramas de estados Ejemplos en OMT Diagrama de estados simplificado de la clase ajedrez Diagrama de estados de la clase telfono Juan Manuel Cueva Lovelle 6-64 Diagramas de estados Concurrencia de agregacin (OMT) Cada estado componente experimenta transiciones en paralelo a todos los dems. Los diagramas de estados de los componentes son independientes, excepto si hay expresiones de proteccin como la que se muestra en la clase encendido que obliga a encender con [Transmisin en punto muerto] Juan Manuel Cueva Lovelle 6-65 Diagramas de estados en UML Juan Manuel Cueva Lovelle 6-66 Ejemplos de diagramas de estados en UML Juan Manuel Cueva Lovelle 6-67 Ejemplo de Diagrama de Estados en Rose Juan Manuel Cueva Lovelle 6-68 Diagramas de Implementacin Los diagramas de implementacin como su propio nombre indica representan aspectos relativos a la implementacin incluyendo la estructura del cdigo fuente y otras caractersticas propias del tiempo de ejecucin UML tiene dos tipos de diagramas de implementacin Diagramas de Componentes Muestran la estructura del cdigo fuente Se corresponden con Categorias de clases en Booch Paquetes de UML Diagramas de Mdulos en Booch Diagramas Desplegables (Deployment Diagrams) Muestran la estructura del sistema en tiempo de ejecucin Se corresponden con los Diagramas de Procesos de Booch Juan Manuel Cueva Lovelle 6-69 Diagramas de Implementacin UML a) Diagrama de Componentes Muestran la dependencia entre los componentes software b) Diagramas Desplegables Son grafos de nodos conectados por asociaciones de comunicacin c) Nodos Son objetos fsicos en tiempo de ejecucin que representan algn recurso que se pueda procesar. Los nodos incluyen perifricos Pueden representarse como tipos e instancias d) Componentes Representa un elemento de implementacin que se puede redistribuir Juan Manuel Cueva Lovelle 6-70 Categoras de clases Booch Una categora de clases es un agregado que contiene clases y otras categoras de clases Sirven para dividir el modelo lgico de un sistema Se da un nombre a cada categora de clases No es necesario mostrar todas las clases contenidas, puede mostrarse las ms representativas o ninguna Una categora de clases puede utilizar otras categoras de clases. Se utiliza el mismo smbolo de la relacin de uso. Las categoras de clases de ms alto nivel representan la arquitectura de alto nivel del sistema Juan Manuel Cueva Lovelle 6-71 Paquetes en UML Un paquete (package) es un grupo de elementos del modelo Los paquetes pueden tener anidados otros paquetes, as como paquetes subordinados Algunos paquetes pueden ser Subsistemas o modelos Juan Manuel Cueva Lovelle 6-72 Diagramas de mdulos Muestran la asignacin de clases y objetos a mdulos en la vista fsica de un sistema Notacin Booch Los primeros tres iconos denotan ficheros icono programa principal denota el fichero que contiene la raz del programa icono especificacin denota el fichero cabecera del mdulo icono cuerpo denota el fichero cuerpo de cada mdulo Estos dos ltimos iconos pueden agruparse en un icono especificacin con sombra Todo nombre de fichero debe ser nico Las dependencias entre mdulos se refieren a dependencias de compilacin Se representan por una flecha que apunta al mdulo respecto al cual existe la dependencia Los subsistemas son agrupaciones de mdulos relacionados lgicamente Juan Manuel Cueva Lovelle 6-73 Diagramas de mdulos Ejemplo en la notacin de Booch Cuatro mdulos se muestran con sus especificaciones y cuerpos agrupados Dos mdulos son solamente especificaciones y sirven para definir tipos y constantes comunes Juan Manuel Cueva Lovelle 6-74 Ejemplo de diagrama de componentes en Rose Juan Manuel Cueva Lovelle 6-75 Diagramas de mdulos Subsistemas Ejemplo en la notacin de Booch Un subsistema es un agregado que contiene otros mdulos y otros subsistemas Se necesita un nombre para cada subsistema Algunos de los mdulos englobados en un subsitema se consideran pblicos, que quiere decir que pueden ser utilizados por otro mdulo fuera del subsistema Un subsistema puede tener dependencias respecto de otros susbsistemas o mdulos. Se usa la flecha dirigida para indicarlo como en el caso de los mdulos Juan Manuel Cueva Lovelle 6-76 Diagramas de procesos Muestran la asociacin de procesos a procesadores en la vista fsica de un sistema Notacin Booch Se utilizan diagramas de procesos para mostrar la asignacin de procesos a procesadores en el diseo fsico de un sistema Los tres elementos bsicos de un diagrama de procesos son Procesadores : Elementos hardware capaces de ejecutar programas Dispositivos : Elementos hardware incapaces de ejecutar programas Conexiones : Comunicacin entre procesadores y dispositivos Pueden definirse iconos especficos para los elementos del diagrama de procesos Puede haber anidamiento de procesadores y dispositivos Se puede adoptar alguna poltica de planificacin de la ejecucin de procesos en un procesador Pueden aadirse especificaciones en modo texto Juan Manuel Cueva Lovelle 6-77 Diagramas de procesos Ejemplo en la notacin de Booch Juan Manuel Cueva Lovelle 6-78 Ejemplo de Diagrama Desplegable en Rose Juan Manuel Cueva Lovelle 6-79 Notacin del modelo funcional OMT Juan Manuel Cueva Lovelle 6-80 Aplicacin de las notacin Las herramientas para el soporte automtico del diseo orientado a objetos Las herramientas no hacen diseo Las herramientas se pueden aplicar a sistemas grandes y pequeos Notacin independiente del lenguaje Juan Manuel Cueva Lovelle 6-81 Criterios de seleccin de herramientas de AyDOO Soporte completo de una o ms metodologas Soporte completo de cada notacin Interfaz de usuario amigable Consistente con la notacin Debe realizar comprobaciones mientras se est diseando Ejemplo: No debe permitir que una clase padre herede de una clase hija Generacin de cdigo automtico Normalmente generan declaraciones y algunos mtodos bsicos como constructores y destructores Ingeniera inversa a partir de cdigo legado o cdigo generado A partir de ficheros con programas se obtiene los esquemas de la notacin Cambios en el cdigo implican cambios en la notacin Seguimiento de los requisitos Reflejar en el diseo y en el cdigo los requisitos Generacin automtica de la documentacin de la aplicacin La documentacin producida debe ser Completa Bien diseada, cmoda de utilizar y de usar Personalizable (se genera en formatos estndar que pueden ser manejados por herramientas de maquetacin estndar) Comprobacin de la consistencia y completud entre todas las vistas del sistema Ayuda en lnea completa Buena documentacin de la herramienta
B4T9-Seguridad y Protección en Redes de Comunicaciones. Seguridad Perimetral. Acceso Remoto Seguro A Redes. Redes Privadas Virtuales (VPN) - Seguridad en El Puesto de Usuario.