Lenguaje Unificado Uml

ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML
MODULO LENGUAJE UNIFICADO DE MODELADO UML ELABORADO Harold Cabrera Meza ACTUALIZADO POR Nilson Albeiro Ferreira Manzanares CORRECTOR DE ESTILO Laura Fabiola lvarez Morales Instituto Virtual de Lenguas - INVIL
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA 2013
TABLA DE CONTENIDO
PRIMERA UNIDAD .............................................................................................. 10 UNIDAD 1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO ...... 11 CAPITULO 1. QU ES UML? ........................................................................... 11 Leccin 1. Por qu Aprender UML? ............................................................... 12 Leccin 2. UML no es un mtodo .................................................................. 13 Leccin 4. Beneficios de Esta Tecnologa ..................................................... 15 Leccin 5. En donde Utilizamos UML ............................................................ 16 CAPITULO 2. MODELOS ................................................................................. 17 Leccin 6. Modelos ....................................................................................... 17 Leccin 7. Notas y Dependencias ................................................................. 18 Leccin 8. Elementos comunes a todos los diagramas.................................. 19 Leccin 9. Fases de Desarrollo ..................................................................... 20 Leccin 10. Herramientas Para Modelado ..................................................... 21 CAPITULO 3. MODELADO ESTRUCTURADO ................................................ 24 Leccin 11. Bloques de Construccin de UML ............................................... 25 Leccin 12. Diagramas .................................................................................. 33 Leccin 13. Diagramas de Clase ................................................................... 35 Leccin 14. Caractersticas avanzadas de las clases y relaciones ................ 38 Leccin 15. Herencia y polimorfismo ............................................................. 46 SEGUNDA UNIDAD ............................................................................................. 48 UNIDAD 2. CARACTERSTICAS DEL MODELADO UML ................................... 49 CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML ......................................... 49 Leccin 16. Diagramas de Objetos ................................................................ 49 Leccin 17. Diagramas de Casos de Uso ...................................................... 50 Leccin 18. Diagramas de Interaccin ........................................................... 54 Leccin 19. Diagrama de Secuencia.............................................................. 55 Leccin 20. Diagrama de Colaboracin ......................................................... 56 2
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 21. Diagramas de Actividades .......................................................... 57 CAPITULO 5. MODELADO DINMICO ............................................................ 61 Leccin 22. Eventos y seales....................................................................... 61 Leccin 23. Mquinas de Estado ................................................................... 62 Leccin 24. Tiempo y Espacio ....................................................................... 64 Leccin 25. Transicin y Accin .................................................................... 66 Leccin 26. Diagramas de Estado.................................................................. 66 CAPITULO 6. MODELADO ARQUITECTNICO ............................................. 67 Leccin 27. Componentes, despliegue, colaboraciones y patrones ............... 67 Leccin 28. Frameworks ................................................................................ 70 Leccin 29. Diagramas de Componentes ...................................................... 71 Leccin 30. Diagramas de Despliegue .......................................................... 72 Leccin 31. Sistemas y modelos.................................................................... 72 TERCERA UNIDAD.............................................................................................. 74 UNIDAD 3. PRINCIPIOS DE UML ORIENTADO A OBJETOS ............................ 75 CAPITULO 7. DESARROLLO ORIENTADO A OBJETOS CON UML ............. 75 Leccin 32. Visin General ........................................................................... 75 Leccin 33. Fase de Planificacin y Especificacin de Requisitos ................. 76 Leccin 34. Construccin de los diagramas de casos de Uso ....................... 81 Leccin 35. Planificacin de Casos de Uso segn Ciclos de Desarrollo ........ 82 Leccin 36. Fase de Construccin del Modelo .............................................. 83 CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA ......................... 86 Leccin 37. Construccin de un Diagrama de Secuencia del Sistema........... 87 Leccin 38. Creacin de los Diagramas de Interaccin ................................. 90 Leccin 40. Construccin Diagramas de Diseo............................................ 93 Leccin 41. Implementacin y Pruebas.......................................................... 95 Captulo 9. PILARES DE LA ORIENTACIN A OBJETOS .............................. 95 Leccin 42. Abstraccin ............................................................................... 95 Leccin 43. Herencia ..................................................................................... 96 Leccin 44. Polimorfismo ............................................................................... 97 Leccin 45. Encapsulamiento ........................................................................ 98 3
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 46. Relaciones .................................................................................. 99
TABLA DE GRAFICAS
FIGURA 1: CREADORES DEL LENGUAJE UML 11 FIGURA 2: EVOLUCIN DEL LENGUAJE UML 14 FIGURA 3: NOTA 18 FIGURA 4: ELEMENTOS 19 FIGURA 5: FASES DE DESARROLLO DE UN SISTEMA SOPORTADO POR UML 20 FIGURA 6: ARGOUML EDITOR UML 22 FIGURA 7: DA EDITOR DE UML 23 FIGURA 8: ELEMENTOS UML 25 FIGURA 9: CLASES 28 FIGURA 10: ATRIBUTOS 29 FIGURA 11: OPERACIONES 29 FIGURA 12: RESPONSABILIDADES 30 FIGURA 13: OBJETOS 31 FIGURA 14: ASOCIACIN 31 FIGURA 15: ROLES 32 FIGURA 16: AGREGACIN 33 FIGURA 17: CONJUNTO DE CLASES 36 FIGURA 18: CONJUNTO DE CLASES EXTRADAS DE UN SISTEMA DE INFORMACIN 37 FIGURA 19: INTERFAZ 38 FIGURA 20: TIPOS DE DATOS 38 FIGURA 21: SEAL 38 FIGURA 22: COMPONENTE 38 FIGURA 23: NODO 39 FIGURA 24: CASO DE USO 39 FIGURA 25: SUBSISTEMA 39 FIGURA 26: NOTACIN 40 FIGURA 27: HERENCIA MLTIPLE 41 FIGURA 28: ASOCIACIN 42 FIGURA 29: INTERFACES 43 FIGURA 30: ABSTRACCIN CON UNA INTERFAZ 43 FIGURA 31: DIAGRAMA DE INTERACCIN ENTRE CLASES 44 FIGURA 32: RELACIN DE CLASES EN NOTACIN 44 FIGURA 33: OBJETO DENTRO RELACIN DE CLASES EN NOTACIN 45 FIGURA 34: ELEMENTOS CONTENIDOS EN EL PAQUETE 45 FIGURA 35: INSTANCIAS 46 FIGURA 36: DIAGRAMA DE OBJETOS 49 FIGURA 37: ACTOR 50 FIGURA 38: CASO DE USO 51 FIGURA 39: LOS ACTORES QUE INTERACTAN CON EL SISTEMA 53 FIGURA 40: CLIENTE PUEDE DEPOSITAR TEMS Y UN OPERADOR PUEDE CAMBIAR LA INFORMACIN DE UN TEM O BIEN PUEDE IMPRIMIR UN INFORME 53 FIGURA 41: DEPOSITAR TEM 53 FIGURA 42: PETICIN A UN OPERADOR 54
FIGURA 43: DISEO COMPLETO DEL DIAGRAMA DE CASOS DE USO FIGURA 44: TRANSICIONES Y ACTIVACIONES FIGURA 45: FLUJO DE CONTROL FIGURA 46: ESTADOS DE ACCIN FIGURA 47: SUBMAQUINAS FIGURA 48: TRANSICIONES FIGURA 49: BIFURCACIONES FIGURA 50: DIVISIN Y UNIN FIGURA 51: CALLES FIGURA 52: SEALES FIGURA 53: EVENTOS FIGURA 54: UN EVENTO DE CAMBIO O DE TIEMPO FIGURA 55: ESTADOS FIGURA 56: TRANSICIONES FIGURA 57: TIEMPO Y ESPACIO FIGURA 58: LOCALIZACIN FIGURA 59: DIAGRAMA DE ESTADOS CON TODOS SUS COMPONENTES FIGURA 60: COMPONENTES FIGURA 61: INTERFAZ FIGURA 62: DESPLIEGUE FIGURA 63: COLABORACIONES FIGURA 64: MECANISMOS FIGURA 65: PLANTILLA FORMADA POR UN CONJUNTO DE ABSTRACCIONES FIGURA 66: FRAMEWORKS FIGURA 67: DIAGRAMA DE COMPONENTES FIGURA 68: DIAGRAMAS DE DESPLIEGUE FIGURA 69: SISTEMAS Y MODELOS FIGURA 70: PLANIFICACIN DE CASOS DE USO SEGN CICLOS DE DESARROLLO FIGURA 71: DIAGRAMA DE SECUENCIA DEL SISTEMA PARA EL CASO DE USO FIGURA 72: DIAGRAMA DE CLASES DE DISEO SENCILLO FIGURA 73: CLASE CON NOMBRE DE RUTA FIGURA 74: HERENCIA FIGURA 75: POLIMORFISMO FIGURA 76: ENCAPSULAMIENTO FIGURA 77: ESTRUCTURA DE ENCAPSULAMIENTO FIGURA 78: TIPOS DE LNEAS QUE SIMBOLIZAN LAS RELACIONES FIGURA 79: ARGUMENTO DE ASIGNATURA FIGURA 80: GENERACIONALES FIGURA 81: ASOCIACIONES FIGURA 82: REALIZACIN 54 55 56 58 58 59 59 60 60 61 62 62 63 64 65 65 67 67 68 68 69 69 70 70 71 72 73 82 87 91 96 97 98 98 98 99 100 100 101 102
INTRODUCCIN
Unas de las etapas vitales para un diseador de software, es el anlisis y diseo de sistemas. El anlisis de sistemas es el proceso de clasificacin e interpretacin de hechos, diagnstico de problemas y manejo de la informacin para hacer mejoras al sistema, siendo el diseo la fase de planificacin, reemplazo o complementacin de un sistema organizacional existente. Para estas fases del desarrollo de software se han desarrollado diferentes modelos con los cuales se han obtenido resultados satisfactorios, mas no ptimos puesto que se han sesgado unos con otros. Es entonces cuando se plantea la necesidad de crear un mismo lenguaje que permita modelar sistemas, de manera que se pueda en cualquier momento construir software partiendo de un solo esquema de modelado, tanto estructural como orientado a objetos El Lenguaje Unificado de Modelado (Unified Modeling Lenguaje UML), es un lenguaje estndar para escribir planos de software, UML se puede utilizar para visualizar, especificar, construir y documentar los artefactos de un sistema que involucre una gran cantidad de software. UML prescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego desplegar tales sistemas. El curso acadmico denominado Lenguaje de Modelado -UML- Electiva, est orientado a hacia el manejo adecuado de las herramientas que ofrece el lenguaje de modelado orientado a objetos, desde la construccin de los diagramas de interaccin del sistema, hasta la aplicacin del modelo en un caso real de desarrollo.
JUSTIFICACIN
El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de modelado y no un mtodo o un proceso. El UML est compuesto por una notacin muy especfica y por las reglas semnticas relacionadas para la construccin de sistemas de software. UML en s mismo no prescribe ni aconseja cmo usar esta notacin en el proceso de desarrollo o como parte de una metodologa de diseo orientada a objetos.
El UML soporta un conjunto rico en elementos de notacin grficos. Describe la notacin para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cmo modelar la relacin entre esos elementos. UML tambin soporta la idea de extensiones personalizadas a travs elementos estereotipados provee beneficios significativos para los ingenieros de software y las organizaciones al ayudarles a construir modelos rigurosos, trazables y sustentables, que soporten el ciclo de vida de desarrollo de software completo.
Para los diseadores de software, UML muestra la forma en la cual se modelan diseos prcticos con los cuales a travs de los casos de usos, diagramas de interaccin se llega en conjunto con el anlisis al diseo del software de manera segura sobre casos reales detallados en los diagramas de estados, adems, UML como lenguaje se implementa en el diseo y en la base de datos, es decir, el diseo se complementa con pruebas sobre el resultado final del modelo a ser programado.
OBJETIVOS 1. Fomentar la realizacin de esquemas que representen al sistema con cierto grado de complejidad, para as desarrollar software ajustado a sus necesidades reales. 2. Especificar la estructura y comportamiento de un sistema. 3. Proporcionar diagramas y plantillas que guen en la construccin de un software orientado a objetos.
PRIMERA UNIDAD
INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO
10
UNIDAD 1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO CAPITULO 1. QU ES UML? El Lenguaje Unificado de Modelado (Unifield Modeling Lenguaje UML), es un lenguaje estndar para escribir planos de software, UML se puede utilizar para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. UML prescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. UML se puede usar para modelar distintos tipos de sistemas como por ejemplo: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego desplegar tales sistemas. UML es slo un lenguaje y por tanto es tan solo una parte de un mtodo de desarrollo de software, adems, es independiente del proceso, aunque para utilizar ptimamente se debera usar en procesos que fuesen dirigidos por los casos de uso, centrados en la arquitectura, lo interactivo e incremental.
Figura 1: Creadores del Lenguaje UML
11
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML UML es una consolidacin de muchas de las notaciones y conceptos ms usados orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares, en 1996, el Object Management Group (OMG), public una peticin con propsito de un metamodelo orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versin 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versin 1.1. El OMG estaba actualmente en proceso de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1 de abril de 1999. Leccin 1. Por qu Aprender UML? Los programadores en los inicios de los sistemas de computacin no realizaban anlisis fuertes o profundos sobre u problema a resolver, eventualmente realizaban un bosquejo o medianamente un diagrama con poca tcnica donde se daba a entender una idea mnima de lo que pensaban realizar en el proceso de programacin. A los programadores se podran considerar como temerarios en el desarrollo de aplicaciones, ya que ests se est ajustando segn los requerimientos del momento, significando un alto riesgo para las empresas o entidades donde se realice los proyectos. En la actualidad este procedimiento se considera un problema de alto riesgo para los negocios. Por tal razn los sistemas de informacin en la actualidad parten de un anlisis y diseo muy bien evaluado, donde el cliente reconozca y entienda a detalle lo que el grupo de programadores realizar y que este pueda sugerir cambios que permitan cumplir con las necesidades o cambiar de opinin frente a un proceso y aplicarlo de otra manera en el sistema, una vez el diseo sea claro y que sea de completo consentimiento del cliente, el grupo de trabajo proceder a desarrollar la solucin tal cual como se dise. A medida que el mundo evoluciona este se vuelve ms complejo y los sistemas de informacin aumentan su complejidad y se debe dar respuesta a las necesidades que se presenten. Es de reconocer que todo influye en un sistema de informacin: el hardware, software, internet, redes, base de datos y muchas ms variables que intervienen en el proceso y que se evidencian en grandes cantidades de informacin. Es por ello que si desea crear un sistema en la actualidad, se deber partir con la pregunta: Cmo se manejara un nivel tan alto de complejidad? UML es la respuesta, pues mediante este lenguaje se organizar el proceso de diseo donde los analistas, clientes, desarrolladores y todo el equipo de trabajo que 12
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML intervenga en el proyecto, comprendern y participar en la mejor solucin al problema presentado, enfrentando la complejidad que se presente y se resuelva de una manera organizada. Por ejemplo: un carro, un avin un edificio, parten de un diseo (Dibujo) muy detallado y aunque estos resultados se evidencian de forma tangible, no significa que un sistema de informacin que es intangible no cuente con su propio diseo, por el contrario, si dicho sistema cuenta con una buena planificacin en su diseo, obtendr un excelente resultado para el usuario final. Tambin es importante tener claro, que un sistema de informacin que cuente con un buen diseo (dibujo), permitir realizar fcilmente futuras modificaciones de manera puntual y precisa, ahorrando tiempo y dinero en el proceso de actualizacin en la programacin de una solucin anteriormente diseada.
Leccin 2. UML no es un mtodo Inicialmente los mtodos son una tcnica para llevar a cabo una accin, UML es un compendio de modelos que pueden ser interpretados de forma directa a una gran variedad de lenguajes de programacin como Java, C++ o Visual Basic, e incluso a tablas en una base de datos relacional o una base de datos orientada a objetos. UML se construye con modelos estndar sobre anlisis y diseo de sistemas orientados a objetos. De los ms populares se incluyen los siguientes: Catlisis: Un mtodo orientado a objetos que fusiona mucho del trabajo reciente en mtodos orientados a objetos, y adems ofrece tcnicas especficas para modelar componentes distribuidos. Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson. Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en marcha por 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 el mundo en Datos (Prentice Hall). Shlaer/Mellor continan actualizando su mtodo continuamente (la actualizacin ms reciente es el OOA96 report), y recientemente publicaron una gua sobre cmo usar la notacin UML con Shlaer/Mellor. Fusin: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un mtodo de diseo orientado a objetos estndar. Combina OMT y Booch con tarjetas CRC y mtodos formales. (www.hpl.hp.com/fusion/file/teameps.pdf) OMT: La Tcnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseo y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un mtodo que propone anlisis y diseo 13
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML interactivo, ms centrado en el lado del anlisis. Booch: Parecido al OMT, y tambin muy popular, la primera y segunda edicin de "Diseo Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, With Applications), detallan un modo ofreciendo tambin diseo y anlisis 'iterative', centrndose en el lado del diseo.
Leccin 3. Evolucin del Lenguaje UML
Figura 2: Evolucin del Lenguaje UML
14
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Desde su indicio ya se evidenciaba un buen grado de precisin que ha tenido el lenguaje de modelado unificado UML, donde muchas de las mejores tcticas en diseo le pertenecen y se espera que este lenguaje sea la base de muchas herramientas aplicadas al modelamiento visual, simulacin y desarrollo de diferentes ambientes, a medida que estas aplicaciones implementen ms desarrollos. Se deben tener en cuenta dos aspectos muy importantes en el Unificado que se logra con UML. Primero, elimina gran parte de las diferencias entre los diferentes lenguajes de modelado y mtodos previos. Segundo, unifica las diferentes perspectivas de diferentes clases de sistemas, fases de desarrollo y concretos internos. Es de destacar del xito de este lenguaje en diversos proyectos de excelentes resultados y el crecimiento de herramientas de apoyo y gran variedad de libros de aprendizaje. Como el proceso de aprendizaje debe de ser constante y dentro del e mdulo no es prudente entrar a mediar otros temas diferentes, por ello se registran las siguientes siglas que sern una incgnita que deber responde cada uno de los futuros ingenieros MSF, RUP, DSL, OMG e IBM y mirar hacia donde se inclinaran en el caso de que consideren que el lenguaje UML no cumple sus requerimientos.
Leccin 4. Beneficios de Esta Tecnologa AL utilizar el lenguaje de modela los beneficios son diversos, entre estos tenemos: 1. Minimizar Costos: esto se evidencia segn el tamao de la organizacin donde se aplique y un buen desarrollo del diseo. 2. Calidad: La aplicacin del lenguaje UML hace necesario la participacin del usuario en la definicin de requerimientos y por ende mejora notablemente un sistema segn sean las necesidades del usuario. El mantenimiento correctivo y/o reparaciones se reduce drsticamente. Algo similar ocurre en los proyectos de reingeniera. 3. Mejor soporte a la planeacin y al control de proyectos. Al desarrollarse un buen plan de trabajo donde todo un equipo de trabajo al igual que el mismo cliente han intervenido en el desarrollo, permite estandarizar distintas fases del proyecto y ser evaluado de una manera fcil por usuarios distintos al programador y permitiendo la toma de decisiones de una manera gil y oportuna. 4. Mayor independencia del personal de desarrollo o programadores. Tambin parte de un buen diseo donde todo este bien documentados permite que el equipo de desarrollares entiendan con facilidad el sistemas y puedan tener movilidad en el proyecto si verse este afectado en su calidad, ya que con 15
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML anterioridad se tienen conocimiento la labor que se va a desarrollar y no se improvisara en el proceso. 5. Mayor soporte al cambio organizacional, comercial y tecnolgico. Con UML todos los cambios que se considere para un sistema, pueden ser probados primero en papel y segn los resultados que arrojen en la planificacin y diseo se cuantificara el impacto que generen los cambios realizados antes de aplicarlo directamente en el sistema, permitiendo probar diferentes alternativas y seleccionar la ms favorable para el cliente. 6. Alto reus. Regularmente los sistemas comparten ciertas similitudes y es muy probable que partes de un diseo y rutinas de programacin puedan ser usadas por sistema, a este se le denomina reus que en ocasiones esta favorece una administracin adecuada, un bajo costo y la minimizacin de errores. 7. Mejores tiempos totales de desarrollo (de 50% o ms). Si se cumple con los pasos anteriores el tiempo de desarrollo baja drsticamente y se podra en considerar que se tendra un ahorro hasta del 50% segn el tamao del sistema. Es por ello que es de suma importancia realizar un anlisis a profundidad y dedicar el tiempo necesario para el diseo y as en las etapas de construccin, implementacin y estabilizacin se aminore el tiempo ya que los errores fueron corregidos en las fase de mayor impacto con el sistema.
Leccin 5. En donde Utilizamos UML Partamos recordando que el Lenguaje de Modelado Unificado UML, es para hacer modelos que faciliten visualizar como es y cmo queremos un sistema. Este modelado es una plantilla que se usara como gua para el desarrollo de un sistema y as dejar documentado todo el proceso de produccin del mismo. Banco y servicios financieros Telecomunicaciones, transporte Defensa/industria aeroespacial Electrnica mdica mbito cientfico Tambin se pueden modelar workflows en un sistema jurdico, diseo de hardware, etc. Estas son algunas de las reas donde el UML es utilizado, debido a que no es permitido que el sistema aplicado al control de una de estas instituciones presente errores que le puedan afectar a la concurrencia de clientes o perdida econmica a la misma institucin que la pudiese afectar fuertemente. 16
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML CAPITULO 2. MODELOS Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Leccin 6. Modelos UML Los modelos de UML que se estudiaran en esta parte son los siguientes: Diagramas de clases Diagramas de Objetos Diagrama de Actividades Diagrama de Componentes Diagrama de Despliegue Diagrama de Casos de Uso Diagrama de Secuencia Diagrama de Colaboracin Diagrama de Estados
Diagramas de clases: muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones, son los ms comunes en el modelo orientado a objetos y cubren las vistas de diseo esttico 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 diseo esttico de un sistema desde la perspectiva de casos reales. Diagrama de Actividades: es un tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema, cubren la vista dinmica de un sistema. Son especialmente importantes al modelar el funcionamiento de un sistema y resaltan el flujo de control de objetos. Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de componentes, cubren la vista esttica de un sistema. Diagrama de Despliegue: muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos, cubren la vista de despliegue esttica de una arquitectura. Diagrama de Casos de Uso: muestra un conjunto de casos de uso, actores y relaciones, cubren la vista de casos de uso esttica de un sistema. Diagrama de Secuencia: es un diagrama de interaccin que resalta la ordenacin 17
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML temporal de los mensajes. Diagrama de Colaboracin: es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensaje. Diagrama de Estados: Muestra una mquina de estados, que consta de estados, transiciones, eventos y actividades, cubren la vista dinmica de un sistema, resaltan el comportamiento dirigido por eventos de un objeto.
Leccin 7. Notas y Dependencias Notas Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar informacin en un formato libre, cuando la notacin del diagrama en cuestin, nos permite expresar dicha informacin de manera adecuada. Una nota se representa como un rectngulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto solo como unido a un elemento por medio de una lnea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
Figura 3: Nota
Dependencias La relacin de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habra que revisar el elemento origen). Una dependencia se representa por medio de una lnea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a l est la flecha).
18
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 8. Elementos comunes a todos los diagramas Un elemento es considerado como una abstraccin y dichos elementes se clasifican en estructurales, de comportamiento, de agrupacin y de anotacin. En esta leccin daremos una descripcin general, ya que a medida que se profundice en el contenido del mdulo se dar respuesta a cada uno de los trminos de relaciones a este espacio.
Figura 4: Elementos
Elementos de agrupamiento: Se realiza mediante el elemento de agrupacin denominado paquete, es presentada por una caja que dentro de esta se puede se descompuesto un modelo. Tambin aparecen los Frameworks, modelos y subsistemas como a variaciones o tipos de paquetes.
Elementos estructurales: Es hace referencia a la parte esttica de un modelo, representando elementos conceptuales o fsicos. Son siete los tipos de elementos estructurales que son: Clase, Interfaz, Colaboracin, Caso de uso, clase activa, componente, y nodo. Es importante tener muy claro que los nodos y componentes representan elementos fsicos. 19
Al igual que los elementos de agrupacin en estos elementos tampoco encontramos con variaciones a los siete elementos mencionados que se identifican como: Tipos de clase: actores, seales, utilidades, Tipos de clases activas: procesos e hilos y Tipos de Componentes: aplicaciones, documentos, archivos, bibliotecas, pginas y tablas. Elementos de comportamiento: Es la parte dinmica de un modelo y se ve representada por los verbos que representan una funcin sobre tiempo y espacio. Se identifican dos tipos de elementos de comportamiento: la interaccin y la mquina de estado. Elementos anotacin: Son los comentarios explcitos o modelo UML y se aplican para describir, iluminar y remarcar modelo. Solo presenta un tipo de elemento de anotacin que este re registraran los comentarios y limitaciones asociados coleccin de datos. muy detallados de un algunos elementos del es denominado Nota y a un elemento o una
Leccin 9. Fases de Desarrollo Partamos identificando que un modelo es la representacin simple de la realidad, estas fases se asemejan al ciclo de vida del desarrollo de software.
Figura 5: Fases de Desarrollo de un Sistema Soportado por UML
20
Anlisis: es donde se lleva el lenguaje natural a un lenguaje tcnico que es fcilmente interpretado por desarrollador de un sistema. Diseo: es la forma en la que se muestra la forma en la que se debe construir un sistema para dar cumplimiento a unos requerimientos de un cliente o usuario. De un buen diseo depende el resultado de un sistema. Programacin: son todas las actividades necesarias para transformar los requerimientos de un usuario plasmado en un diseo y convertido en un sistema de software. Prueba: es la parte donde se verifica, valida y se evidencia la calidad del producto o sistemas de software desarrollado. Anlisis de Requerimiento: es la fase donde el propsito fundamental es dejar muy claro cules son las necesidades del usuario y los requerimientos.
Leccin 10. Herramientas Para Modelado El kit ms importante en cuanto a herramientas prcticas y fciles de conseguir son: papel, lpiz, borrador y saca punta, para realizar un diseo UML. Puede sonar raro cuando estamos hablando de software y tecnologa pero estos materiales son formidables para realizar diferentes tipos de diseo, en cualquier rea. En esta leccin no se entrara a detallar herramientas o aplicaciones ya que esta funcin la realizar diversos sitios web y los sitios principales de cada herramienta a los cuales les corresponden convencer a los futuros ingenieros.
A continuacin se relacionarn varias herramientas de modelado gratuito, esto no significa que son necesariamente software libre y quedarn muchsimas sin descubrir o recomendar que pudieran ser mejores, pero esto depende de la autonoma de cada uno de los diseadores y tambin de los recursos econmicos en el caso de que se requiera obtener una licencia. Las recomendaciones que se registran a continuacin son tomadas de la pgina http://www.rfsdigital.com/2012/01/herramientas-para-modelado-uml.html
1. ArgoUML (Clic para que acceda a la pgina principal de la aplicacin)
21
Figura 6: ArgoUML Editor UML
ArgoUML es un editor UML gratuito que tiene compatibilidad con el estndar UML 1.4. Permite la exportacin a varios formatos grficos y tiene la disponibilidad de perfiles para varios lenguajes de programacin. Es mi herramienta favorita, aunque solo tiene soporte para UML 1.4 (la ltima versin de UML es 2.4.1). Al ser programado en Java, ArgoUML tiene la caracterstica de ser multiplataforma. Entre sus caractersticas resalta lo siguiente: Exportacin de diagramas a diferentes formatos Generacin de cdigo Soporte para bases de datos Soporte cognitivo: 22
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Crticas de diseo creado, listas de cosas por hacer (To Do Lists), correcciones automticas, entre otros. Comprensin y solucin del problema
2. Da (Clic para que acceda a la pgina principal de la aplicacin)
Figura 7: Da Editor de UML
Da es un programa de creacin de diagramas, similar al programa Visio de la suite de ofimtica de Microsoft Office. Est basado en GTK+, biblioteca con objetos y funciones para la interfaz grfica de usuario, y tiene licencia GPL. Dispone de una gran serie de extensiones que permiten la elaboracin de diagramas entidad-interrelacin, UML, flujo de datos, diagramas de red, entre otros.
3. Frame UML (Clic para que acceda a la pgina principal de la aplicacin) Herramienta gratuita UML de fcil uso con soporte para UML 2, est pensado 23
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML para funcionar sobre Windows. Permite la generacin de cdigo desde el modelo. Tiene soporte para 12 tipos de diagramas, excepto diagramas de objetos. 4. StarUML (Clic para que acceda a la pgina principal de la aplicacin) StarUML es una herramienta de fcil uso que ayuda a generar diagramas compatibles con la suite de ofimtica de Microsoft Office. Tiene cdigo es compatible con C++ y Java. Y se puede empezar a dibujar manualmente o hacer uso de plantillas que contienen archivos de instalacin, para modificarlas pensado en las persona que no estn acostumbrada o que no hayan trabajado con anterioridad en modelamiento UML. 5. Tiny UML (Clic para que acceda a la pgina principal de la aplicacin) TinyUML es una herramienta gratuita de modelado UML de fcil uso y de rpida creacin de diagramas UML 2 implementado en la plataforma Java, requiere Java SE 6.
6. Eclipse (Clic para que acceda a la pgina principal de la aplicacin) La aplicacin de eclipse no funciona como una herramienta directa de UML, sino que requiere una extensin para realizar el modelado, adems que facilita que los diagramas que se realicen en dicha herramienta se conviertan en cdigo. Se recomienda descargar las siguientes extensiones para ser aplicada al eclipse y poder realizar el diseo en este programa. UML2 UML2 Tools
Seleccione la herramienta segn se ajuste a sus requerimientos y considere que la ms fcil manejar y a medida que su nivel prctico y de conocimiento en el manejo del lenguaje de modelado le permita escoger la herramienta ms avanzada. Es importante entender que hay herramientas muy buenas, pero no necesariamente significa que ser la que el diseador utilice, ya que puede considerar la herramienta menos conocida pero que le arroje excelentes resultados y el nivel de manejo sea cmodo. Se recomienda Eclipse y StarUML, pero sintase libre de tomar la mejor decisin que usted considere. Es muy posible que se trabaje con una sola aplicacin para dar cumplimiento a un desarrollo acadmico, que se dar a conocer directamente en el espacio donde se considere necesario.
CAPITULO 3. MODELADO ESTRUCTURADO Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje y esto requiere aprender tres elementos principales: los bloques bsicos de construccin 24
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML de UML, las reglas que dictan cmo se pueden combinar estos bloques bsicos y algunos mecanismos comunes que se aplican a travs de UML. Una vez comprendidas estas ideas, se pueden leer los modelos UML y crear algunos modelos bsicos. Leccin 11. Bloques de Construccin de UML El vocabulario de UML incluye tres clases de bloques de construccin Elementos en UML Hay 4 tipos de elementos en UML, elementos estructurales, elementos de comportamiento, elementos de agrupacin y elementos de anotacin:
Figura 8: Elementos UML
25
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Elementos Estructurales Nombre Descripcin Es una coleccin de operaciones que especifica un servicio de una clase o componente, representa el comportamiento completo de una clase o componente Smbolo
Interfaz
Se definen como una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento Colaboracin cooperativo mayor que la suma de los comportamientos de sus elementos las colaboracin representan la implementacin de patronesque forman un sistema.de secuencias de Es una descripcin acciones que un sistema ejecuta y que produce un resultado observable de inters para un actor particular. Se utiliza para estructurar el comportamiento en un modelo Es un clase objetos tienen uno o mas procesos o hilos de ejecucin 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 elementos. Es una parte fsica y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementacin de dicho conjunto Representa tpicamente e empaquetamiento fsico de diferentes elementos lgicos, como clases interfaces y colaboraciones Es un elemento fsico que existe en tiempo Nodo de ejecucin y representa un recursos computacional que dispone de memoria y con frecuencia capacidad de procesamiento
Caso de Uso
Clase Activa
Componente
Nodo1
26
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos) son los elementos estructurales bsicos que se pueden incluir en el modelo UML. Tambin existen variaciones de estos siete elementos, tales como actores, seales, procesos, hilos y aplicaciones, documentos, archivos, bibliotecas, pginas y tablas. Los elementos de comportamiento: son las partes dinmicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y en el espacio. Interaccin: e s un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propsito especifico Mquina de Estados: es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos Estos dos elementos (interacciones y mquinas de estado) son los elementos de comportamiento que se pueden incluir de un modelo UML, estos elementos estn conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos. Los Elementos de agrupacin: son las partes organizativas de los modelos UML. Estos son las cajas en las que pueden descomponerse un modelo Paquete: es un mecanismo de propsito general para organizar elementos en grupos. En los paquetes se pueden agrupar los elementos estructurales, de comportamiento e incluso otros elementos de agrupacin Los paquetes son los elementos de agrupacin bsicos con los cuales se puede organizar un modelo UML. Tambin hay variaciones, tales como los framework, los modelos y los subsistemas. Relaciones: Existen cuatro tipos de la relaciones en UML Dependencias Asociaciones Generalizaciones Realizacin Estas relaciones son los bloques bsicos de construccin para las relaciones de UML.
27
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Relaciones en UML Dependencia: es una relacin semntica entre dos elementos, en la cual un cambio a un elemento puede afectar el significado de otro elemento. Asociaciones: es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objeto y representan una relacin estructural entre un todo y sus partes. Diagramas: un diagrama es la representacin grfica de un conjunto de elementos, visualizando la mayora de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema, un diagrama representa una vista resumida de los elementos que constituyen un sistema. (Los tipos de diagramas que utiliza UML se mencionan en el Numeral 1.1.2. de este mdulo). Clases: una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Las clases pueden representar cosas como hardware, software o solo conceptuales y tambin forman parte de una distribucin equilibrada de responsabilidades en el sistema UML representa una representacin grfica de las clases como se muestra en la figura.
Figura 9: Clases
Componentes de las Clases Una clase es una descripcin de un conjunto de objetos que comparten los mimos atributos, operaciones, relaciones y semnticas. Grficamente una clase se representa como un rectngulo, en el cual se describen las caractersticas de los objetos que representa, entre ellos tenemos.
28
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML 1. Nombre: una clase debe contener un nombre que la identifique, compuesto por cualquier nmero de letras y nmeros exceptuando 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, adems, una clase puede o no contener atributos. Por ejemplo un atributo de la clase estudiante es el nombre, apellido, fecha Nacimiento, etc.
Figura 10: Atributos
3. Operaciones: es una abstraccin de algo que puede hacer un objeto y que es compartido por todos los objetos de la clase. Las clases pueden tener o no operaciones. Ejemplo: La clase estudiante puede tener los objetos generados por ella: matricular, evaluar, aprobar y estas operaciones son comunes a todos los objetos que se describen a travs de la clase estudiante.
Figura 11: Operaciones
4. Responsabilidades: Al crear una clase, se est expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento. De forma ms general los atributos y operaciones son las caractersticas por medio de la cuales se llevan a cabo las responsabilidades de la clase. Grficamente las responsabilidades se pueden expresar en un comportamiento separado al final del icono de la clase.
29
Figura 12: Responsabilidades
Usos Comunes de las Clases Las clases se utilizan para modelar y representar el conjunto de elementos de un sistema de manera general (abstracciones), para determinar los problemas que se intenta resolver y as implementar una solucin. Para definir las clases que intervienen dentro de un sistema se recomienda como puntos de partida las siguientes consideraciones: Identificar aquellas cosas que utilizan los usuarios o programadores para describir el problema o la solucin. 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 pequeas Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de la clase que sean importantes, como tambin sus atributos y operaciones Objetos Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, segn la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase.
30
Figura 13: Objetos
Asociaciones Es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro. Dada una asociacin entre dos clases, se puede navegar desde un objeto de una clase hasta el objeto de otra clase, y viceversa. Una asociacin que conecta dos clases se dice binaria, s conecta ms de dos clases se denomina asociacin n-arias, las asociaciones se utilizarn cuando se quieren representar relaciones estructurales. Caractersticas de las Asociaciones y operaciones Nombre de la Asociacin y Direccin El nombre de la asociacin se utiliza para describir la naturaleza de la relacin, es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un pequeo tringulo negro slido que indique la direccin y permita leer el nombre de la asociacin. En el ejemplo se puede leer la asociacin como Director manda sobre Empleado.
Figura 14: Asociacin
Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la informacin que se presenta, con el consiguiente riesgo de saturacin. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregacin y de herencia no se suele poner el nombre. 31
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Multiplicidad La multiplicidad es una restriccin que se pone a una asociacin, que limita el nmero de instancias de una clase que pueden tener esa asociacin con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un nmero 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 ms. Con una combinacin 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 ms). Roles Un rol es simplemente la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo.
Figura 15: Roles
Para indicar el papel que juega una clase en una asociacin se puede especificar un nombre de rol. Se representa en el extremo de la asociacin junto a la clase que desempea dicho rol. 32
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Agregacin El smbolo de agregacin es un diamante colocado en el extremo en el que est la clase que representa el todo.
Figura 16: Agregacin
Leccin 12. Diagramas Un diagrama es una presentacin grfica de un conjunto de elementos, que la mayora de las veces se dibuja como un conjunto de elementos relacionados. Los diagramas se utilizan para representar un sistema desde diferentes perspectivas, por esto UML ha definido varios diagramas que permiten centrarse en diferentes aspectos del sistema de manera independiente. Un diagrama es una proyeccin grfica de los elementos que configuran un sistema. Por ejemplo, se podra tener cientos de clases en el diseo de un sistema de recursos humanos de un empresa, pero no se podra ver la estructura o el comportamiento de ese sistema observando un gran diagrama con todas sus clases y relaciones, es entonces preferible realizar varios diagramas que especifiquen las vistas relevantes solamente a ese subsistema definido, este tipo de manejo de diagramas representativos por clases permite realizar agrupaciones que muestran el funcionamiento general del sistema de forma particular pero denotando el funcionamiento general del sistema con todos sus elementos constitutivos. Con el modelado de sistemas se obtienen deferentes tipos de vistas, las vistas estticas de los sistemas en UML se representan con 4 tipos de diagramas que se describen a continuacin Diagramas Estructurales Los cuales comprenden los siguientes diagramas Diagramas de Clases Representa un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Los diagramas de clases los diagramas ms comunes en el modelado de sistemas orientados a objetos. Estos diagramas se utilizan para describir las vista de diseo esttica de un sistema, incluyen clases activas se utilizan para cubrir la vista de procesos esttica de un sistema 33
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Diagramas de Objetos Representa un conjunto de objetos y sus relaciones. Se utiliza para describir estructuras de datos y las instancias de los elementos encontrados en los diagramas de clases. Cubren la vista de diseo esttica o la vista de proceso esttica de un sistema al igual que los diagramas de clases. Pero desde la perspectiva de casos reales prototipos. Diagramas de Componentes Muestra un conjunto de componentes y relaciones, se utilizan para describir la vista de implementacin esttica de un sistema, se relacionan con los diagramas de clases en que un componente normalmente se corresponde con una o ms clases. Interfaces o colaboraciones Diagramas de despliegue Muestra un conjunto de nodos y sus relaciones, se utilizan para describir la vista de despliegue esttica de una arquitectura, se relacionan con los diagramas de componentes en que un nodo normalmente incluye uno o ms componentes. Diagramas de Comportamiento Los cuales estn compuestos por los siguientes diagramas Diagramas de casos de uso En el modelado orientado a objetos los diagramas de casos de uso, son los que representan en general el funcionamiento del sistema siendo estos los ms utilizados como base del desarrollo de un modelo real, representan casos de uso, actores y relaciones, se utilizan especialmente para organizar y modelar el comportamiento de un sistema. Diagramas de Secuencia Es un diagrama de interaccin que resalta la ordenacin temporal de los mensajes, este presenta un conjunto de objetos y los mensajes enviados por ellos. Los objetos suelen ser instancias con nombre, pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos, se utilizan para describir la vista dinmica de un sistema. Diagramas de colaboracin Son diagramas de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes, pueden representar instancias de otros elementos como colaboraciones, componentes y nodos. Se utilizan para describir la vista dinmica de un sistema. 34
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Diagramas de estado Representan una mquina de estados constituida por estados, transacciones, eventos y actividades, se utilizan para representar la vista dinmica de un sistema son especialmente importantes para modelar el comportamiento de una interfaz, clase o una colaboracin, resaltan en comportamiento dirigido por eventos de un objeto. Diagrama de Actividades Muestra el flujo de actividades en un sistema, muestra el flujo secuencial o ramificado de actividades y los objetos en los que acta, son importantes para modelar la funcin de un sistema as como para resaltar el flujo de control entre objetos
Leccin 13. Diagramas de Clase Un diagrama de clases de uso muestra un conjunto de interfaces, colaboraciones y sus relaciones. Grficamente, un diagrama de clases es una coleccin de nodos y arcos. Los diagramas de clases contienen normalmente los siguientes elementos, clases, interfaces, colaboraciones, relaciones de dependencia, generalizacin y asociacin. Los diagramas pueden tambin notas, restricciones, paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes ms grandes. Usos de los diagramas de clases Se utilizan para modelar la vista esttica de un sistema, muestra principalmente los requisitos funcionales de un sistema y los servicios que el sistema debe proporcionar a sus usuarios finales Los diagramas de clases se utilizan cuando se modela la vista de diseo de un sistema de la siguiente forma: Para modelar el vocabulario de un sistema El modelado del vocabulario de un sistema implica tomar decisiones sobre que abstracciones son parte del sistema en consideracin y cuales caen fuera de sus lmites. Los diagramas de clases se utilizan para especificar estas abstracciones y sus responsabilidades Para modelar colaboraciones simples Una colaboracin es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de todos los elementos. 35
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Cuando se crea un diagrama de clases, se est modelando una parte de los elementos y las relaciones que configuran la vista de diseo del sistema, por esta razn, cada diagrama de clases debe centrarse en una colaboracin cada vez. Para modelar una colaboracin se debe tener en cuenta: Identificar los mecanismos que se quiere modelar, un mecanismo representa una funcin o comportamiento de la parte del sistema que se est modelando que resulta de la interaccin de una sociedad de clases, interfaces y otros elementos. Identificar las clases, interfaces y otras colaboraciones que participan en esta colaboracin identificando las relaciones entre estos elementos. Usar escenarios para recorrer la interaccin entre estos elementos. Identificar las responsabilidades y hacer un reparto equilibrada de ellas en los elementos que componen el sistema. Por ejemplo la siguiente figura muestra un conjunto de clases que muestran el sistema de facturacin y control de ventas de una empresa, las clases se centran en la forma como se maneja la facturacin de inmuebles y productos de consumo. Aparece una clase abstracta llamada factura que muestra a su vez 2 hijos factura comestibles y factura inmuebles a su vez las dos clases se muestran como partes de otra clase denominada vendedor. La clase ventas tiene una asociacin uno a uno con vendedor y una asociacin uno a muchos con controlvendedor. No se muestran atributos ni operaciones para la clase ventas, pero s se muestran sus responsabilidades.
Figura 17: Conjunto de Clases
Para modelar un esquema lgico de base de datos Este esquema representa el plano que permite el diseo conceptual de la base de 36
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML datos sea para una base de datos relacional o una base de datos orientada a objetos. Para modelar un esquema tenemos en cuenta: Identificar las clases que van a ser persistentes en el diseo 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 atencin en las 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 manipulacin de datos dentro de la base de datos La figura muestra un conjunto de clases extradas de un sistema de informacin que determina las relaciones entre los estudiantes, el profesor y el curso que el estudiante va a estudiar
Figura 18: Conjunto de Clases Extradas de un Sistema de Informacin
El anterior diagrama muestra en detalle cada una de las clases con sus respectivos atributos, los cuales permiten construir la base de datos fsica, comenzando por la parte inferior izquierda se encuentra las clases estudiantes, curso y profesores, hay una asociacin. 37
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Las clases se han marcado como persistentes, es decir, sus instancias se han concebido para almacenar en una base de datos u otra forma de almacenamiento persistente.
Leccin 14. Caractersticas avanzadas de las clases y relaciones El tipo ms importante de clasificador en UML es la clase, una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Sin embargo, las clases no son el nico tipo de clasificador, existen otros tipos de clasificadores que ayudan a modelar: Interfaz: es una coleccin de operaciones que especifican un servicio de una clase o componente
Figura 19: Interfaz
Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos primitivos predefinidos.
Figura 20: Tipos de Datos
Seal: la especificacin de un estmulo asncrono enviado entre instancias
Figura 21: Seal
Componente: una parte fsica y reemplazable de un sistema que conforma y proporciona la realizacin de un conjunto de interfaces.
Figura 22: Componente
Nodo: un elemento fsico que existe en tiempo de ejecucin y representa 38
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML un recurso computacional, generalmente con alguna memoria y a menudo capacidad de almacenamiento.
Figura 23: Nodo
Caso de uso: descripcin de una secuencia de acciones, incluye variantes, que se ejecuta un sistema y produce un resultado observable para un actor particular
Figura 24: Caso de Uso
Subsistema: agrupacin de elementos, algunos de los cuales constituyen una especificacin del comportamiento de los otros elementos contenidos
Figura 25: Subsistema
Los clasificadores descritos anteriormente proporcionan al modelado de sistemas una vista general de comportamiento del sistema mostrndolo en detalle en sus atributos y operaciones
Generalidades de las clases Es necesario saber que para el modelado de sistemas con UML, las clases muestran en la definicin de sus atributos ciertos tipos de smbolos, los cuales determinan si los elementos asociados a cada clase son pblicos o privados por ejemplo: Si la marca de elemento es un +, indica que este elemento es de acceso pblico y por lo tanto se pueden operar desde cualquier instancia del sistema. Por el contrario, si el signo es -, indica que este elemento solo es de uso exclusivo de la clase que lo contiene. Otro caso en los cuales los elementos de la clase son por decirlo de alguna 39
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML semi privados, solo se relacionan con las clases que han sido descendientes de la clase padre y estas se marcan con el smbolo #. Cuando se usa una clase, es probable que se deseen caractersticas de otras clases y tambin permitir que otras clases ms especficas hereden caractersticas de ella. Tambin se puede especificar que una clase no puede tener hijos, a este elemento se le llama hoja y se especifica escribiendo la propiedad leaf bajo el nombre de la clase. Otra caracterstica de las clases, es cuando esta no tiene padres, este tipo de clases se denomina raz y se denota escribiendo debajo del nombre de la clase root. Podemos observar el siguiente ejemplo de notacin:
Figura 26: Notacin
Las clases tienen muchas operaciones entre s, las que se heredan entre clases se denominan polimrficas esto ocurre cuando los objetos han ejecutado una operacin que est definida en la clase que los contiene pero con la diferencia de que la operacin cambia de significado dependiendo del contexto donde se est ejecutado. Generalidades de las relaciones Al modelar los elementos que constituyen el vocabulario de un sistema, tambin hay que modelar cmo se relacionan entre s estos elementos, las relaciones de dependencia, las generalizaciones y las asociaciones son los tres bloques de construccin de relaciones ms importantes de UML. Observemos el comportamiento de estas relaciones.
40
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Relaciones de Dependencia: Una dependencia es una relacin de uso, la cual especifica que un cambio en la especificacin de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente a la inversa. Grficamente, una dependencia se representa como una lnea continua dirigida hacia el elemento del que se depende. Las dependencias se deben aplicar cuando se quiera representar que un elemento utiliza a otro Relaciones de Generalizacin Una generalizacin es una relacin entre un elemento (superclase o padre) y un tipo ms efectivo de ese elemento (subclase o hijo). Por ejemplo, se puede encontrar la clase general ventana junto a un tipo ms especfico ventaconmarco, con una relacin de generalizacin del hijo al padre, el hijo ventaconmarco heredar la estructura y comportamiento del padre ventana, en una generalizacin la instancia del hijo pueden usarse donde quiera que se puedan usar las instancias del padre. La generalizacin se manifiesta en la herencia simple que a veces es suficiente en la mayora de las veces, aunque, la herencia mltiple es ms adecuada, grficamente se muestra de la siguiente forma:
Figura 27: Herencia Mltiple
En la figura anterior se muestra la clase activo con tres hijos: CuentaBancaria, inmueble y valor dos de estos hijos (CuentaBancaria, Inmueble) tienen sus propios hijos por ejemplo Accin y Bono son ambos hijos de valor Dos de estos hijos (CuentaBancaria, Inmueble) heredan de varios padres. inmueble por ejemplo, es un tipo de activo, as como un tipo de Elemento-Asegurable y CuentaBancaria, es un tipo de activo as como un ElementoConInteres y un ElementoAsegurable
41
Relaciones de Asociacin Una asociacin es una relacin estructural que especifica que los objetos de un elemento se conectan a los objetos de otro, por ejemplo, una clase biblioteca podra tener una asociacin uno a muchos con clase libro, indicando que cada instancia de libro pertenece a una instancia de biblioteca, adems, dado un libro, se puede encontrar su biblioteca, y dando una biblioteca se puede navegar hacia todos los libros, grficamente, un asociaciones se representa con una lnea continua entre la misma o diferentes clases. Las relaciones se utilizan para mostrar relaciones estructurales. En la siguiente asociacin simple se muestra como se hace la navegacin entre objetos, por ejemplo al modelar una asociacin entre 2 objetos como Usuario y Clave se tiene que un dado un Usuario se puede encontrar las correspondientes Claves, pero dada una Clave no se podra identificar al Usuario correspondiente.
Figura 28: Asociacin
La lnea representa una asociacin y la fecha indica la direccin del recorrido Interfaces, Tipos y roles Interfaz El manejo de las interfaces dentro del UML es importante ya que proporcionan al modelador un registro exacto de las fronteras existentes entre los diferentes procesos del sistema, con lo cual se pretende observar al sistema en sus componentes integrales para as determinar que procesos se pueden afectar sin que se afecten los otros. La construccin de interfaces permite tambin el manejo de libreras estndar reutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sin necesidad de afectar el funcionamiento general del sistema. Se entiendo como interfaz como una coleccin de operaciones que sirven para especificar un servicio de una clase o un componente. Cada interfaz ha de tener un nombre que la distingue de otras interfaces, el nombre de la interfaz puede ser simple o de camino cuando en este se indica el nombre de la interfaz y el paquete en el que se encuentre.
42
Figura 29: Interfaces
Operaciones de las Interfaces Al contrario de las clases y los tipos, las interfaces no especifican ninguna estructura, las interfaces no incluyen atributos ni mtodos, pero estas pueden contener cualquier nmero de operaciones. La siguiente notacin hace referencia a una interfaz donde se manifiesta de manera grfica su nombre y operaciones a diferencia de la notacin del crculo presentada anteriormente. Proporciona un mecanismo para modelar la conformidad esttica y dinmica de una abstraccin con una interfaz en un contexto especfico
Figura 30: Abstraccin con una Interfaz
Ntese en la representacin el nombre <<interface>> como identificador de la interface definida. Las relaciones entre interfaces se realizan de la misma manera como se relacionan con las clases puesto que las relaciones son del mismo tipo, para recordar: relaciones de generalizacin, relaciones de asociacin y relaciones de dependencia. Como se mostr anteriormente las interfaces se pueden denotar mostrndose como un crculo o con sus operaciones, dentro de un diagrama de interaccin entre clases los resultados para mostrar las relaciones entre las clases a travs de las interfaces se expresa de la siguiente manera: 43
Figura 31: Diagrama de Interaccin entre Clases
La primera forma es la sencilla en la cual se muestra la conexin de dos clases a travs de un circulo que representa la interfaz con la cual se comunican dichas clases, la segunda forma, muestra de manera ms detallada las operaciones con las cuales interactan las clases definidas antes y despus de la interface, ntese como se representan las relaciones de dependencia de la misma forma como se mostr en las relaciones entre clases. Tipos y roles Un rol representa un comportamiento de una entidad que participa en un contexto particular, por ejemplo consideremos una instancia de una clase denominada profesor, este profesor puede ser de matemticas, sociales, informtica, fsica, etc, para cada rol generado de clase profesor, se deduce que las propiedades cada rol son exclusivas y en ningn momento pueden tomar propiedades de un rol que no le corresponda. Para representar el rol que representa un objeto dentro de una relacin de clases en notacin UML se tiene por ejemplo:
Figura 32: Relacin de Clases en Notacin
44
Figura 33: Objeto Dentro Relacin de Clases en Notacin
La figura anterior representa una asociacin de clases con una interfaz especfica, como se ve existe una asociacin de entre las clases persona y empresa en cuyo contexto personal juega un rol llamado e, cuyo tipo es empleado
Paquetes e Instancias Un paquete es un mecanismo de propsito general para organizar elementos en grupos, grficamente un paquete se representa como una carpeta. Cada paquete a de contener un nombre que lo distingue de los dems.
Figura 34: Elementos Contenidos en el Paquete
Un paquete puede contener otros elementos incluyendo clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas en incluso otros paquetes. 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 manifestacin concreta de una abstraccin a la que se puede aplicar un conjunto de operaciones y que posee un estado que almacena el efecto de las operaciones. Grficamente una instancia se representa subrayando su nombre.
45
Figura 35: Instancias
Las instancias no aparecen aisladas, casi siempre estn ligadas a una abstraccin. La mayora de las instancias que se modelan en UML sern instancias de clases (llamadas objetos), aunque se pueden tener instancias de otros elementos, como componentes, nodos, casos de usos y asociaciones. En sentido general, un objeto es algo que ocupa espacio en el mundo real o conceptual y al que se le pueden hacer cosas. Por ejemplo, una instancia de un nodo es normalmente un computador que se encuentra fsicamente en una habitacin; una instancia de un componente ocupa algo de espacio en el sistema de archivos; una instancia de un registro de un cliente consume algo de memoria fsica, anlogamente, una instancia de un billete de avin es algo sobre lo que se pueden hacer clculos.
Leccin 15. Herencia y polimorfismo Polimorfismo Una de las caractersticas fundamentales de la OOP es el polimorfismo, que no es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un objeto STRING significara concatenacin ("pegar" strings uno seguido al otro) Herencia En programacin orientada a objetos, la herencia es un mecanismo que hace posible que una clase herede todo el comportamiento y atributos de otra clase; a travs de la herencia, una clase tiene inmediatamente toda la funcionalidad de una clase existente, debido a esto, las nuevas clases se pueden crear indicando nicamente 46
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML en que se diferencian de la clase existente, es decir, que toma la definicin previa de la cual es subclase, y que solo se le agrega caractersticas especiales que la difieren de la clase de la cual procede. La relacin de herencia se representa mediante un tringulo en el extremo de la relacin que corresponde a la clase ms general o clase padre.
47
SEGUNDA UNIDAD CARACTERSTICAS DEL MODELADO UML
48
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML UNIDAD 2. CARACTERSTICAS DEL MODELADO UML CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML Leccin 16. Diagramas de Objetos Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos dinmicos del sistema, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases, representando slo la parte esttica de una interaccin, consistiendo en los objetos que colaboraran pero sin ninguno de los mensajes intercambiados entre ellos. Los diagramas de objetos se emplean para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estticas, En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representada por un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.
Figura 36: Diagrama de Objetos
49
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML En la figura anterior se representa un conjunto de objetos extrados de la implementacin de un robot. Como indica la figura, un objeto representa al propio robot, (r es una instancia de Robot), y r se encuentra actualmente en estado movimiento. Este objeto tiene un enlace con m, una instancia de Mundo, que representa una abstraccin del modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un conjunto de instancias de Elemento, que representan entidades que el robot ha identificado, pero an no ha asignado en su vista del mundo. En este instante, m est enlazado a dos instancias de rea. Una de ellas (a2) se muestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cada una de estas paredes est etiquetada con su anchura actual, y cada una se muestra 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 y una puerta en el cuarto. Como vemos los diagramas de objetos son especialmente tiles para modelar estructuras de datos complejas. Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un conjunto de clases con t relaciones entre ellas, pueden existir muchas ms configuraciones posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos slo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototpicos.
Leccin 17. Diagramas de Casos de Uso El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos: Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin. Elementos Actor
Figura 37: Actor
50
Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema. Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. Caso de Uso
Figura 38: Caso de Uso
Es una operacin o tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso. Relaciones Las relaciones se explicaron de manera especfica en el apartado 1.2.4 de este mdulo, ahora se explica de manera sencilla para observar su uso dentro de los diagramas de casos de uso. Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple. Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada. Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia 51
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML (<<extends>>). Este tipo de relacin est orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde est la duda clsica de usar o heredar. Ejemplo: Como ejemplo est el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar lo siguiente: Registrar el nmero de tems ingresados. Imprimir un recibo cuando el usuario lo solicita: Describe lo depositado El valor de cada tem Total El usuario/cliente presiona el botn de comienzo Existe un operador que desea saber lo siguiente: Cuantos tems han sido retornados en el da. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: Informacin asociada a tems. Dar una alarma en el caso de que: tem se atora. No hay ms papel. Como una primera aproximacin identificamos a los actores que interactan con el sistema:
52
Figura 39: Los Actores que Interactan con el Sistema
Luego, tenemos que un Cliente puede Depositar tems y un Operador puede cambiar la informacin de un tem o bien puede Imprimir un informe:
Figura 40: Cliente Puede Depositar tems y un Operador Puede Cambiar la Informacin de un tem o Bien Puede Imprimir un Informe
Adems podemos notar que un tem puede ser una Botella, un Tarro o una Jaba.
Figura 41: Depositar tem
53
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn tem por un cliente o bien puede ser realizada a peticin de un operador.
Figura 42: Peticin a un Operador
Entonces, el diseo completo del diagrama casos de uso es:
Figura 43: Diseo Completo del Diagrama de Casos de Uso
Leccin 18. Diagramas de Interaccin Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de un sistema, lo que conlleva modelar instancias concretas o prototpicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de objetos colaboran para proveer un comportamiento. En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia 54
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML y Diagramas de Colaboracin. Leccin 19. Diagrama de Secuencia Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
Figura 44: Transiciones y Activaciones
55
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Los diagramas de secuencia tienen 2 caractersticas que los distinguen de los diagramas de colaboracin, en primer lugar est la lnea de vida de un objeto que es la lnea discontinua vertical que representa la existencia de un objeto a lo largo de un periodo de tiempo. La mayora de los objetos que aparecen en un diagrama de secuencia existirn mientras dure la interaccin, los objetos se colocan en la parte superior del diagrama con sus lneas de vida dibujadas de arriba hasta abajo. Pueden crearse objetos durante la interaccin, sus lneas de vida comienzan con la recepcin de mensajes estereotipado como crate. Los objetos pueden destruirse durante la interaccin, sus lneas de vida acaban con la recepcin del mensaje estereotipado como destroy, adems, se muestra la seal visual de una gran X que marca el final de sus vidas.
Leccin 20. Diagrama de Colaboracin Un diagrama de colaboracin destaca la organizacin de los objetos que participan en una interaccin, un diagrama de colaboracin se construye colocando en primer lugar los objetos que participan en la colaboracin como nodos de un grafo. A continuacin se representa los enlaces que conectan esos objetos como arcos de grafo, por ltimo, estos enlaces se adorna con los mensajes que envan y reciben los objetos, esto da al lector una seal visual clara del flujo de control en el contexto de la organizacin estructural de los objetos que colaboran
Figura 45: Flujo de Control
Los diagramas colaboracin tienen dos caractersticas que los distinguen de los diagramas de secuencia, el primero para indicar cmo se enlaza un objeto a otro, se puede asociar un objeto al extremo ms lejano de un enlace con la palabra local que indica que el objeto designado es local al emisor. En segundo lugar est el nmero de secuencia, para indicar la ordenacin temporal de los mensajes, se precede de un nmero iniciando con el numeral 1, que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control.
56
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 21. Diagramas de Actividades Un diagrama de actividades muestra el flujo de actividades, siendo un actividad una ejecucin general entre los objetos que se est ejecutando en un momento dado dentro de una mquina de estados, el resultado de un actividad es una accin que producen un cambio en el estado del sistema o la devolucin de un valor. Las acciones incluyen llamadas a otras operaciones, envo de seales, creacin o destruccin de objetos o simples clculos. Grficamente un diagrama de actividades ser un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cmo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecucin de un proceso ms complejo. Por este motivo, en un diagrama de actividades aparecern acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido.
Contenido del diagrama de actividades Bsicamente un diagrama de actividades contiene: Estados de actividad Estados de accin Transiciones Objetos
Estados de actividad y estados de accin La representacin de ambos es un rectngulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una accin. La forma de expresar tanto una actividad como una accin, no queda impuesta por UML, se podra utilizar lenguaje natural, una especificacin formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: Un estado que represente una accin es atmico, lo que significa que su ejecucin se puede considerar instantnea y no puede ser interrumpida, Al igual que en el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un crculo) y uno final (representado como dos crculos concntricos). En la siguiente figura, podemos ver ejemplos de estados de accin.
57
Figura 46: Estados de Accin
En cambio un estado de actividad, s puede descomponerse en ms subactividades representadas a travs de otros diagramas de actividades. Adems estos estados s pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestin, as como definicin de submquinas, como podemos ver en la figura siguiente:
Figura 47: Submaquinas
Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de accin. Esta transicin se produce como resultado de la finalizacin del estado del que parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y terminar en algn momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo siguiente.
58
Figura 48: Transiciones
Bifurcaciones Un flujo de control no tiene porqu ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcacin se utilizar como smbolo el rombo. Dicha bifurcacin tendr una transicin de entrada y dos o ms de salida. En cada transicin de salida se colocar una expresin booleana que ser evaluada una vez al llegar a la bifurcacin, las guardas de la bifurcacin han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecucin del flujo de control quedara interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transicin obligada a un determinado estado cuando el resto de guardas han fallado. Veamos un ejemplo de bifurcacin.
Figura 49: Bifurcaciones
59
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Divisin y unin No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en los que se requieren tareas concurrentes. UML representa grficamente el proceso de divisin, que representa la concurrencia, y el momento de la unin de nuevo al flujo de control secuencial, por una lnea horizontal ancha. Podemos ver cmo se representa grficamente.
Figura 50: Divisin y unin
Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente til dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. Cada calle representa a la parte de la organizacin responsable de las actividades que aparecen en esa calle. Grficamente quedara como se muestra a continuacin
Figura 51: Calles
60
CAPITULO 5. MODELADO DINMICO Leccin 22. Eventos y seales Un evento es la especificacin de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio. En el contexto de las mquinas de estado, un evento es la aparicin de un estmulo que puede disparar una transicin de estado. Una seal es un tipo de evento que representa la especificacin de un estmulo asncrono que es transmitido entre instancias. Seales Una seal representa un objeto con nombre que es enviado (lanzado) asncronamente por un objeto y recibido (capturado) por otro. El tipo ms comn de seal interna que se presenta dentro de los lenguajes de programacin son las excepciones. Una seal puede enviarse como la accin de una transicin de estado en una mquina de estados, o como el envo de un mensaje en una interaccin. En UML, la relacin entre una operacin y los eventos que puede enviar se modela con relacin de dependencia, estereotipada como send. Las seales y las excepciones se modelan como clases estereotipadas, se puede utilizar una dependencia, estereotipada como send para indicar que la operacin enva una seal particular.
Figura 52: Seales
61
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Eventos Un evento de llamada representa una invocacin de una operacin, un evento puede disparar una transicin de estado de una mquina de estados. Cuando un objeto invoca una operacin sobre otro objeto que tiene una mquina de estados, el control pasa del emisor al receptor, el evento dispara la transicin, la operacin acaba, el receptor pasa a un nuevo estado y el control regresa al emisor. Grficamente se muestra al evento con sus parmetros, como el disparador de una transicin de estado.
Figura 53: Eventos
Un evento de tiempo es un evento que representa el paso del tiempo, en UML se modela un evento de tiempo con la palabra alter seguida de alguna expresin que se evala para producir algn periodo de tiempo. Un evento de cambio es un evento que representa un cambio en el estado o el cumplimiento de alguna condicin, se modela con la palabra when seguida de alguna expresin booleana.
Figura 54: Un evento de Cambio o de Tiempo
Leccin 23. Mquinas de Estado Una mquina de estado es un comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos. Un Estado es una condicin o situacin en la vida de un objeto durante la cual satisface alguna condicin, realiza una actividad o espera algn evento. Un evento es la especificacin de un acontecimiento significativo que ocupa un lugar en el tiempo y el espacio, es la estimulacin que puede disparar una transicin de estados. 62
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Una transicin es una relacin entre dos estados que indica que un objeto que est en el primer estado realizar ciertas acciones y entrar el segundo estado cuando ocurra un evento especfico y se satisfagan unas condiciones especficas y una actividad es una ejecucin no atmica en curso, dentro de una mquina de estados. Estados Un estado es una condicin o situacin en la vida de un objeto durante la cual satisface alguna condicin, realiza una actividad o espera un evento. Un objeto puede estar en cualquier estado durante una cantidad de tiempo determinado, por ejemplo un calentador de agua puede estar en cualquiera de los cuatro estados: inactivo, en preparacin (esperando alcanzar la temperatura adecuada), activo (cuando el calentador alcanza la temperatura ideal para calentar el agua), y pagado. Un estado tiene varias partes, nombre, acciones de entrada salida, transiciones internas, subastados y eventos diferidos. Como se muestra a continuacin un estado se representa con un rectngulo con las esquinas redondeadas.
Figura 55: Estados
Como se observa en la grfica anterior en la mquina de estados de un objeto se pueden definir dos estados especiales, en primer lugar el punto inicial que indica el punto de comienzo por defecto para la mquina de estados o el subestado. En segundo lugar, el estado final, que indica la ejecucin de la mquina de estado o el estado que lo contiene ha finalizado
63
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Transiciones Una transicin es una relacin entre dos estados que indica que un objeto que est en un primer estado , realizar ciertas acciones y entrar en el segundo estado, cuando ocurra un evento especfico y se satisfagan unas condiciones mnimas, cuando se produce este cambio de estado. Se dice que la transicin se ha disparado. Hasta que se dispara la transicin se dice que el objeto est en el estado origen, despus de dispararse se dice que est en el estado destino.
Figura 56: Transiciones
Una transicin tiene cinco partes, estado origen, evento disparado, condicin de guarda, accin y estado de destino; una transicin se representa con una lnea continua dirigida desde el estado origen hacia el destino y una autotransicin es una transicin cuyos estados origen y destino son los mismos.
Leccin 24. Tiempo y Espacio Una marca de tiempo denota el instante en el que ocurre un evento, grficamente, una marca de tiempo es una expresin obtenida a partir del nombre dado al mensaje; una expresin de tiempo es una expresin que al evaluarse genera un valor de tiempo 64
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML absoluto o relativo. Una restriccin de tiempo se representa como cualquiera otra restriccin, es decir, una cadena de texto entre llaves y normalmente conectada a un electo mediante una relacin de dependencia. La localizacin es la asignacin de un componente de un nodo. Grficamente, la localizacin se representa como un valor etiquetado, es decir, una cadena de texto entra llaves colocada debajo del nombre del elemento, o mediante la inclusin de componentes dentro de nodos.
Figura 57: Tiempo y Espacio
En el grfico anterior se observa la manera como se representa el tiempo y el siguiente grfico se muestra la localizacin:
Figura 58: Localizacin
65
Leccin 25. Transicin y Accin Transicin Simple: Es la relacin entre dos o muchos estados que estn unidos por una flecha, identificando a un objeto en un estado primario donde se realizara una accin especfica y que pasara a un segundo estado, cuando ocurra un evento y se cumplan unas condiciones especficas avanzando as entre los diferentes estados o cerrando el mismo.
Transicin Compleja: Se da cuando dos o ms estados en una sola transicin y tienen varias fuentes o destinos. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. Transicin interna: Tiene un estado origen pero ningn estado destino. Si una transicin interna tiene accin, se ejecuta pero no existe cambio de estado. Accin: Es cuando una transicin se dispara o se acciona, para que se pueda considerar como una accin se debe de cumplir con alguna de estas: Una sentencia de asignacin Una operacin aritmtica El envo de una seal a otro objeto La invocacin de una operacin propia Asignacin de valores de retorno Creacin o destruccin de objetos Una secuencia de acciones simples
Leccin 26. Diagramas de Estado Es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas, lo que distingue a un diagrama de estados de los otros tipos de diagramas es su contenido, normalmente los diagramas de estados contienen: Estados simples y compuestos Transiciones, incluyendo eventos y acciones Observemos un diagrama de estados a continuacin con todos sus componentes
66
Figura 59: Diagrama de estados con todos sus componentes
CAPITULO 6. MODELADO ARQUITECTNICO Leccin 27. Componentes, despliegue, colaboraciones y patrones Componentes Un componente es una parte fsica y reemplazable de un sistema que conforma un conjunto de interfaces. Grficamente, un componente se representa como un rectngulo con pestaas, un componente debe tener un nombre que lo distinga del resto de componentes. El nombre de un componente puede ser simple o de camino que consta del nombre del componente precedido del nombre del paquete en el que se encuentra, usualmente un componente se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la siguiente figura
Figura 60: Componentes
67
Figura 61: Interfaz
Despliegue Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que generalmente tiene alguna memoria y a menudo capacidad de procesamiento, grficamente un nodo se representa como un cubo. El nombre de un componente puede ser simple o de camino que consta del nombre del componente precedido del nombre del paquete en el que se encuentra, usualmente un nodo se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la siguiente figura.
Figura 62: Despliegue
Colaboraciones Una colaboracin es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Una colaboracin es tambin la especificacin de cmo un elemento tal como un clasificador o un operacin, es realizado mediante un conjunto de clasificadores y asociaciones que juegan roles especficos utilizados de una forma especfica, grficamente, una colaboracin se representa como una elipse con borde discontinua. El nombre de una colaboracin puede ser simple o de camino que 68
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML consta del nombre de la colaboracin precedido del nombre del paquete en el que se encuentra, usualmente un nodo se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la siguiente figura.
Figura 63: Colaboraciones
Patrones Un patrn es una solucin comn a un problema comn en un contexto dado. Los patrones ayudan a visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Hay dos tipos de patrones, patrones de diseo (Mecanismos) y frameworks. Mecanismos Un mecanismo simplemente muestra un conjunto de abstracciones que colaboran entre s para llevar a cabo algn comportamiento comn, estos mecanismos se muestran como colaboraciones simples, ya que solamente dan el nombre a una sociedad de clases.
Figura 64: Mecanismos
Los mecanismos pueden nombrar una plantilla formada por un conjunto de abstracciones que colaboran entre s para llevar a cabo algn comportamiento comn, se representan como colaboraciones parametrizadas que se muestran de forma parecida a las clases plantilla, observe la siguiente figura 69
Figura 65: Plantilla Formada por un conjunto de abstracciones
Leccin 28. Frameworks Un frameworks es un patrn arquitectnico que proporciona una plantilla extensible para aplicaciones dentro de un dominio. La siguiente figura ilustra un frameworks, llamado AdministradorCiclo entre otras cosas, este frameworks incluye una colaboracin EventosComunes que contiene un conjunto de clases evento, junto con un mecanismo GestorDeEventos para procesar estos eventos de forma cclica. Un cliente que utilice este frameworks tal como un Marcapasos podra construir sobre las abstracciones en EventosComunes creando subclases y tambin podra emplear una instancia del mecanismo GestorDeEventos.
Figura 66: Frameworks
70
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 29. Diagramas de Componentes Lo que distingue a un diagrama de componentes de otros tipos de diagramas es su contenido. Normalmente contienen componentes, interfaces y relaciones entre ellos. Y como todos los diagramas, tambin puede contener paquetes utilizados para agrupar elementos del modelo. Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software, sean stos componentes de cdigo fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideracin los requisitos relacionados con la facilidad de desarrollo, la gestin del software, la reutilizacin, y las restricciones impuestas por los lenguajes de programacin y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes sern componentes y paquetes. Dado que los diagramas de componentes muestran los componentes software que constituyen una parte reusable, sus interfaces, y sus interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama de clases a gran escala. Cada componente en el diagrama debe ser documentado con un diagrama de componentes ms detallado, un diagrama de clases, o un diagrama de casos de uso. Un paquete en un diagrama de componentes representa una divisin fsica del sistema. Los paquetes se organizan en una jerarqua de capas donde cada capa tiene una interfaz bien definida. Un ejemplo tpico de una jerarqua en capas de este tipo es: Interfaz de usuario; Paquetes especficos de la aplicacin; Paquetes reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo. Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilacin). Puede mostrar tambin que un componente software contiene una interfaz, es decir, la soporta. Un ejemplo se muestra a continuacin
Figura 67: Diagrama de Componentes
71
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 30. Diagramas de Despliegue Cuando se trata de hardware y el software del sistema, se utiliza los diagramas de despliegue para razonar sobre la tipologa de procesadores y dispositivos sobre los que reejecuta el software. Los diagramas de despliegue se utilizan para visualizar los aspectos estticos de estos nodos f si co s y sus relaciones y para especificar sus detalles para la construccin, como se muestra a continuacin.
Figura 68: Diagramas de Despliegue
Un diagrama de despliegue es un diagrama que muestra la configuracin de los nodos que participan en la ejecucin y de los componentes que residen en ellos, grficamente, un diagrama de despliegue es una coleccin de nodos y arcos.
Leccin 31. Sistemas y modelos UML proporciona una representacin grfica de los sistemas y los subsistemas, esta notacin permite visualizar la descompensacin de un sistema en subsistemas ms pequeos, grficamente, un sistema y un subsistema se representa con el smbolo de un paquete estereotipado. Observemos su representacin a continuacin. 72
Figura 69: Sistemas y Modelos
Un sistema posiblemente descompuesto en una coleccin de subsistemas, es un conjunto de elementos organizados para lograr un propsito y descrito por un conjunto de modelos. Un subsistema es una agrupacin de elementos, algunos de los cuales constituyen una especificacin del comportamiento ofrecido por otros elementos.
73
TERCERA UNIDAD
PRINCIPIOS DE UML ORIENTADO A OBJETOS
74
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML UNIDAD 3. PRINCIPIOS DE UML ORIENTADO A OBJETOS
CAPITULO 7. DESARROLLO ORIENTADO A OBJETOS CON UML Cuando se va a construir un sistema software es necesario conocer un lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea robusto y sustentable, es necesario que el problema sea analizado y la solucin sea cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de ambos, entonces la construccin de sistemas software va a poder planificar y repetible. Y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas. La notacin que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estndar de facto en cuanto a notacin orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentacin, pues es de esperar que cualquier desarrollador versado en orientacin a objetos conozca y use UML (o se est planteando su uso). Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando as una visin completa y coherente de la produccin de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. As no se pierde de vista la motivacin principal que debera estar en cualquier proceso de construccin de software: el resolver una necesidad del usuario/cliente.
Leccin 32. Visin General El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que vamos a encontrar al intentar desarrollar cualquier sistema software de tamao medio-alto. El proceso est formado por una serie de actividades y subactividades, cuya realizacin se va repitiendo en el tiempo, aplicadas a distintos elementos.
75
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML En este apartado se va a presentar una visin general para poder tener una idea del proceso a alto nivel, y ms adelante se vern los pasos que componen cada fase. Fase de Planificacin y Especificacin de Requisitos: Planificacin, definicin de requisitos, construccin de prototipos, etc. Fase de Construccin del Modelo: La construccin del sistema, las fases dentro de esta etapa son las siguientes: Diseo de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. Diseo de Bajo Nivel: El sistema se especifica en detalle, describiendo cmo va a funcionar internamente para satisfacer lo especificado en el Diseo de Alto Nivel. Implementacin: se lleva lo especificado en el Diseo de Bajo Nivel a un lenguaje de programacin. Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificacin y Especificacin de Requisitos. Instalacin: La puesta en marcha del sistema en el entorno previsto de uso. De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del diseo de alto y al de bajo nivel, para llegar a la implementacin y pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximacin se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente.
Leccin 33. Fase de Planificacin y Especificacin de Requisitos Esta fase se corresponde con la Especificacin de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente.
76
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Actividades Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigacin Preliminar. Definir los Requisitos. Registrar Trminos en el Glosario. (continuado en posteriores fases) Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) Refinar el Plan. El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede tambin en las actividades de las fases de diseo, que se vern ms adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificacin de proyectos software, como las correspondientes a creacin de planes e informes preliminares. Requisitos El formato del documento de Especificacin de Requisitos no est definido en UML, pero se ha incluido este punto para resaltar que la actividad de definicin de requisitos es un paso clave en la creacin de cualquier producto software. Para entender y describir los requisitos la tcnica de casos de uso constituye una valiosa ayuda. Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. Ntese que UML no define un formato para describir un caso de uso. Tan slo define la manera de representar la relacin entre actores y casos de uso en un diagrama. Sin embargo, un caso de uso individual no es un diagrama, es un documento de texto. En la siguiente seccin se define el formato textual para la descripcin de un caso de uso que se va a utilizar en este documento.
77
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica de acciones e interacciones entre los actores y el sistema. Ms adelante se ver la representacin de los escenarios correspondientes a un caso de uso por medio de Diagramas de Secuencia. En un primer momento interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con ms detalle se usa el formato expandido. Casos de Uso de Alto Nivel El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est usando un cajero automtico: Caso de Uso: Realizar Reintegro Actores: Cliente Tipo: Primario Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica.
El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se condensa en dos o tres frases. Es til para comprender el mbito y el grado de complejidad del sistema. Casos de Uso Expandidos Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencian al resto, se describen a un nivel ms detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve en el siguiente ejemplo: Caso de Uso: Realizar Reintegro Actores: Cliente (iniciador) Propsito: Realizar una operacin de reintegro de una cuenta del banco Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.
78
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Tipo: Primario y esencial Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificacin. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operacin de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. Cursos Alternativas: Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin. Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operacin.
Identificacin de Casos de Uso La identificacin de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en el uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo. Como gua para la identificacin inicial de casos de uso hay dos mtodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organizacin. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Ejemplos de casos de uso: Pedir un producto. Matricularse en un curso de la facultad. Comprobar la ortografa de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet
79
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Identificacin de los Lmites del Sistema En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para que los casos de uso tengan un significado completo es necesario que el sistema est definido con precisin. Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son: El hardware y software de un sistema informtico. Un departamento de una organizacin. Una organizacin entera. Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere construir. Tipos de Casos de Uso A. Segn su Importancia Para establecer una primera aproximacin a la priorizacin de casos de uso que identifiquemos los vamos a distinguir entre: Primarios: R e p r e s e n t a n los procesos principales, los ms comunes, como Realizar Reintegro en el caso del cajero automtico. Secundarios: R e p r e s e n t a n casos de uso menores, que van a necesitarse raramente, tales como Aadir Nueva Operacin. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. B. Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin. Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas.
80
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico tenemos la siguiente descripcin del curso tpico. Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 2. Pide el PIN (Personal Identification Number). 3. Introduce el PIN a travs del teclado numrico. 4. Presenta las opciones de operaciones disponibles. 5. etc. En principio, los casos de uso reales deberan ser creados en la fase de Diseo de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el diseo es continuo, y una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros. Consejos Relativos a Casos de Uso Nombre: El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artculos o Realizar Pedido. Alternativas equiprobables: Cu an d o se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas consideradas normales se puede completar el Curso Tpico de Eventos con secciones adicionales. Leccin 34. Construccin de los diagramas de casos de Uso Para construir el Modelo de Casos de Uso en la fase de Planificacin y especificacin de Requisitos se siguen los siguientes pasos: 1. Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los actores y los casos de uso. 2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales. 3. Se dibuja el Diagrama de Casos de Uso. 4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el Diagrama de Casos de Uso. 81
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML 5. Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definicin en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez. 6. Se crean casos de uso reales slo cuando: Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin). Leccin 35. Planificacin de Casos de Uso segn Ciclos de Desarrollo La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a tomar basndose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementacin de uno o ms casos de uso, o versiones simplificadas de casos de uso. Se asigna una versin simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo.
Figura 70: Planificacin de casos de uso segn ciclos de desarrollo
Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos segn prioridad. Las caractersticas de un caso de uso especfico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes:
82
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva o arriesgada. Representa un proceso de gran importancia en la lnea de negocio. Supone directamente un aumento de beneficios o una disminucin de costos. Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin numrica de cada uno de estos puntos, para conseguir una puntuacin total aplicando pesos a cada apartado. Caso de Uso de Inicializacin Prcticamente todos los sistemas van a tener un caso de uso de Inicializacin. Aunque puede ser que no tenga una prioridad alta en la clasificacin realizada segn el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las necesidades de inicializacin de los casos de uso que se tratan en dicho ciclo. As se tiene un sistema en cada ciclo de desarrollo que puede funcionar. Leccin 36. Fase de Construccin del Modelo Diseo de Alto Nivel En la fase de Diseo de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se est tratando. Se intenta llegar a una buena comprensin del problema por parte del equipo de desarrollo, sin entrar en cmo va a ser la solucin en cuanto a detalles de implementacin. Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseo de Alto Nivel hay una serie de actividades de planificacin. Estas actividades consisten en actualizar los modelos que se tengan segn lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseo de Alto Nivel.
83
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML En esta fase se trabaja con los modelos de Diseo de Alto Nivel construidos en la fase anterior, amplindolos con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual. Actividades Las actividades de la fase de Diseo de Alto Nivel son las siguientes: 1. Definir Casos de Uso Esenciales en formato expandido. (si no estn definidos ) 2. Refinar los Diagramas de Casos de Uso. 3. Refinar el Modelo Conceptual. 4. Refinar el Glosario. (continuado en posteriores fases) 5. Definir los Diagramas de Secuencia del Sistema. 6. Definir Contratos de Operacin. 7. Definir Diagramas de Estados. (opcional) Modelo Conceptual Una parte de la investigacin sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Esttica de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representacin de conceptos del mundo real, no de componentes software. El objetivo de la creacin de un Modelo Conceptual es aumentar la comprensin del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algn concepto importante. Identificacin de Conceptos Para identificar conceptos hay que basarse en el documento de especificacin de requisitos y en el conocimiento general acerca del dominio del problema. Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, ms concretamente, en la descripcin de los casos de uso. No es un mtodo infalible, pero puede servir de gua para empezar.
Para poner nombre a los conceptos se puede usar la analoga con el cartgrafo, resumida en los siguientes tres puntos: Usar los nombres existentes en el territorio: hay que usar el vocabulario del dominio para nombrar conceptos y atributos. Excluir caractersticas irrelevantes: al igual que el cartgrafo elimina 84
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML caractersticas no relevantes segn la finalidad del mapa (por ejemplo datos de poblacin en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos. No aadir cosas que no estn ah: si algo no pertenece al dominio del problema no se aade al modelo. Creacin del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: Hacer una lista de conceptos candidato usando la Lista de Categoras de Conceptos y la bsqueda de sustantivos relacionados con los requisitos en consideracin en este ciclo. Representarlos en un diagrama. Aadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. Aadir los atributos necesarios para contener toda la informacin que se necesite conocer de cada concepto. Identificacin de Asociaciones Una asociacin es una relacin entre conceptos que indica una conexin con sentido y que es de inters en el conjunto de casos de uso que se est tratando. Se incluyen en el modelo las asociaciones siguientes: Asociaciones para las que el conocimiento de la relacin necesita mantenerse por un cierto perodo de tiempo (asociaciones necesita-conocer). Asociaciones derivadas de la Lista de Asociaciones Identificacin de Atributos Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de informacin de los casos de uso que se estn desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los tipos complejos deberan ser modelados como conceptos y ser relacionados mediante asociaciones, incluso cuando un valor es de un tipo simple es ms conveniente representarlo como concepto en las siguientes ocasiones cuando: Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el nombre de una persona, etc. 85
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Tiene operaciones asociadas, tales como validacin. Ejemplo: nmero nico de identificacin. Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin. Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesos, dlares o en euros. Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del desarrollo se va refinando segn se le aaden conceptos que se haban pasado por alto. Glosario En el glosario debe aparecer una descripcin textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigedad. Se ordena alfabticamente por trmino.
CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA Adems de investigar sobre los conceptos del sistema y su estructura, tambin es preciso investigar el diseo de alto nivel sobre el comportamiento del sistema, visto ste como una caja negra. Una parte de la descripcin del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema. En cada caso de uso se muestra una interaccin de actores con el sistema. En esta interaccin los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avin, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operacin en el sistema de reservas. Los casos de uso representan una interaccin genrica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecucin real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular. Un Diagrama de Secuencia de Sistema se representa usando la notacin para diagramas de secuencia de UML estudiadas en la unidad 2 de este mdulo. En l se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas. Para cada caso de uso que se est tratando se realiza un diagrama para el curso tpico de eventos, y adems se realiza un diagrama para los cursos alternativos de mayor inters. En la siguiente figura se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar Reintegro de un cajero automtico.
86
Figura 71: Diagrama de secuencia del sistema para el caso de uso
Leccin 37. Construccin de un Diagrama de Secuencia del Sistema Para construir un Diagrama de Secuencia del Sistema para el curso tpico de eventos de un caso de uso, se siguen los siguientes pasos: 1. Representar el sistema como un objeto con una lnea debajo. 2. Identificar los actores que directamente operan con el sistema, y dibujar una lnea para cada uno de ellos. 3. Partiendo del texto del curso tpico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama. 4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama. los eventos del sistema deberan expresarse en base a la nocin de operacin que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere finalizarOperacin a presionadaTeclaEnter, porque captura la finalidad de la operacin sin realizar compromisos en cuanto a la interfaz usada.
87
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Diagramas de Estados Para modelar el comportamiento del sistema pueden usarse los Diagramas de estados definidos en la unidad 2 de este mdulo Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: Una clase software Un concepto Un caso de uso En la fase de Diseo de Alto Nivel slo se hara para los dos ltimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseo. Puesto que el sistema entero puede ser representado por un concepto, tambin se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados. La utilidad de un Diagrama de Estados en esta fase reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automtico si se est en el transcurso de una operacin. Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sera una combinacin de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es opcional. Diseo de Bajo Nivel En la fase de Diseo de Bajo Nivel se crea una solucin a nivel lgico para satisfacer los requisitos, basndose en el conocimiento reunido en la fase de Diseo de Alto Nivel. Los modelos ms importantes en esta fase son el Diagrama de Clases de Diseo y los Diagramas de Interaccin, que se realizan en paralelo y que definen los elementos que forman parte del sistema orientado a objetos que se va a construir (clases y objetos) y cmo colaboran entre s para realizar las funciones que se piden al sistema, segn stas se definieron en los contratos de operaciones del sistema. Actividades Las actividades que se realizan en la etapa de Diseo de Bajo Nivel son las siguientes: 1. Definir los Casos de Uso Reales. 88
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML 2. 3. 4. 5. Definir Informes e Interfaz de Usuario. Refinar la Arquitectura del Sistema. Definir los Diagramas de Interaccin. Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas de Interaccin). 6. Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura del Sistema no tiene por qu realizarse en la posicin 3, puede realizarse antes o despus. Casos de Uso Reales Un Caso de Uso Real describe el diseo real del caso de uso segn una tecnologa concreta de entrada y de salida y su implementacin. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluir bocetos de las ventanas y detalles de la interaccin a bajo nivel con los widgets (botn, lista seleccionable, campo editable, etc.) de la ventana. Como alternativa a la creacin de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementacin. Diagramas de Interaccin Los Diagramas de Interaccin muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato Hay dos clases de Diagramas de Interaccin: 1. Diagramas de Colaboracin. 2. Diagramas de Secuencia. La notacin en UML para ambos es la definida unidad 2 de este mdulo, los Diagramas de Colaboracin tienen una mayor expresividad y mayor economa espacial (una interaccin compleja puede ser muy larga en un Diagrama de Secuencia), sin embargo en ellos la secuencia de interaccin entre objetos es ms difcil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma informacin, por lo que se puede usar cualquiera de los dos para expresar la interaccin entre los objetos del sistema. La creacin de los Diagramas de Interaccin de un sistema es una de las actividades ms importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creacin de estos diagramas, por tanto, debera ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero.
89
Leccin 38. Creacin de los Diagramas de Interaccin Para crear los Diagramas de Colaboracin o de Secuencia se pueden seguir los siguientes consejos: Crear un diagrama separado para cada operacin del sistema en desarrollo en el ciclo de desarrollo actual. Para cada evento del sistema, hacer un diagrama con l como mensaje inicial. Usando los apartados de responsabilidades y de post-condiciones del contrato de operacin, y la descripcin del caso de uso como punto de partida, disear un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. Si el diagrama se complica, dividirlo en dos diagramas ms pequeos. Para ello se termina la secuencia de mensajes en un mensaje determinado, y en el segundo diagrama se comienza con el mensaje que termin el primero. Debe indicarse en el primer diagrama que el resto de la interaccin se detalla en el segundo. El comportamiento dinmico del sistema que se describe en un Diagrama de Interaccin debe ser acorde con la estructura esttica del sistema que se refleja en el Diagrama de Clases de Diseo. Es aconsejable realizar un Diagrama de Clases de Diseo borrador antes de comenzar con los Diagramas de Interaccin. La capacidad de realizar una buena asignacin de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo segn aumenta la experiencia en el desarrollo orientado a objetos. Responsabilidad es como un contrato u obligacin de una clase o tipo. Las responsabilidades estn ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Bsicamente, estas responsabilidades pueden ser de tipo Conocer o de tipo Hacer: Conocer: Conocer datos privados encapsulados. Conocer los objetos relacionados. Conocer las cosas que puede calcular o derivar. Hacer: Hacer algo l mismo. Iniciar una accin en otros objetos. Controlar y coordinar actividades en otros objetos. Por ejemplo, se puede decir que un Recibo es responsable de calcular el total (tipo hacer), o que una Transaccin es responsable de saber su fecha (tipo conocer). Las responsabilidades de tipo conocer se pueden inferir normalmente del Modelo Conceptual y una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para satisfacer responsabilidades. 90
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 39. Diagrama de Clases de Diseo Un Diagrama de Clases de Diseo muestra la especificacin para las clases software de una aplicacin. Incluye la siguiente informacin: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Mtodos. Navegabilidad. Dependencias.
A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra definiciones de entidades software ms que conceptos del mundo real. En la siguiente figura se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.
Figura 72: Diagrama de Clases de Diseo Sencillo
Relaciones de Dependencia Para Representar Visibilidad Entre Clases Cuando una clase conoce a otra por un medio que no es a travs de un atributo (una asociacin con la navegabilidad adecuada), entonces es preciso indicar esta situacin por medio de una dependencia. 91
Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se dice entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad ms directa es por medio de atributo, cuando hay una asociacin entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia: Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>. Local: Cuando en un mtodo de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>. Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un mtodo de una clase B llama a un mtodo de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>. No es necesario representar la relacin de dependencia entre clases que ya estn relacionadas por medio de una asociacin, que se trata de una dependencia ms fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qu elementos hay que revisar cuando se realiza un cambio en el diseo de un elemento del sistema. Solitario: Caso Particular de Visibilidad global El uso de variables globales no se aconseja por los efectos laterales que se pueden presentar, pero hay un caso en el que s hay cierta globalidad: las clases que slo van a tener una instancia. Suele tratarse de clases que se han creado en el Diseo de Bajo Nivel, que no aparecan en el Modelo Conceptual. Varias clases de nuestro sistema pueden querer llamar a los mtodos de la nica instancia de una clase de ese tipo, entonces s se considera que es beneficioso que se pueda acceder a esa instancia como un valor accesible de forma global. Una solucin elegante para este caso se implementa mediante un mtodo de clase para obtener esa nica instancia (los mtodos de clase los permiten algunos lenguajes orientados a objetos, por ejemplo Java), en vez de definirla directamente como una variable global. Para indicar que una clase slo va a tener una instancia, se etiqueta la clase con el estereotipo <>, y las relaciones de dependencia entre las clases que la usan y se etiquetan tambin <> en vez de <<>>.
92
A continuacin se muestra un ejemplo del cdigo en Java de una clase solitario: public class Solitario { // se define la instancia como atributo de clase (static) Solitario static instancia:= null; // mtodo de clase que devuelve la instancia public static Solitario dar instancia () { if (instancia = = null) { // si no est creada la instancia la crea instancia:= new Solitario (); } return instancia; } ... // otros mtodos de la clase } Cuando otra clase quiere llamar a un mtodo de la instancia incluye el siguiente cdigo: Variable Solitario; Variable = Solitario.dar_instancia(); Variable. Mtodo (); // llamada al mtodo que necesitamos Leccin 40. Construccin Diagramas de Diseo Normalmente se tiene una idea de un Diagrama de Clases, con una asignacin de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia: Identificar todas las clases participantes en la solucin software. Esto se lleva a cabo analizando los Diagramas de Interaccin. Representarlas en un diagrama de clases. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. Aadir los mtodos, segn aparecen en los Diagramas de Interaccin. Aadir informacin de tipo a los atributos y mtodos. Aadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. Aadir flechas de navegabilidad a las asociaciones para indicar la direccin de visibilidad de los atributos. Aadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando segn se vayan completando los Diagramas de Interaccin correspondientes. No existe precedencia entre la realizacin del Diagrama de Clases de Diseo y los Diagramas de Interaccin. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero ms en el de clases y otras veces se trabaja primero ms en los de interaccin. 93
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML No todas las clases que aparecan en el Modelo Conceptual tienen por qu aparecer en el Diagrama de Diseo. De hecho, tan solo se incluirn aquellas clases que tengan inters en cuanto a que se les ha asignado algn tipo de responsabilidad en el diseo del sistema. No hay, por tanto, una transicin directa entre el Modelo Conceptual y el Diagrama de Clases de Diseo, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensin de un dominio, y el segundo en una solucin software. En el Diagrama de Clases de Diseo se aaden los detalles referentes al lenguaje de programacin que se vaya a usar. Por ejemplo, los tipos de los atributos y parmetros se expresarn en el lenguaje de implementacin escogido.
Navegabilidad La navegabilidad es una propiedad de un rol (un extremo de una asociacin) que indica que es posible navegar unidireccionalmente a travs de la asociacin, desde objetos de la clase origen a objetos de la clase destino. Como se vio en la unidad 2 y se representa en UML mediante una flecha. La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementacin se traducir en la clase origen como un atributo que sea una referencia a la clase destino. Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una funcin, deben ser necesarias, si no es as deben eliminarse. Las situaciones ms comunes en las que parece que se necesita definir una asociacin con navegabilidad de A a B son: A enva un mensaje a B. A crea una instancia B. A necesita mantener una conexin con B.
Visibilidad de Atributos y Mtodos Los atributos y los mtodos deben tener una visibilidad asignada, que puede ser: + Visibilidad pblica. # Visibilidad protegida. - Visibilidad privada. Tambin puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementacin que sean necesarios para completar el Diagrama de Clases. Otros Aspectos en el Diseo del Sistema 94
En los puntos anteriores se ha hablado de decisiones de diseo a un nivel de granularidad fina, con las clases y objetos como unidades de decisin. En el diseo de un sistema es necesario tambin tomar decisiones a un nivel ms alto sobre la descomposicin de un sistema en subsistemas y sobre la arquitectura del sistema (definicin de sistemas y subsistemas unidad 2). Esta parte del Diseo de Bajo Nivel es lo que se denomina Diseo del Sistema. Estas decisiones no se toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Por tanto, no se va a entrar en este documento en cmo se realiza esta actividad.
Leccin 41. Implementacin y Pruebas Una vez se tiene completo el Diagrama de Clases de Diseo, se pasa a la implementacin en el lenguaje de programacin elegido. El programa obtenido se depura y prueba. Y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en produccin si se ha planificado una instalacin gradual. Una vez se tiene una versin estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo.
Captulo 9. PILARES DE LA ORIENTACIN A OBJETOS Leccin 42. Abstraccin Consiste en quitar las propiedades y acciones de un objeto y as dejar las acciones que sean necesarias. Esto clasifica diferentes tipos de problemas que requieren diferentes cantidades de informacin aun si estos problemas pertenecen a un rea en comn. Y se debe tener claro que en cada fase se podran aplicar ms o menos tributos que en las fases anteriores. Ignorancia selectiva La abstraccin nos ayuda a trabajos con temas complejos. Se enfoca en lo ms importante y por ende ignora lo que no lo es. Una clase en una abstraccin en la que: Se enfatiza las caractersticas ms relevantes, por tal razn se suprimen las dems caractersticas. Una abstraccin clave solo debe de ser capturada por una y solo unas clase.
95
Leccin 43. Herencia Partimos diciendo que es la cualidad ms importante de la OOP y que el concepto de objeto es la instancia de una clase que tiene todas las caractersticas de la clase de donde provienen, a estas caractersticas representativas se le denomina herencia, sin importar que atributos o acciones se decida unas en otra clase ya que cada objeto hereda atributos y operaciones. Tambin podramos definir como superclase la mayor y las subclases aquellas que estn dentro de la clase mayor. Recordemos que una clase se simboliza con un rectngulo y el nombre inicia con mayscula. Igualmente, el nombre de la clase est compuesto por ms de una palabra, estas deben de ir juntas sin espacio. Si representamos una clase de tipo escrita, se considera al procedimiento como: clase con nombre de ruta: ElementosDeportivos::Balon O de tipo grfica.
Figura 73: Clase con Nombre de Ruta
Tipos de herencia Herencia simple o Una clase posee una sola superclase directa. El grfico de herencia es un rbol Herencia mltiple o Una clase posee varias superclases directas. El grfico de herencia no es un rbol Mecanismos de herencia Enriquecimiento: Se aaden variables y/o mtodos Substitucin: Un mtodo heredado recibe una nueva definicin (la antigua no es adecuada al nuevo conjunto de objetos descritos por la superclase Visibilidad: Pblica (public) Privada (private) Protegida (protected) 96
Figura 74: Herencia
Leccin 44. Polimorfismo En algunas oportunidades se puede dar la coincidencia de que una accin presenta el mismo nombre en diferentes clases o en la misma, pero realizar una funcin diferente. Se da la posibilidad de que dos mtodos implementen distintas acciones, identificndose con el mismo nombre, dependiendo del objeto que lo ejecuta o de los parmetros que recibe, hay que tener la salvedad de que esta se da siempre y cuando el tipo de parmetro que recibe o el nmero sean diferentes. Podemos identificar la sobrecarga como tipo especial del polimorfismo y la invocacin como el resultado al momento de la ejecucin.
97
Figura 75: Polimorfismo
Leccin 45. Encapsulamiento Cuando hablamos de encapsulamiento nos referimos al ocultamiento del funcionamiento interno de las diferentes operaciones, de otros objetos y del entorno. Ejemplo el uso del computador (no es necesario que se sepa cmo funciona ni las partes que lo componen sino que cumple o satisface la necesidad del usuario, como jugar, escuchar msica entre otras actividades que podemos realizar).
Figura 76: Encapsulamiento
Se establece que los atributos son propios de un objeto y estos no son visibles desde otros objetos del entorno. Los datos y los procedimientos que los manipulan se agrupan en una sola entidad: el objeto
Figura 77: Estructura de Encapsulamiento
Por qu es til? Punto de control / Las respuestas son ms eficientes a los cambios.
98
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Leccin 46. Relaciones Cuando diferentes objetos trabajan en funcin a una meta o propsito y se logra por medio de la colaboracin entre las partes a travs de las relaciones. En pocas palabras se define como la conexin entre elementos. Para diferenciar las distintas relaciones se utilizan una Simbologa con base en varios tipos de lneas.
Figura 78: Tipos de Lneas que Simbolizan las Relaciones
De los diferentes tipos de relaciones a las que ms se les da importancias son: las dependencias, las generalizaciones y asociaciones. Tambin existe la relacin de realizacin.
Dependencias
Es una relacin de significado entre dos elementos, donde cualquier cambio a un elemento independiente, puede afectar el significado de otro elemento dependiente. Las dependencias generalmente representan relaciones de uso que manifiestan que un cambio en la especificacin de un elemento puede afectar a otro que la utiliza, pero no necesariamente a la inversa. Las clases o paquetes utilizan en su mayora en su contexto, para indicar que una clase utiliza a otra como argumento en la asignatura de una operacin.
99
Figura 79: Argumento de Asignatura
Generacionales
Esta hace referencia a la relacin de una sper clase o clase padre con una subclase o clase hija. La generalizacin significa que los objetos hijos se pueden emplear en cualquier clase donde pueda aparecer el padre, pero no a la inversa. Es decir, el hijo puede sustituir al padre, pero el padre no puede sustituir al hijo. Estas son sus caractersticas: El hijo hereda atributos y operaciones del padre. El hijo puede agregar atributos y operaciones. Puede tener operaciones polimrficas La generalizacin se llama a veces relacin es -un-tipo-de: un elemento (clase Animal mamfero) es-un-tipo-de un elemento ms general (clase Animal).
Figura 80: Generacionales
100
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Asociaciones
Es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro. Permitiendo a una asociacin entre dos clases se puede pasar de un objeto de una clase hasta un objeto de otra clase. Podemos encontrar una caracterstica especial entre las asociaciones dependencias ya que estas pueden ser reflexivas. y las
Figura 81: Asociaciones
La agregacin es un tipo especial de asociacin, que representa una relacin estructural entre todo y sus partes. Donde representa Una relacin del tipo Tienen-un ejemplo, Un AnimalAves Tienen Plumas.
Realizacin
Es una relacin semntica entre clasificadores donde este especifica unas normas o un reglamento con otro clasificador que garantiza que se cumplir. Se encuentran relaciones de realizacin: entre interfaces, clases y componentes que las realizan y entre los casos de uso y las colaboraciones que los realizan. Si confrontamos las relaciones de la dependencia, la generalizacin y la asociacin notamos que la realizacin es diferente a las otras relaciones mencionadas y as poderla trabajar como un tipo aparte de relacin. Pero semnticamente la realizacin es una mezcla entre dependencia y generalizacin.
101
Figura 82: Realizacin
102
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML REFERENCIAS BIBLIOGRFICAS El proceso Unificado de desarrollo de software, Booch Graby, Rumbaugh James, Jacobson Ivar, Edit Addison Wesly, 2002 Anlisis y Diseo de Sistemas de Informacin, Senn James, Editorial Mc Graw Hill. El lenguaje Unificado de Modelado, Booch Graby, Rumbaugh James, Jacobson Ivar, Edit Addison Wesly, 2002 Anlisis y diseo de Sistemas, Kendall &&Kendall, Editorial Printice Hall. Certificacin Profesional en Uml, Varios Autores, Saejee Bussiness School, 2009. epiwiki. (03 de 10 de 2005). Introduccin a UML 2.0. Recuperado el 10 de 05 de 2013, de http://www.epidataconsulting.com/: http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15 IRIS, R. (1995). Red IRIS BSCW. Recuperado el 30 de 05 de 2013, de http://bscw.rediris.es/pub/bscw.cgi/d673123/Manual de UML.doc Magma Soft. (19 de Agosto de 2006). Magma Soft. Recuperado el 30 de 05 de 2013, de http://www.magma.com.ni/~jorge/upoli_uml/refs/Resumen_de_UML.doc monografias.com. (15 de 12 de 2005). Diseo y Modelacin de un Proyecto de Software Utilizando el lenguaje UML. Recuperado el 30 de 5 de 2013, de http://www.monografias.com: http://www.monografias.com/trabajos28/proyectouml/proyecto-uml.shtml Universidad Nacional de Ingeniera. (29 de 12 de 2012). Modelo Dinamico UML. Recuperado el 20 de 5 de 2013, de http://es.scribd.com: http://es.scribd.com/doc/106012983/Modelo-Dinamico-UML Universidad Yacamb. (10 de 2009). Anlisis y Diseo de Sistemas. Recuperado el 04 de 06 de 2013, de http://www.oocities.org/es: http://www.oocities.org/es/bcontrerasrodriguez/AnalisisyDisenodeSistemas/foro/forouml. htm Universidad Yacamb. (2009). UML (Unified Modeling Lenguaje) . Recuperado el 05 de 06 de 2013, de http://www.oocities.org: http://www.oocities.org/es/avrrinf/tabd/Foro/Foro_UML.htm Modelado con UML. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [69]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300030&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelado y Programacin Orientada a Objetos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [67]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300029&v=2.1&u =unad&it=r&p=GVRL&sw=w Programacin Orientada a Objetos con Java. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [129]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300041&v=2.1&u =unad&it=r&p=GVRL&sw=w 103
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Resumen. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. 64). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300027&v=2.1&u =unad&it=r&p=GVRL&sw=w Desarrollo de Software Orientado a Objetos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [193]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300050&v=2.1&u =unad&it=r&p=GVRL&sw=w Programacin y Desarrollo de Software Para Internet. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [599]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300088&v=2.1&u =unad&it=r&p=GVRL&sw=w Desarrollo de Software Para Internet. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [629]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300097&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Interfaces. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 209-210). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300054&v=2.1&u =unad&it=r&p=GVRL&sw=w Definicin de Conceptos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [577]-578). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300082&v=2.1&u =unad&it=r&p=GVRL&sw=w Costo y Complejidad del Software. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [3]). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300011&v=2.1&u =unad&it=r&p=GVRL&sw=w Arquitectura de Clases. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 254-258). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300060&v=2.1&u =unad&it=r&p=GVRL&sw=w Mdulos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 121-127). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300038&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Anlisis. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (p. [253]). Mexico City: Cengage Learning. Retrieved from 104
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300059&v=2.1&u =unad&it=r&p=GVRL&sw=w Diagrama de Clases. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 570-575). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300078&v=2.1&u =unad&it=r&p=GVRL&sw=w Arquitectura Cliente-Servidor. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [601]-602). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300090&v=2.1&u =unad&it=r&p=GVRL&sw=w Objetos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [69]-72). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300031&v=2.1&u =unad&it=r&p=GVRL&sw=w Clases. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 72-74). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300032&v=2.1&u =unad&it=r&p=GVRL&sw=w Descripcin del Problema. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 197-199). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300052&v=2.1&u =unad&it=r&p=GVRL&sw=w Diagramas de Secuencias del Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 515-521). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300073&v=2.1&u =unad&it=r&p=GVRL&sw=w Conceptos Bsicos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [21]-24). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300017&v=2.1&u =unad&it=r&p=GVRL&sw=w Programacin Avanzada. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 145-148). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300044&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelos Recientes. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 54-56). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300025&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelos Clsicos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a 105
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Objetos con UML, Java e Internet (pp. 50-54). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300024&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Requisitos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [195]-197). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300051&v=2.1&u =unad&it=r&p=GVRL&sw=w Clases Segn Casos de uso. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 271-275). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300062&v=2.1&u =unad&it=r&p=GVRL&sw=w HTML. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 602-608). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300091&v=2.1&u =unad&it=r&p=GVRL&sw=w Programacin y Lenguajes Orientados a Objetos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 25-28). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300018&v=2.1&u =unad&it=r&p=GVRL&sw=w Atributos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 74-79). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300033&v=2.1&u =unad&it=r&p=GVRL&sw=w Tipos de Pruebas. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 578-581). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300083&v=2.1&u =unad&it=r&p=GVRL&sw=w Diccionario de Clases Segn Mdulos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 327-332). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300065&v=2.1&u =unad&it=r&p=GVRL&sw=w Ensamblados: Agregacin y Composicin. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 101-106). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300036&v=2.1&u =unad&it=r&p=GVRL&sw=w Proceso de Pruebas. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 582-584). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300084&v=2.1&u 106
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML =unad&it=r&p=GVRL&sw=w Estrategias de Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 336-338). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300069&v=2.1&u =unad&it=r&p=GVRL&sw=w Revisin del Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 510-515). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300072&v=2.1&u =unad&it=r&p=GVRL&sw=w Lenguajes de Programacin. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 29-32). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300019&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Implementacin. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 643-656). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300099&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Casos de uso. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 199-209). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300053&v=2.1&u =unad&it=r&p=GVRL&sw=w Interfaces Grficas del Usuario. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 182-191). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300047&v=2.1&u =unad&it=r&p=GVRL&sw=w Pruebas del Sistema de Reservaciones de Vuelos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 584-598). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300085&v=2.1&u =unad&it=r&p=GVRL&sw=w Introduccin a Java. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [129]-134). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300042&v=2.1&u =unad&it=r&p=GVRL&sw=w Calidad de Software y Modelos de Madurez del Proceso. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 56-64). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300026&v=2.1&u =unad&it=r&p=GVRL&sw=w 107
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML Complejidad del Software. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 13-19). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300013&v=2.1&u =unad&it=r&p=GVRL&sw=w Programacin Bsica. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 134-145). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300043&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Proceso. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [35]-50). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300023&v=2.1&u =unad&it=r&p=GVRL&sw=w Generalizacin y Herencia. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 106-121). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300037&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo del Dominio del Problema. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 235-250). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300056&v=2.1&u =unad&it=r&p=GVRL&sw=w Identificacin de Clases Segn Estereotipos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 258-270). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300061&v=2.1&u =unad&it=r&p=GVRL&sw=w Modelo de Diseo. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. [629]-643). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300098&v=2.1&u =unad&it=r&p=GVRL&sw=w Actores y Casos de uso Para el Sistema de Reservaciones de Vuelos. (2005). In A. Weitzenfeld, Ingeniera de Software Orientada a Objetos con UML, Java e Internet (pp. 210-234). Mexico City: Cengage Learning. Retrieved from http://bibliotecavirtual.unad.edu.co:2130/ps/i.do?id=GALE%7CCX3004300055&v=2.1&u =unad&it=r&p=GVRL&sw=w
108

Lenguaje Unificado Uml

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lenguaje Unificado Uml

Uploaded by

Copyright:

Available Formats

ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA Contenido Didctico del Curso 200609 Lenguaje de Modelado Unificado - UML

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA 2013

INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO

Figura 1: Creadores del Lenguaje UML

Leccin 3. Evolucin del Lenguaje UML

Figura 2: Evolucin del Lenguaje UML

Figura 5: Fases de Desarrollo de un Sistema Soportado por UML

1. ArgoUML (Clic para que acceda a la pgina principal de la aplicacin)

Figura 6: ArgoUML Editor UML

2. Da (Clic para que acceda a la pgina principal de la aplicacin)

Figura 7: Da Editor de UML

Figura 8: Elementos UML

Figura 10: Atributos

Figura 11: Operaciones

Figura 12: Responsabilidades

Figura 13: Objetos

Figura 14: Asociacin

Figura 15: Roles

Figura 16: Agregacin

Figura 17: Conjunto de Clases

Figura 18: Conjunto de Clases Extradas de un Sistema de Informacin

Figura 19: Interfaz

Figura 20: Tipos de Datos

Seal: la especificacin de un estmulo asncrono enviado entre instancias

Figura 21: Seal

Figura 22: Componente

Nodo: un elemento fsico que existe en tiempo de ejecucin y representa 38

Figura 23: Nodo

Figura 24: Caso de Uso

Figura 25: Subsistema

Figura 26: Notacin

Figura 27: Herencia Mltiple

Figura 28: Asociacin

Figura 29: Interfaces

Figura 30: Abstraccin con una Interfaz

Figura 31: Diagrama de Interaccin entre Clases

Figura 32: Relacin de Clases en Notacin

Figura 33: Objeto Dentro Relacin de Clases en Notacin

Figura 34: Elementos Contenidos en el Paquete

Figura 35: Instancias

SEGUNDA UNIDAD CARACTERSTICAS DEL MODELADO UML

Figura 36: Diagrama de Objetos

Figura 37: Actor

Figura 38: Caso de Uso

Figura 39: Los Actores que Interactan con el Sistema

Figura 41: Depositar tem

Figura 42: Peticin a un Operador

Entonces, el diseo completo del diagrama casos de uso es:

Figura 43: Diseo Completo del Diagrama de Casos de Uso

Figura 44: Transiciones y Activaciones

Figura 45: Flujo de Control

Figura 46: Estados de Accin

Figura 47: Submaquinas

Figura 48: Transiciones

Figura 49: Bifurcaciones

Figura 50: Divisin y unin

Figura 51: Calles

Figura 52: Seales

Figura 53: Eventos

Figura 54: Un evento de Cambio o de Tiempo

Figura 55: Estados

Figura 56: Transiciones

Figura 57: Tiempo y Espacio

Figura 58: Localizacin