ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Contenido Didáctico del Curso Lenguaje de Modelado Unificado - UML

Transcripción

1 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

2 TABLA DE CONTENIDO PRIMERA UNIDAD UNIDAD 1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO CAPITULO 1. QUÉ ES UML? Lección 1. Por qué Aprender UML? Lección 2. UML no es un método Lección 4. Beneficios de Esta Tecnología Lección 5. En donde Utilizamos UML CAPITULO 2. MODELOS Lección 6. Modelos Lección 7. Notas y Dependencias Lección 8. Elementos comunes a todos los diagramas Lección 9. Fases de Desarrollo Lección 10. Herramientas Para Modelado CAPITULO 3. MODELADO ESTRUCTURADO Lección 11. Bloques de Construcción de UML Lección 12. Diagramas Lección 13. Diagramas de Clase Lección 14. Características avanzadas de las clases y relaciones Lección 15. Herencia y polimorfismo SEGUNDA UNIDAD UNIDAD 2. CARACTERÍSTICAS DEL MODELADO UML CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML Lección 16. Diagramas de Objetos Lección 17. Diagramas de Casos de Uso Lección 18. Diagramas de Interacción Lección 19. Diagrama de Secuencia Lección 20. Diagrama de Colaboración

3 Lección 21. Diagramas de Actividades CAPITULO 5. MODELADO DINÁMICO Lección 22. Eventos y señales Lección 23. Máquinas de Estado Lección 24. Tiempo y Espacio Lección 25. Transición y Acción Lección 26. Diagramas de Estado CAPITULO 6. MODELADO ARQUITECTÓNICO Lección 27. Componentes, despliegue, colaboraciones y patrones Lección 28. Frameworks Lección 29. Diagramas de Componentes Lección 30. Diagramas de Despliegue Lección 31. Sistemas y modelos TERCERA UNIDAD UNIDAD 3. PRINCIPIOS DE UML ORIENTADO A OBJETOS CAPITULO 7. DESARROLLO ORIENTADO A OBJETOS CON UML Lección 32. Visión General Lección 33. Fase de Planificación y Especificación de Requisitos Lección 34. Construcción de los diagramas de casos de Uso Lección 35. Planificación de Casos de Uso según Ciclos de Desarrollo Lección 36. Fase de Construcción del Modelo CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA Lección 37. Construcción de un Diagrama de Secuencia del Sistema Lección 38. Creación de los Diagramas de Interacción Lección 40. Construcción Diagramas de Diseño Lección 41. Implementación y Pruebas Capítulo 9. PILARES DE LA ORIENTACIÓN A OBJETOS Lección 42. Abstracción Lección 43. Herencia Lección 44. Polimorfismo Lección 45. Encapsulamiento

4 Lección 46. Relaciones

5 TABLA DE GRAFICAS FIGURA 1: CREADORES DEL LENGUAJE UML 11 FIGURA 2: EVOLUCIÓN 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: DÍA 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: ASOCIACIÓN 31 FIGURA 15: ROLES 32 FIGURA 16: AGREGACIÓN 33 FIGURA 17: CONJUNTO DE CLASES 36 FIGURA 18: CONJUNTO DE CLASES EXTRAÍDAS DE UN SISTEMA DE INFORMACIÓN 37 FIGURA 19: INTERFAZ 38 FIGURA 20: TIPOS DE DATOS 38 FIGURA 21: SEÑAL 38 FIGURA 22: COMPONENTE 38 FIGURA 23: NODO 39 FIGURA 24: CASO DE USO 39 FIGURA 25: SUBSISTEMA 39 FIGURA 26: NOTACIÓN 40 FIGURA 27: HERENCIA MÚLTIPLE 41 FIGURA 28: ASOCIACIÓN 42 FIGURA 29: INTERFACES 43 FIGURA 30: ABSTRACCIÓN CON UNA INTERFAZ 43 FIGURA 31: DIAGRAMA DE INTERACCIÓN ENTRE CLASES 44 FIGURA 32: RELACIÓN DE CLASES EN NOTACIÓN 44 FIGURA 33: OBJETO DENTRO RELACIÓN DE CLASES EN NOTACIÓN 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 INTERACTÚAN CON EL SISTEMA 53 FIGURA 40: CLIENTE PUEDE DEPOSITAR ÍTEMS Y UN OPERADOR PUEDE CAMBIAR LA INFORMACIÓN DE UN ÍTEM O BIEN PUEDE IMPRIMIR UN INFORME 53 FIGURA 41: DEPOSITAR ÍTEM 53 FIGURA 42: PETICIÓN A UN OPERADOR 54 5

6 FIGURA 43: DISEÑO COMPLETO DEL DIAGRAMA DE CASOS DE USO 54 FIGURA 44: TRANSICIONES Y ACTIVACIONES 55 FIGURA 45: FLUJO DE CONTROL 56 FIGURA 46: ESTADOS DE ACCIÓN 58 FIGURA 47: SUBMAQUINAS 58 FIGURA 48: TRANSICIONES 59 FIGURA 49: BIFURCACIONES 59 FIGURA 50: DIVISIÓN Y UNIÓN 60 FIGURA 51: CALLES 60 FIGURA 52: SEÑALES 61 FIGURA 53: EVENTOS 62 FIGURA 54: UN EVENTO DE CAMBIO O DE TIEMPO 62 FIGURA 55: ESTADOS 63 FIGURA 56: TRANSICIONES 64 FIGURA 57: TIEMPO Y ESPACIO 65 FIGURA 58: LOCALIZACIÓN 65 FIGURA 59: DIAGRAMA DE ESTADOS CON TODOS SUS COMPONENTES 67 FIGURA 60: COMPONENTES 67 FIGURA 61: INTERFAZ 68 FIGURA 62: DESPLIEGUE 68 FIGURA 63: COLABORACIONES 69 FIGURA 64: MECANISMOS 69 FIGURA 65: PLANTILLA FORMADA POR UN CONJUNTO DE ABSTRACCIONES 70 FIGURA 66: FRAMEWORKS 70 FIGURA 67: DIAGRAMA DE COMPONENTES 71 FIGURA 68: DIAGRAMAS DE DESPLIEGUE 72 FIGURA 69: SISTEMAS Y MODELOS 73 FIGURA 70: PLANIFICACIÓN DE CASOS DE USO SEGÚN CICLOS DE DESARROLLO 82 FIGURA 71: DIAGRAMA DE SECUENCIA DEL SISTEMA PARA EL CASO DE USO 87 FIGURA 72: DIAGRAMA DE CLASES DE DISEÑO SENCILLO 91 FIGURA 73: CLASE CON NOMBRE DE RUTA 96 FIGURA 74: HERENCIA 97 FIGURA 75: POLIMORFISMO 98 FIGURA 76: ENCAPSULAMIENTO 98 FIGURA 77: ESTRUCTURA DE ENCAPSULAMIENTO 98 FIGURA 78: TIPOS DE LÍNEAS QUE SIMBOLIZAN LAS RELACIONES 99 FIGURA 79: ARGUMENTO DE ASIGNATURA 100 FIGURA 80: GENERACIONALES 100 FIGURA 81: ASOCIACIONES 101 FIGURA 82: REALIZACIÓN 102 6

7 INTRODUCCIÓN Unas de las etapas vitales para un diseñador de software, es el análisis y diseño de sistemas. El análisis de sistemas es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y manejo de la información para hacer mejoras al sistema, siendo el diseño la fase de planificación, reemplazo o complementación 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 estándar 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 estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos 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 académico 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 construcción de los diagramas de interacción del sistema, hasta la aplicación del modelo en un caso real de desarrollo. 7

8 JUSTIFICACIÓN El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de modelado y no un método o un proceso. El UML está compuesto por una notación muy específica y por las reglas semánticas relacionadas para la construcción de sistemas de software. UML en sí mismo no prescribe ni aconseja cómo usar esta notación en el proceso de desarrollo o como parte de una metodología de diseño orientada a objetos. El UML soporta un conjunto rico en elementos de notación gráficos. Describe la notación para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cómo modelar la relación entre esos elementos. UML también soporta la idea de extensiones personalizadas a través 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 diseñadores de software, UML muestra la forma en la cual se modelan diseños prácticos con los cuales a través de los casos de usos, diagramas de interacción se llega en conjunto con el análisis al diseño del software de manera segura sobre casos reales detallados en los diagramas de estados, además, UML como lenguaje se implementa en el diseño y en la base de datos, es decir, el diseño se complementa con pruebas sobre el resultado final del modelo a ser programado. 8

9 OBJETIVOS 1. Fomentar la realización 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 guíen en la construcción de un software orientado a objetos. 9

10 PRIMERA UNIDAD INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO 10

11 UNIDAD 1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO CAPITULO 1. QUÉ ES UML? El Lenguaje Unificado de Modelado (Unifield Modeling Lenguaje UML), es un lenguaje estándar 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 estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos 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 sólo un lenguaje y por tanto es tan solo una parte de un método de desarrollo de software, además, es independiente del proceso, aunque para utilizar óptimamente se debería 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

12 UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares, en 1996, el Object Management Group (OMG), publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 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 versión 1.1. Este documento fue aprobado por el OMG en Noviembre de El OMG llama a este documento OMG UML versión 1.1. El OMG estaba actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de Lección 1. Por qué Aprender UML? Los programadores en los inicios de los sistemas de computación no realizaban análisis fuertes o profundos sobre u problema a resolver, eventualmente realizaban un bosquejo o medianamente un diagrama con poca técnica donde se daba a entender una idea mínima de lo que pensaban realizar en el proceso de programación. A los programadores se podrían considerar como temerarios en el desarrollo de aplicaciones, ya que estás se está ajustando según 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 razón los sistemas de información en la actualidad parten de un análisis y diseño 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 opinión frente a un proceso y aplicarlo de otra manera en el sistema, una vez el diseño sea claro y que sea de completo consentimiento del cliente, el grupo de trabajo procederá a desarrollar la solución tal cual como se diseñó. A medida que el mundo evoluciona este se vuelve más complejo y los sistemas de información aumentan su complejidad y se debe dar respuesta a las necesidades que se presenten. Es de reconocer que todo influye en un sistema de información: el hardware, software, internet, redes, base de datos y muchas más variables que intervienen en el proceso y que se evidencian en grandes cantidades de información. Es por ello que si desea crear un sistema en la actualidad, se deberá partir con la pregunta: Cómo se manejara un nivel tan alto de complejidad? UML es la respuesta, pues mediante este lenguaje se organizará el proceso de diseño donde los analistas, clientes, desarrolladores y todo el equipo de trabajo que 12

13 intervenga en el proyecto, comprenderán y participará en la mejor solución al problema presentado, enfrentando la complejidad que se presente y se resuelva de una manera organizada. Por ejemplo: un carro, un avión un edificio, parten de un diseño (Dibujo) muy detallado y aunque estos resultados se evidencian de forma tangible, no significa que un sistema de información que es intangible no cuente con su propio diseño, por el contrario, si dicho sistema cuenta con una buena planificación en su diseño, obtendrá un excelente resultado para el usuario final. También es importante tener claro, que un sistema de información que cuente con un buen diseño (dibujo), permitirá realizar fácilmente futuras modificaciones de manera puntual y precisa, ahorrando tiempo y dinero en el proceso de actualización en la programación de una solución anteriormente diseñada. Lección 2. UML no es un método Inicialmente los métodos son una técnica para llevar a cabo una acción, UML es un compendio de modelos que pueden ser interpretados de forma directa a una gran variedad de lenguajes de programación 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 estándar sobre análisis y diseño de sistemas orientados a objetos. De los más populares se incluyen los siguientes: Catálisis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas específicas para modelar componentes distribuidos. Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson. Shlaer/Mellor: El método para diseñar 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 continúan actualizando su método continuamente (la actualización más reciente es el OOA96 report), y recientemente publicaron una guía sobre cómo usar la notación UML con Shlaer/Mellor. Fusión: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos estándar. Combina OMT y Booch con tarjetas CRC y métodos formales. ( OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que propone análisis y diseño 13

14 interactivo, más centrado en el lado del análisis. Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, With Applications), detallan un modo ofreciendo también diseño y análisis 'iterative', centrándose en el lado del diseño. Lección 3. Evolución del Lenguaje UML Figura 2: Evolución del Lenguaje UML 14

15 Desde su indicio ya se evidenciaba un buen grado de precisión que ha tenido el lenguaje de modelado unificado UML, donde muchas de las mejores tácticas en diseño le pertenecen y se espera que este lenguaje sea la base de muchas herramientas aplicadas al modelamiento visual, simulación y desarrollo de diferentes ambientes, a medida que estas aplicaciones implementen más 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 métodos 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 módulo no es prudente entrar a mediar otros temas diferentes, por ello se registran las siguientes siglas que serán una incógnita que deberá responde cada uno de los futuros ingenieros MSF, RUP, DSL, OMG e IBM y mirar hacia donde se inclinarían en el caso de que consideren que el lenguaje UML no cumple sus requerimientos. Lección 4. Beneficios de Esta Tecnología AL utilizar el lenguaje de modela los beneficios son diversos, entre estos tenemos: 1. Minimizar Costos: esto se evidencia según el tamaño de la organización donde se aplique y un buen desarrollo del diseño. 2. Calidad: La aplicación del lenguaje UML hace necesario la participación del usuario en la definición de requerimientos y por ende mejora notablemente un sistema según sean las necesidades del usuario. El mantenimiento correctivo y/o reparaciones se reduce drásticamente. Algo similar ocurre en los proyectos de reingeniería. 3. Mejor soporte a la planeación 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 fácil 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. También parte de un buen diseño 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

16 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 tecnológico. Con UML todos los cambios que se considere para un sistema, pueden ser probados primero en papel y según los resultados que arrojen en la planificación y diseño se cuantificara el impacto que generen los cambios realizados antes de aplicarlo directamente en el sistema, permitiendo probar diferentes alternativas y seleccionar la más favorable para el cliente. 6. Alto reusó. Regularmente los sistemas comparten ciertas similitudes y es muy probable que partes de un diseño y rutinas de programación puedan ser usadas por sistema, a este se le denomina reusó que en ocasiones esta favorece una administración adecuada, un bajo costo y la minimización de errores. 7. Mejores tiempos totales de desarrollo (de 50% o más). Si se cumple con los pasos anteriores el tiempo de desarrollo baja drásticamente y se podría en considerar que se tendría un ahorro hasta del 50% según el tamaño del sistema. Es por ello que es de suma importancia realizar un análisis a profundidad y dedicar el tiempo necesario para el diseño y así en las etapas de construcción, implementación y estabilización se aminore el tiempo ya que los errores fueron corregidos en las fase de mayor impacto con el sistema. Lección 5. En donde Utilizamos UML Partamos recordando que el Lenguaje de Modelado Unificado UML, es para hacer modelos que faciliten visualizar como es y cómo queremos un sistema. Este modelado es una plantilla que se usara como guía para el desarrollo de un sistema y así dejar documentado todo el proceso de producción del mismo. Banco y servicios financieros Telecomunicaciones, transporte Defensa/industria aeroespacial Electrónica médica Ámbito científico También se pueden modelar workflows en un sistema jurídico, diseño 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 económica a la misma institución que la pudiese afectar fuertemente. 16

17 CAPITULO 2. MODELOS Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Lección 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 Colaboración Diagrama de Estados Diagramas de clases: muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones, son los más comunes en el modelo orientado a objetos y cubren las vistas de diseño estático de un sistema. Diagramas de Objetos: muestra un conjunto de objetos y sus relaciones, representan instancias de los elementos encontrados en los diagramas de clases, representado cubren las vistas de diseño estático de un sistema desde 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 dinámica 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 organización y las dependencias entre un conjunto de componentes, cubren la vista estática de un sistema. Diagrama de Despliegue: muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos, cubren la vista de despliegue estática 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 estática de un sistema. Diagrama de Secuencia: es un diagrama de interacción que resalta la ordenación 17

18 temporal de los mensajes. ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Diagrama de Colaboración: es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensaje. Diagrama de Estados: Muestra una máquina de estados, que consta de estados, transiciones, eventos y actividades, cubren la vista dinámica de un sistema, resaltan el comportamiento dirigido por eventos de un objeto. Lección 7. Notas y Dependencias Notas Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión, nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo 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 línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc. Figura 3: Nota Dependencias La relación 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 habría que revisar el elemento origen). Una dependencia se representa por medio de una línea 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

19 Lección 8. Elementos comunes a todos los diagramas Un elemento es considerado como una abstracción y dichos elementes se clasifican en estructurales, de comportamiento, de agrupación y de anotación. En esta lección daremos una descripción general, ya que a medida que se profundice en el contenido del módulo se dará respuesta a cada uno de los términos de relaciones a este espacio. Figura 4: Elementos Elementos de agrupamiento: Se realiza mediante el elemento de agrupación denominado paquete, es presentada por una caja que dentro de esta se puede se descompuesto un modelo. También aparecen los Frameworks, modelos y subsistemas como a variaciones o tipos de paquetes. Elementos estructurales: Es hace referencia a la parte estética de un modelo, representando elementos conceptuales o físicos. Son siete los tipos de elementos estructurales que son: Clase, Interfaz, Colaboración, Caso de uso, clase activa, componente, y nodo. Es importante tener muy claro que los nodos y componentes representan elementos físicos. 19

20 Al igual que los elementos de agrupación en estos elementos tampoco encontramos con variaciones a los siete elementos mencionados que se identifican como: Tipos de clase: actores, señales, utilidades, Tipos de clases activas: procesos e hilos y Tipos de Componentes: aplicaciones, documentos, archivos, bibliotecas, páginas y tablas. Elementos de comportamiento: Es la parte dinámica de un modelo y se ve representada por los verbos que representan una función sobre tiempo y espacio. Se identifican dos tipos de elementos de comportamiento: la interacción y la máquina de estado. Elementos anotación: Son los comentarios explícitos o muy detallados de un modelo UML y se aplican para describir, iluminar y remarcar algunos elementos del modelo. Solo presenta un tipo de elemento de anotación que es denominado Nota y este re registraran los comentarios y limitaciones asociados a un elemento o una colección de datos. Lección 9. Fases de Desarrollo Partamos identificando que un modelo es la representación 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

21 Análisis: es donde se lleva el lenguaje natural a un lenguaje técnico que es fácilmente interpretado por desarrollador de un sistema. Diseño: 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 diseño depende el resultado de un sistema. Programación: son todas las actividades necesarias para transformar los requerimientos de un usuario plasmado en un diseño 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. Análisis de Requerimiento: es la fase donde el propósito fundamental es dejar muy claro cuáles son las necesidades del usuario y los requerimientos. Lección 10. Herramientas Para Modelado El kit más importante en cuanto a herramientas prácticas y fáciles de conseguir son: papel, lápiz, borrador y saca punta, para realizar un diseño UML. Puede sonar raro cuando estamos hablando de software y tecnología pero estos materiales son formidables para realizar diferentes tipos de diseño, en cualquier área. En esta lección no se entrara a detallar herramientas o aplicaciones ya que esta función la realizará diversos sitios web y los sitios principales de cada herramienta a los cuales les corresponden convencer a los futuros ingenieros. A continuación se relacionarán varias herramientas de modelado gratuito, esto no significa que son necesariamente software libre y quedarán muchísimas sin descubrir o recomendar que pudieran ser mejores, pero esto depende de la autonomía de cada uno de los diseñadores y también de los recursos económicos en el caso de que se requiera obtener una licencia. Las recomendaciones que se registran a continuación son tomadas de la página 1. ArgoUML (Clic para que acceda a la página principal de la aplicación) 21

22 Figura 6: ArgoUML Editor UML ArgoUML es un editor UML gratuito que tiene compatibilidad con el estándar UML 1.4. Permite la exportación a varios formatos gráficos y tiene la disponibilidad de perfiles para varios lenguajes de programación. Es mi herramienta favorita, aunque solo tiene soporte para UML 1.4 (la última versión de UML es 2.4.1). Al ser programado en Java, ArgoUML tiene la característica de ser multiplataforma. Entre sus características resalta lo siguiente: Exportación de diagramas a diferentes formatos Generación de código Soporte para bases de datos Soporte cognitivo: 22

23 Críticas de diseño creado, listas de cosas por hacer (To Do Lists), correcciones automáticas, entre otros. Comprensión y solución del problema 2. Día (Clic para que acceda a la página principal de la aplicación) Figura 7: Día Editor de UML Día es un programa de creación de diagramas, similar al programa Visio de la suite de ofimática de Microsoft Office. Está basado en GTK+, biblioteca con objetos y funciones para la interfaz gráfica de usuario, y tiene licencia GPL. Dispone de una gran serie de extensiones que permiten la elaboración de diagramas entidad-interrelación, UML, flujo de datos, diagramas de red, entre otros. 3. Frame UML (Clic para que acceda a la página principal de la aplicación) Herramienta gratuita UML de fácil uso con soporte para UML 2, está pensado 23

24 para funcionar sobre Windows. Permite la generación de código desde el modelo. Tiene soporte para 12 tipos de diagramas, excepto diagramas de objetos. 4. StarUML (Clic para que acceda a la página principal de la aplicación) StarUML es una herramienta de fácil uso que ayuda a generar diagramas compatibles con la suite de ofimática de Microsoft Office. Tiene código es compatible con C++ y Java. Y se puede empezar a dibujar manualmente o hacer uso de plantillas que contienen archivos de instalación, para modificarlas pensado en las persona que no están acostumbrada o que no hayan trabajado con anterioridad en modelamiento UML. 5. Tiny UML (Clic para que acceda a la página principal de la aplicación) TinyUML es una herramienta gratuita de modelado UML de fácil uso y de rápida creación de diagramas UML 2 implementado en la plataforma Java, requiere Java SE Eclipse (Clic para que acceda a la página principal de la aplicación) La aplicación de eclipse no funciona como una herramienta directa de UML, sino que requiere una extensión para realizar el modelado, además que facilita que los diagramas que se realicen en dicha herramienta se conviertan en código. Se recomienda descargar las siguientes extensiones para ser aplicada al eclipse y poder realizar el diseño en este programa. UML2 UML2 Tools Seleccione la herramienta según se ajuste a sus requerimientos y considere que la más fácil manejar y a medida que su nivel práctico y de conocimiento en el manejo del lenguaje de modelado le permita escoger la herramienta más avanzada. Es importante entender que hay herramientas muy buenas, pero no necesariamente significa que será la que el diseñador utilice, ya que puede considerar la herramienta menos conocida pero que le arroje excelentes resultados y el nivel de manejo sea cómodo. Se recomienda Eclipse y StarUML, pero siéntase libre de tomar la mejor decisión que usted considere. Es muy posible que se trabaje con una sola aplicación para dar cumplimiento a un desarrollo académico, 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 básicos de construcción 24

25 de UML, las reglas que dictan cómo se pueden combinar estos bloques básicos y algunos mecanismos comunes que se aplican a través de UML. Una vez comprendidas estas ideas, se pueden leer los modelos UML y crear algunos modelos básicos. Lección 11. Bloques de Construcción de UML El vocabulario de UML incluye tres clases de bloques de construcción Elementos en UML Hay 4 tipos de elementos en UML, elementos estructurales, elementos de comportamiento, elementos de agrupación y elementos de anotación: Figura 8: Elementos UML 25

26 Elementos Estructurales ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Nombre Descripción Símbolo Es una colección de operaciones que especifica un servicio de una clase o componente, Interfaz representa el comportamiento completo de una clase o componente Colaboración Caso de Uso Clase Activa Componente Nodo Se definen como una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos las colaboración representan la implementación de patronesque Es una forman descripción un sistema. de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Se utiliza para estructurar el comportamiento en un modelo Es un clase objetos tienen uno o mas procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control. Son iguales a las clases excepto en que sus objetos representan elementos cuyos comportamiento es concurrente con otros elementos. Es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto Representa típicamente e empaquetamiento físico de diferentes elementos lógicos, como clases interfaces y colaboraciones Es un elemento físico que existe en tiempo de ejecución y representa un recursos computacional que dispone de memoria y con frecuencia capacidad de procesamiento Nodo1 26

27 Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos) son los elementos estructurales básicos que se pueden incluir en el modelo UML. También existen variaciones de estos siete elementos, tales como actores, señales, procesos, hilos y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas. Los elementos de comportamiento: son las partes dinámicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y en el espacio. Interacción: e s un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propósito especifico Máquina de Estados: es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos Estos dos elementos (interacciones y máquinas de estado) son los elementos de comportamiento que se pueden incluir de un modelo UML, estos elementos están conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos. Los Elementos de agrupación: son las partes organizativas de los modelos UML. Estos son las cajas en las que pueden descomponerse un modelo Paquete: es un mecanismo de propósito general para organizar elementos en grupos. En los paquetes se pueden agrupar los elementos estructurales, de comportamiento e incluso otros elementos de agrupación Los paquetes son los elementos de agrupación básicos con los cuales se puede organizar un modelo UML. También hay variaciones, tales como los framework, los modelos y los subsistemas. Relaciones: Existen cuatro tipos de la relaciones en UML Dependencias Asociaciones Generalizaciones Realización Estas relaciones son los bloques básicos de construcción para las relaciones de UML. 27

28 Relaciones en UML Dependencia: es una relación semántica entre dos elementos, en la cual un cambio a un elemento puede afectar el significado de otro elemento. Asociaciones: es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objeto y representan una relación estructural entre un todo y sus partes. Diagramas: un diagrama es la representación gráfica de un conjunto de elementos, visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyección 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 de este módulo). Clases: una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Las clases pueden representar cosas como hardware, software o solo conceptuales y también forman parte de una distribución equilibrada de responsabilidades en el sistema UML representa una representación gráfica de las clases como se muestra en la figura. Figura 9: Clases Componentes de las Clases Una clase es una descripción de un conjunto de objetos que comparten los mimos atributos, operaciones, relaciones y semánticas. Gráficamente una clase se representa como un rectángulo, en el cual se describen las características de los objetos que representa, entre ellos tenemos. 28

29 1. Nombre: una clase debe contener un nombre que la identifique, compuesto por cualquier número de letras y números 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, además, 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 abstracción 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 través 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 más general los atributos y operaciones son las características por medio de la cuales se llevan a cabo las responsabilidades de la clase. Gráficamente las responsabilidades se pueden expresar en un comportamiento separado al final del icono de la clase. 29

30 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 solución. 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 solución. Identificar las responsabilidades de cada clase y asegurarse que cada clase existe. Identificar los atributos y operaciones necesarios para cumplir sus responsabilidades. Hacer del conjunto de clases y sus responsabilidades un modelo equilibrado donde no existan clase demasiado grandes ni pequeñas Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de la clase que sean importantes, como también sus atributos y 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, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase. 30

31 Figura 13: Objetos Asociaciones Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Dada una asociación entre dos clases, se puede navegar desde un objeto de una clase hasta el objeto de otra clase, y viceversa. Una asociación que conecta dos clases se dice binaria, sí conecta más de dos clases se denomina asociación n-arias, las asociaciones se utilizarán cuando se quieren representar relaciones estructurales. Características de las Asociaciones y operaciones Nombre de la Asociación y Dirección El nombre de la asociación se utiliza para describir la naturaleza de la relación, es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección y permita leer el nombre de la asociación. En el ejemplo se puede leer la asociación como Director manda sobre Empleado. Figura 14: Asociación Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre. 31

32 Multiplicidad ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un número fijo: 1. Con un intervalo de valores: 2.5. Con un rango en el cual uno de los extremos es un asterisco Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más. Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*. Con un asterisco: *. En este caso indica que puede tomar cualquier valor (cero o más). Roles Un rol es simplemente la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. Figura 15: Roles Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol. 32

33 Agregación El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el todo. Figura 16: Agregación Lección 12. Diagramas Un diagrama es una presentación gráfica de un conjunto de elementos, que la mayoría 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 proyección gráfica de los elementos que configuran un sistema. Por ejemplo, se podría tener cientos de clases en el diseño de un sistema de recursos humanos de un empresa, pero no se podría 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 estáticas de los sistemas en UML se representan con 4 tipos de diagramas que se describen a continuación 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 más comunes en el modelado de sistemas orientados a objetos. Estos diagramas se utilizan para describir las vista de diseño estática de un sistema, incluyen clases activas se utilizan para cubrir la vista de procesos estática de un sistema 33

34 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 diseño estática o la vista de proceso estática 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 implementación estática de un sistema, se relacionan con los diagramas de clases en que un componente normalmente se corresponde con una o más clases. Interfaces o colaboraciones Diagramas de despliegue Muestra un conjunto de nodos y sus relaciones, se utilizan para describir la vista de despliegue estática de una arquitectura, se relacionan con los diagramas de componentes en que un nodo normalmente incluye uno o más componentes. Diagramas de Comportamiento Los cuales están 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 más 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 interacción que resalta la ordenación 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 dinámica de un sistema. Diagramas de colaboración Son diagramas de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes, pueden representar instancias de otros elementos como colaboraciones, componentes y nodos. Se utilizan para describir la vista dinámica de un sistema. 34

35 Diagramas de estado Representan una máquina de estados constituida por estados, transacciones, eventos y actividades, se utilizan para representar la vista dinámica de un sistema son especialmente importantes para modelar el comportamiento de una interfaz, clase o una colaboración, 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 actúa, son importantes para modelar la función de un sistema así como para resaltar el flujo de control entre objetos Lección 13. Diagramas de Clase Un diagrama de clases de uso muestra un conjunto de interfaces, colaboraciones y sus relaciones. Gráficamente, un diagrama de clases es una colección de nodos y arcos. Los diagramas de clases contienen normalmente los siguientes elementos, clases, interfaces, colaboraciones, relaciones de dependencia, generalización y asociación. Los diagramas pueden también notas, restricciones, paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes más grandes. Usos de los diagramas de clases Se utilizan para modelar la vista estática 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 diseño 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 consideración y cuales caen fuera de sus límites. Los diagramas de clases se utilizan para especificar estas abstracciones y sus responsabilidades Para modelar colaboraciones simples Una colaboración 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

36 Cuando se crea un diagrama de clases, se está modelando una parte de los elementos y las relaciones que configuran la vista de diseño del sistema, por esta razón, cada diagrama de clases debe centrarse en una colaboración cada vez. Para modelar una colaboración se debe tener en cuenta: Identificar los mecanismos que se quiere modelar, un mecanismo representa una función o comportamiento de la parte del sistema que se está modelando que resulta de la interacción de una sociedad de clases, interfaces y otros elementos. Identificar las clases, interfaces y otras colaboraciones que participan en esta colaboración identificando las relaciones entre estos elementos. Usar escenarios para recorrer la interacción entre estos elementos. Identificar las responsabilidades y hacer un reparto equilibrada de ellas en los elementos que componen el sistema. Por ejemplo la siguiente figura muestra un conjunto de clases que muestran el sistema de facturación y control de ventas de una empresa, las clases se centran en la forma como se maneja la facturación de inmuebles y productos de consumo. Aparece una clase abstracta llamada factura que muestra a su vez 2 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 asociación uno a uno con vendedor y una asociación 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 lógico de base de datos Este esquema representa el plano que permite el diseño conceptual de la base de 36

37 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 diseño general de la bases de datos. Crear un diagrama de clases que contenga estas clases y marcarlas como persistentes. Expandir los detalles estructurales de estas clases, es decir, especificar los detalles de sus atributos y centrar su atención en 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 manipulación de datos dentro de la base de datos La figura muestra un conjunto de clases extraídas de un sistema de información que determina las relaciones entre los estudiantes, el profesor y el curso que el estudiante va a estudiar Figura 18: Conjunto de Clases Extraídas de un Sistema de Información El anterior diagrama muestra en detalle cada una de las clases con sus respectivos atributos, los cuales permiten construir la base de datos física, comenzando por la parte inferior izquierda se encuentra las clases estudiantes, curso y profesores, hay una asociación. 37

38 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. Lección 14. Características avanzadas de las clases y relaciones El tipo más importante de clasificador en UML es la clase, una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Sin embargo, las clases no son el único tipo de clasificador, existen otros tipos de clasificadores que ayudan a modelar: Interfaz: es una colección de operaciones que especifican un servicio de una clase o componente Figura 19: Interfaz Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos primitivos predefinidos. Figura 20: Tipos de Datos Señal: la especificación de un estímulo asíncrono enviado entre instancias Figura 21: Señal Componente: una parte física y reemplazable de un sistema que conforma y proporciona la realización de un conjunto de interfaces. Figura 22: Componente Nodo: un elemento físico que existe en tiempo de ejecución y representa 38

39 un recurso computacional, generalmente con alguna memoria y a menudo capacidad de almacenamiento. Figura 23: Nodo Caso de uso: descripción de una secuencia de acciones, incluye variantes, que se ejecuta un sistema y produce un resultado observable para un actor particular Figura 24: Caso de Uso Subsistema: agrupación de elementos, algunos de los cuales constituyen una especificación 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 mostrándolo 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 definición de sus atributos ciertos tipos de símbolos, los cuales determinan si los elementos asociados a cada clase son públicos o privados por ejemplo: Si la marca de elemento es un +, indica que este elemento es de acceso público 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

40 semi privados, solo se relacionan con las clases que han sido descendientes de la clase padre y estas se marcan con el símbolo #. Cuando se usa una clase, es probable que se deseen características de otras clases y también permitir que otras clases más específicas hereden características de ella. También 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 característica de las clases, es cuando esta no tiene padres, este tipo de clases se denomina raíz y se denota escribiendo debajo del nombre de la clase root. Podemos observar el siguiente ejemplo de notación: Figura 26: Notación Las clases tienen muchas operaciones entre sí, las que se heredan entre clases se denominan polimórficas esto ocurre cuando los objetos han ejecutado una operación que está definida en la clase que los contiene pero con la diferencia de que la operación 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, también hay que modelar cómo se relacionan entre sí estos elementos, las relaciones de dependencia, las generalizaciones y las asociaciones son los tres bloques de construcción de relaciones más importantes de UML. Observemos el comportamiento de estas relaciones. 40

41 Relaciones de Dependencia: Una dependencia es una relación de uso, la cual especifica que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente a la inversa. Gráficamente, una dependencia se representa como una línea 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 Generalización Una generalización es una relación entre un elemento (superclase o padre) y un tipo más efectivo de ese elemento (subclase o hijo). Por ejemplo, se puede encontrar la clase general ventana junto a un tipo más específico ventaconmarco, con una relación de generalización del hijo al padre, el hijo ventaconmarco heredará la estructura y comportamiento del padre ventana, en una generalización la instancia del hijo pueden usarse donde quiera que se puedan usar las instancias del padre. La generalización se manifiesta en la herencia simple que a veces es suficiente en la mayoría de las veces, aunque, la herencia múltiple es más adecuada, gráficamente se muestra de la siguiente forma: Figura 27: Herencia Múltiple 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 Acción 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

42 Relaciones de Asociación Una asociación es una relación estructural que especifica que los objetos de un elemento se conectan a los objetos de otro, por ejemplo, una clase biblioteca podría tener una asociación uno a muchos con clase libro, indicando que cada instancia de libro pertenece a una instancia de biblioteca, además, dado un libro, se puede encontrar su biblioteca, y dando una biblioteca se puede navegar hacia todos los libros, gráficamente, un asociaciones se representa con una línea continua entre la misma o diferentes clases. Las relaciones se utilizan para mostrar relaciones estructurales. En la siguiente asociación simple se muestra como se hace la navegación entre objetos, por ejemplo al modelar una asociación 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 podría identificar al Usuario correspondiente. Figura 28: Asociación La línea representa una asociación y la fecha indica la dirección 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 construcción de interfaces permite también el manejo de librerías estándar reutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sin necesidad de afectar el funcionamiento general del sistema. Se entiendo como interfaz como una colección 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

43 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 métodos, pero estas pueden contener cualquier número de operaciones. La siguiente notación hace referencia a una interfaz donde se manifiesta de manera gráfica su nombre y operaciones a diferencia de la notación del círculo presentada anteriormente. Proporciona un mecanismo para modelar la conformidad estática y dinámica de una abstracción con una interfaz en un contexto específico Figura 30: Abstracción con una Interfaz Nótese en la representación 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 generalización, relaciones de asociación y relaciones de dependencia. Como se mostró anteriormente las interfaces se pueden denotar mostrándose como un círculo o con sus operaciones, dentro de un diagrama de interacción entre clases los resultados para mostrar las relaciones entre las clases a través de las interfaces se expresa de la siguiente manera: 43

44 Figura 31: Diagrama de Interacción entre Clases La primera forma es la sencilla en la cual se muestra la conexión de dos clases a través de un circulo que representa la interfaz con la cual se comunican dichas clases, la segunda forma, muestra de manera más detallada las operaciones con las cuales interactúan las clases definidas antes y después de la interface, nótese 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 matemáticas, sociales, informática, física, etc, para cada rol generado de clase profesor, se deduce que las propiedades cada rol son exclusivas y en ningún momento pueden tomar propiedades de un rol que no le corresponda. Para representar el rol que representa un objeto dentro de una relación de clases en notación UML se tiene por ejemplo: Figura 32: Relación de Clases en Notación 44

45 Figura 33: Objeto Dentro Relación de Clases en Notación La figura anterior representa una asociación de clases con una interfaz específica, como se ve existe una asociación 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 propósito general para organizar elementos en grupos, gráficamente un paquete se representa como una carpeta. Cada paquete a de contener un nombre que lo distingue de los demás. 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 manifestación concreta de una abstracción a la que se puede aplicar un conjunto de operaciones y que posee un estado que almacena el efecto de las operaciones. Gráficamente una instancia se representa subrayando su nombre. 45

46 Figura 35: Instancias Las instancias no aparecen aisladas, casi siempre están ligadas a una abstracción. La mayoría de las instancias que se modelan en UML serán 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 físicamente en una habitación; 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 física, análogamente, una instancia de un billete de avión es algo sobre lo que se pueden hacer cálculos. Lección 15. Herencia y polimorfismo Polimorfismo Una de las características fundamentales de la OOP es el polimorfismo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro) Herencia En programación orientada a objetos, la herencia es un mecanismo que hace posible que una clase herede todo el comportamiento y atributos de otra clase; a través 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

47 en que se diferencian de la clase existente, es decir, que toma la definición previa de la cual es subclase, y que solo se le agrega características especiales que la difieren de la clase de la cual procede. La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase padre. 47

48 SEGUNDA UNIDAD CARACTERÍSTICAS DEL MODELADO UML 48

49 UNIDAD 2. CARACTERÍSTICAS DEL MODELADO UML CAPITULO 4. DIAGRAMAS UTILIZADOS EN UML Lección 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 estáticos del sistema y los diagramas de interacción se utilizan para ver los aspectos dinámicos 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 sólo la parte estática de una interacción, 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 diseño estática o la vista de procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estáticas, En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantánea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena estática dentro de la historia representada por un diagrama de interacción. 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

50 En la figura anterior se representa un conjunto de objetos extraídos de la implementación 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 abstracción 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 aún 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 más configuraciones posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototípicos. Lección 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, además de la forma, tipo y orden en como los elementos interactúan (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 Comunicación. Elementos Actor Figura 37: Actor 50

51 Una definición 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 más bien la labor que realiza frente al sistema. Como ejemplo a la definición 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 operación o tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Relaciones Las relaciones se explicaron de manera específica en el apartado de este módulo, ahora se explica de manera sencilla para observar su uso dentro de los diagramas de casos de uso. Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia 51

52 (<<extends>>). ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde está la duda clásica de usar o heredar. Ejemplo: Como ejemplo está el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar lo siguiente: Registrar el número 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 botón de comienzo Existe un operador que desea saber lo siguiente: Cuantos ítems han sido retornados en el día. Al final de cada día el operador solicita un resumen de todo lo depositado en el día. El operador debe además poder cambiar: Información asociada a ítems. Dar una alarma en el caso de que: Ítem se atora. No hay más papel. Como una primera aproximación identificamos a los actores que interactúan con el sistema: 52

53 Figura 39: Los Actores que Interactúan con el Sistema Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la información de un Ítem o bien puede Imprimir un informe: Figura 40: Cliente Puede Depositar Ítems y un Operador Puede Cambiar la Información de un Ítem o Bien Puede Imprimir un Informe Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba. Figura 41: Depositar Ítem 53

54 Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien puede ser realizada a petición de un operador. Figura 42: Petición a un Operador Entonces, el diseño completo del diagrama casos de uso es: Figura 43: Diseño Completo del Diagrama de Casos de Uso Lección 18. Diagramas de Interacción Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo que conlleva modelar instancias concretas o prototípicas 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 interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia 54

55 y Diagramas de Colaboración. Lección 19. Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según 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 interacción, sin un orden prefijado. Cada objeto o actor tiene una línea 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

56 Los diagramas de secuencia tienen 2 características que los distinguen de los diagramas de colaboración, en primer lugar está la línea de vida de un objeto que es la línea discontinua vertical que representa la existencia de un objeto a lo largo de un periodo de tiempo. La mayoría de los objetos que aparecen en un diagrama de secuencia existirán mientras dure la interacción, los objetos se colocan en la parte superior del diagrama con sus líneas de vida dibujadas de arriba hasta abajo. Pueden crearse objetos durante la interacción, sus líneas de vida comienzan con la recepción de mensajes estereotipado como créate. Los objetos pueden destruirse durante la interacción, sus líneas de vida acaban con la recepción del mensaje estereotipado como destroy, además, se muestra la señal visual de una gran X que marca el final de sus vidas. Lección 20. Diagrama de Colaboración Un diagrama de colaboración destaca la organización de los objetos que participan en una interacción, un diagrama de colaboración se construye colocando en primer lugar los objetos que participan en la colaboración como nodos de un grafo. A continuación se representa los enlaces que conectan esos objetos como arcos de grafo, por último, estos enlaces se adorna con los mensajes que envían y reciben los objetos, esto da al lector una señal visual clara del flujo de control en el contexto de la organización estructural de los objetos que colaboran Figura 45: Flujo de Control Los diagramas colaboración tienen dos características que los distinguen de los diagramas de secuencia, el primero para indicar cómo se enlaza un objeto a otro, se puede asociar un objeto al extremo más lejano de un enlace con la palabra local que indica que el objeto designado es local al emisor. En segundo lugar está el número de secuencia, para indicar la ordenación temporal de los mensajes, se precede de un número iniciando con el numeral 1, que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control. 56

57 Lección 21. Diagramas de Actividades Un diagrama de actividades muestra el flujo de actividades, siendo un actividad una ejecución general entre los objetos que se está ejecutando en un momento dado dentro de una máquina de estados, el resultado de un actividad es una acción que producen un cambio en el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras operaciones, envío de señales, creación o destrucción de objetos o simples cálculos. Gráficamente un diagrama de actividades será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido. Contenido del diagrama de actividades Básicamente un diagrama de actividades contiene: Estados de actividad Estados de acción Transiciones Objetos Estados de actividad y estados de acción La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como una acción, no queda impuesta por UML, se podría utilizar lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: Un estado que represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida, Al igual que en el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un círculo) y uno final (representado como dos círculos concéntricos). En la siguiente figura, podemos ver ejemplos de estados de acción. 57

58 Figura 46: Estados de Acción En cambio un estado de actividad, sí puede descomponerse en más subactividades representadas a través de otros diagramas de actividades. Además 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 cuestión, así como definición de submáquinas, 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 acción. Esta transición se produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo siguiente. 58

59 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 bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar a la bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado estado cuando el resto de guardas han fallado. Veamos un ejemplo de bifurcación. Figura 49: Bifurcaciones 59

60 División y unión No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se requieren tareas concurrentes. UML representa gráficamente el proceso de división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial, por una línea horizontal ancha. Podemos ver cómo se representa gráficamente. Figura 50: División y unión 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 organización responsable de las actividades que aparecen en esa calle. Gráficamente quedaría como se muestra a continuación Figura 51: Calles 60

61 CAPITULO 5. MODELADO DINÁMICO Lección 22. Eventos y señales Un evento es la especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio. En el contexto de las máquinas de estado, un evento es la aparición de un estímulo que puede disparar una transición de estado. Una señal es un tipo de evento que representa la especificación de un estímulo asíncrono que es transmitido entre instancias. Señales Una señal representa un objeto con nombre que es enviado (lanzado) asíncronamente por un objeto y recibido (capturado) por otro. El tipo más común de señal interna que se presenta dentro de los lenguajes de programación son las excepciones. Una señal puede enviarse como la acción de una transición de estado en una máquina de estados, o como el envío de un mensaje en una interacción. En UML, la relación entre una operación y los eventos que puede enviar se modela con relación de dependencia, estereotipada como send. Las señales y las excepciones se modelan como clases estereotipadas, se puede utilizar una dependencia, estereotipada como send para indicar que la operación envía una señal particular. Figura 52: Señales 61

62 Eventos ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Un evento de llamada representa una invocación de una operación, un evento puede disparar una transición de estado de una máquina de estados. Cuando un objeto invoca una operación sobre otro objeto que tiene una máquina de estados, el control pasa del emisor al receptor, el evento dispara la transición, la operación acaba, el receptor pasa a un nuevo estado y el control regresa al emisor. Gráficamente se muestra al evento con sus parámetros, como el disparador de una transición 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 expresión que se evalúa para producir algún periodo de tiempo. Un evento de cambio es un evento que representa un cambio en el estado o el cumplimiento de alguna condición, se modela con la palabra when seguida de alguna expresión booleana. Figura 54: Un evento de Cambio o de Tiempo Lección 23. Máquinas de Estado Una máquina 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 condición o situación en la vida de un objeto durante la cual satisface alguna condición, realiza una actividad o espera algún evento. Un evento es la especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y el espacio, es la estimulación que puede disparar una transición de estados. 62

63 Una transición es una relación entre dos estados que indica que un objeto que esté en el primer estado realizará ciertas acciones y entrará el segundo estado cuando ocurra un evento específico y se satisfagan unas condiciones específicas y una actividad es una ejecución no atómica en curso, dentro de una máquina de estados. Estados Un estado es una condición o situación en la vida de un objeto durante la cual satisface alguna condición, 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 preparación (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 continuación un estado se representa con un rectángulo con las esquinas redondeadas. Figura 55: Estados Como se observa en la gráfica anterior en la máquina 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 máquina de estados o el subestado. En segundo lugar, el estado final, que indica la ejecución de la máquina de estado o el estado que lo contiene ha finalizado 63

64 Transiciones ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Una transición es una relación 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 específico y se satisfagan unas condiciones mínimas, cuando se produce este cambio de estado. Se dice que la transición se ha disparado. Hasta que se dispara la transición se dice que el objeto está en el estado origen, después de dispararse se dice que está en el estado destino. Figura 56: Transiciones Una transición tiene cinco partes, estado origen, evento disparado, condición de guarda, acción y estado de destino; una transición se representa con una línea continua dirigida desde el estado origen hacia el destino y una autotransición es una transición cuyos estados origen y destino son los mismos. Lección 24. Tiempo y Espacio Una marca de tiempo denota el instante en el que ocurre un evento, gráficamente, una marca de tiempo es una expresión obtenida a partir del nombre dado al mensaje; una expresión de tiempo es una expresión que al evaluarse genera un valor de tiempo 64

65 absoluto o relativo. Una restricción de tiempo se representa como cualquiera otra restricción, es decir, una cadena de texto entre llaves y normalmente conectada a un electo mediante una relación de dependencia. La localización es la asignación de un componente de un nodo. Gráficamente, la localización se representa como un valor etiquetado, es decir, una cadena de texto entra llaves colocada debajo del nombre del elemento, o mediante la inclusión de componentes dentro de nodos. Figura 57: Tiempo y Espacio En el gráfico anterior se observa la manera como se representa el tiempo y el siguiente gráfico se muestra la localización: Figura 58: Localización 65

66 Lección 25. Transición y Acción Transición Simple: Es la relación entre dos o muchos estados que están unidos por una flecha, identificando a un objeto en un estado primario donde se realizara una acción específica y que pasara a un segundo estado, cuando ocurra un evento y se cumplan unas condiciones específicas avanzando así entre los diferentes estados o cerrando el mismo. Transición Compleja: Se da cuando dos o más estados en una sola transición y tienen varias fuentes o destinos. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado. Transición interna: Tiene un estado origen pero ningún estado destino. Si una transición interna tiene acción, se ejecuta pero no existe cambio de estado. Acción: Es cuando una transición se dispara o se acciona, para que se pueda considerar como una acción se debe de cumplir con alguna de estas: Una sentencia de asignación Una operación aritmética El envío de una señal a otro objeto La invocación de una operación propia Asignación de valores de retorno Creación o destrucción de objetos Una secuencia de acciones simples Lección 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 continuación con todos sus componentes 66

67 Figura 59: Diagrama de estados con todos sus componentes CAPITULO 6. MODELADO ARQUITECTÓNICO Lección 27. Componentes, despliegue, colaboraciones y patrones Componentes Un componente es una parte física y reemplazable de un sistema que conforma un conjunto de interfaces. Gráficamente, un componente se representa como un rectángulo con pestañas, 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 algún comportamiento que indique sus detalles. Como se muestra en la siguiente figura Figura 60: Componentes 67

68 Figura 61: Interfaz Despliegue Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y a menudo capacidad de procesamiento, gráficamente 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 algún comportamiento que indique sus detalles. Como se muestra en la siguiente figura. Figura 62: Despliegue Colaboraciones Una colaboración 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 colaboración es también la especificación de cómo un elemento tal como un clasificador o un operación, es realizado mediante un conjunto de clasificadores y asociaciones que juegan roles específicos utilizados de una forma específica, gráficamente, una colaboración se representa como una elipse con borde discontinua. El nombre de una colaboración puede ser simple o de camino que 68

69 consta del nombre de la colaboración 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 algún comportamiento que indique sus detalles. Como se muestra en la siguiente figura. Figura 63: Colaboraciones Patrones Un patrón es una solución común a un problema común 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 diseño (Mecanismos) y frameworks. Mecanismos Un mecanismo simplemente muestra un conjunto de abstracciones que colaboran entre sí para llevar a cabo algún comportamiento común, 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 algún comportamiento común, se representan como colaboraciones parametrizadas que se muestran de forma parecida a las clases plantilla, observe la siguiente figura 69

70 Figura 65: Plantilla Formada por un conjunto de abstracciones Lección 28. Frameworks Un frameworks es un patrón arquitectónico 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 colaboración EventosComunes que contiene un conjunto de clases evento, junto con un mecanismo GestorDeEventos para procesar estos eventos de forma cíclica. Un cliente que utilice este frameworks tal como un Marcapasos podría construir sobre las abstracciones en EventosComunes creando subclases y también podría emplear una instancia del mecanismo GestorDeEventos. Figura 66: Frameworks 70

71 Lección 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, también puede contener paquetes utilizados para agrupar elementos del modelo. Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre componentes software, sean éstos componentes de código fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán 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 más detallado, un diagrama de clases, o un diagrama de casos de uso. Un paquete en un diagrama de componentes representa una división física del sistema. Los paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida. Un ejemplo típico de una jerarquía en capas de este tipo es: Interfaz de usuario; Paquetes específicos de la aplicación; 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 compilación). Puede mostrar también que un componente software contiene una interfaz, es decir, la soporta. Un ejemplo se muestra a continuación Figura 67: Diagrama de Componentes 71

72 Lección 30. Diagramas de Despliegue Cuando se trata de hardware y el software del sistema, se utiliza los diagramas de despliegue para razonar sobre la tipología de procesadores y dispositivos sobre los que reejecuta el software. Los diagramas de despliegue se utilizan para visualizar los aspectos estáticos de estos nodos físicos y sus relaciones y para especificar sus detalles para la construcción, como se muestra a continuación. Figura 68: Diagramas de Despliegue Un diagrama de despliegue es un diagrama que muestra la configuración de los nodos que participan en la ejecución y de los componentes que residen en ellos, gráficamente, un diagrama de despliegue es una colección de nodos y arcos. Lección 31. Sistemas y modelos UML proporciona una representación gráfica de los sistemas y los subsistemas, esta notación permite visualizar la descompensación de un sistema en subsistemas más pequeños, gráficamente, un sistema y un subsistema se representa con el símbolo de un paquete estereotipado. Observemos su representación a continuación. 72

73 Figura 69: Sistemas y Modelos Un sistema posiblemente descompuesto en una colección de subsistemas, es un conjunto de elementos organizados para lograr un propósito y descrito por un conjunto de modelos. Un subsistema es una agrupación de elementos, algunos de los cuales constituyen una especificación del comportamiento ofrecido por otros elementos. 73

74 TERCERA UNIDAD PRINCIPIOS DE UML ORIENTADO A OBJETOS 74

75 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 programación, pero con eso no basta. Si se quiere que el sistema sea robusto y sustentable, es necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción 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 notación 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 estándar de facto en cuanto a notación 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 documentación, pues es de esperar que cualquier desarrollador versado en orientación 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 visión completa y coherente de la producción 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 específicos. 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 motivación principal que debería estar en cualquier proceso de construcción de software: el resolver una necesidad del usuario/cliente. Lección 32. Visión 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 tamaño medio-alto. El proceso está formado por una serie de actividades y subactividades, cuya realización se va repitiendo en el tiempo, aplicadas a distintos elementos. 75

76 En este apartado se va a presentar una visión general para poder tener una idea del proceso a alto nivel, y más adelante se verán los pasos que componen cada fase. Fase de Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. Fase de Construcción del Modelo: La construcción del sistema, las fases dentro de esta etapa son las siguientes: Diseño 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. Diseño de Bajo Nivel: El sistema se especifica en detalle, describiendo cómo va a funcionar internamente para satisfacer lo especificado en el Diseño de Alto Nivel. Implementación: se lleva lo especificado en el Diseño de Bajo Nivel a un lenguaje de programación. 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 Planificación y Especificación de Requisitos. Instalación: 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 iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo a través del diseño de alto y al de bajo nivel, para llegar a la implementación y pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximación 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. Lección 33. Fase de Planificación y Especificación de Requisitos Esta fase se corresponde con la Especificación de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definición de Casos de Uso de alto nivel. En esta fase se decidiría si se aborda la construcción del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente. 76

77 Actividades ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigación Preliminar. Definir los Requisitos. Registrar Términos 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 también en las actividades de las fases de diseño, que se verán más adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificación de proyectos software, como las correspondientes a creación de planes e informes preliminares. Requisitos El formato del documento de Especificación de Requisitos no está definido en UML, pero se ha incluido este punto para resaltar que la actividad de definición de requisitos es un paso clave en la creación de cualquier producto software. Para entender y describir los requisitos la técnica 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. Nótese que UML no define un formato para describir un caso de uso. Tan sólo define la manera de representar la relación 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 sección se define el formato textual para la descripción de un caso de uso que se va a utilizar en este documento. 77

78 Un escenario es un camino concreto a través del caso de uso, una secuencia específica de acciones e interacciones entre los actores y el sistema. Más adelante se verá la representación 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 abstracción alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con más 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 automático: Caso de Uso: Realizar Reintegro Actores: Cliente Tipo: Primario Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripción 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 más importantes y que se considere que son los que más influencian al resto, se describen a un nivel más detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de Curso Típico de Eventos, pero también incluye otros apartados como se ve en el siguiente ejemplo: Caso de Uso: Realizar Reintegro Actores: Cliente (iniciador) Propósito: Realizar una operación de reintegro de una cuenta del banco Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. 78

79 Tipo: Primario y esencial Curso Típico de Eventos: Acción 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 identificación. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la petición 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: Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación. Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación. Identificación de Casos de Uso La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisión de los documentos de requisitos existentes, y en el uso de la técnica de brainstorming entre los miembros del equipo de desarrollo. Como guía para la identificación inicial de casos de uso hay dos métodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organización. 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 ortografía de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet 79

80 Identificación de los Límites del Sistema En la descripción 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 precisión. Al definir los límites del sistema se establece una diferenciación 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 informático. Un departamento de una organización. Una organización entera. Si no se está haciendo reingeniería del proceso de negocio lo más 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. Según su Importancia Para establecer una primera aproximación a la priorización 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 más comunes, como Realizar Reintegro en el caso del cajero automático. Secundarios: R ep r e se n ta n casos de uso menores, que van a necesitarse raramente, tales como Añadir Nueva Operación. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. B. Según el Grado de Compromiso con el Diseño En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solución, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnología y de la implementación. 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 abstracción. Por el contrario, un caso de uso real describe concretamente el proceso en términos del diseño real, de la solución específica que se va a llevar a cabo. Se ajusta a un tipo de interfaz específica, y se baja a detalles como pantallas y objetos en las mismas. 80

81 Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automático tenemos la siguiente descripción del curso típico. Eventos: Acción 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 través del teclado numérico. 4. Presenta las opciones de operaciones disponibles. 5. etc. En principio, los casos de uso reales deberían ser creados en la fase de Diseño de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definición 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 diseño 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 diseño es continuo, y una descripción específica de un caso de uso estará situada en algún punto de la línea entre Casos de Uso Esenciales y Reales, normalmente más 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 debería ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artículos o Realizar Pedido. Alternativas equiprobables: Cuando 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 Típico de Eventos con secciones adicionales. Lección 34. Construcción de los diagramas de casos de Uso Para construir el Modelo de Casos de Uso en la fase de Planificación y especificación de Requisitos se siguen los siguientes pasos: 1. Después de listar las funciones del sistema, se definen los límites 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

82 5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definición 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 sólo cuando: Descripciones más detalladas ayudan significativamente a incrementar la comprensión del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar según prioridad los casos de uso (este paso se va a ver a continuación). Lección 35. Planificación de Casos de Uso según Ciclos de Desarrollo La decisión de qué partes del sistema abordar en cada ciclo de desarrollo se va a tomar basándose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementación de uno o más casos de uso, o versiones simplificadas de casos de uso. Se asigna una versión simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo. Figura 70: Planificación de casos de uso según ciclos de desarrollo Para tomar la decisión de qué casos de uso se van a tratar primero es necesario ordenarlos según prioridad. Las características de un caso de uso específico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes: 82

83 Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo. Implica bien un trabajo de investigación significante, o bien el uso de una tecnología nueva o arriesgada. Representa un proceso de gran importancia en la línea de negocio. Supone directamente un aumento de beneficios o una disminución de costos. Para realizar la clasificación se puede asignar a cada caso de uso una valoración numérica de cada uno de estos puntos, para conseguir una puntuación total aplicando pesos a cada apartado. Caso de Uso de Inicialización Prácticamente todos los sistemas van a tener un caso de uso de Inicialización. Aunque puede ser que no tenga una prioridad alta en la clasificación realizada según el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla una versión simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las necesidades de inicialización de los casos de uso que se tratan en dicho ciclo. Así se tiene un sistema en cada ciclo de desarrollo que puede funcionar. Lección 36. Fase de Construcción del Modelo Diseño de Alto Nivel En la fase de Diseño 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 comprensión del problema por parte del equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles de implementación. Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseño de Alto Nivel hay una serie de actividades de planificación. Estas actividades consisten en actualizar los modelos que se tengan según lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseñado 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 Diseño de Alto Nivel. 83

84 En esta fase se trabaja con los modelos de Diseño de Alto Nivel construidos en la fase anterior, ampliándolos 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 Diseño de Alto Nivel son las siguientes: 1. Definir Casos de Uso Esenciales en formato expandido. (si no están 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 Operación. 7. Definir Diagramas de Estados. (opcional) Modelo Conceptual Una parte de la investigación 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 Estática de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software. El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión 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 algún concepto importante. Identificación de Conceptos Para identificar conceptos hay que basarse en el documento de especificación 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, más concretamente, en la descripción de los casos de uso. No es un método infalible, pero puede servir de guía para empezar. Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo, 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 características irrelevantes: al igual que el cartógrafo elimina 84

85 características no relevantes según la finalidad del mapa (por ejemplo datos de población en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos. No añadir cosas que no están ahí: si algo no pertenece al dominio del problema no se añade al modelo. Creación del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos y la búsqueda de sustantivos relacionados con los requisitos en consideración en este ciclo. Representarlos en un diagrama. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. Añadir los atributos necesarios para contener toda la información que se necesite conocer de cada concepto. Identificación de Asociaciones Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de interés 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 relación necesita mantenerse por un cierto período de tiempo (asociaciones necesita-conocer ). Asociaciones derivadas de la Lista de Asociaciones Identificación de Atributos Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones, incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto en las siguientes ocasiones cuando: Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una persona, etc. 85

86 Tiene operaciones asociadas, tales como validación. Ejemplo: número único de identificación. 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, dólares 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 según se le añaden conceptos que se habían pasado por alto. Glosario En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigüedad. Se ordena alfabéticamente por término. CAPITULO 8. DIAGRAMAS DE SECUENCIA DEL SISTEMA Además de investigar sobre los conceptos del sistema y su estructura, también es preciso investigar el diseño de alto nivel sobre el comportamiento del sistema, visto éste como una caja negra. Una parte de la descripción del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema. En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avión, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operación en el sistema de reservas. Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecución 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 notación para diagramas de secuencia de UML estudiadas en la unidad 2 de este módulo. 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 típico de eventos, y además se realiza un diagrama para los cursos alternativos de mayor interés. En la siguiente figura se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar Reintegro de un cajero automático. 86

87 Figura 71: Diagrama de secuencia del sistema para el caso de uso Lección 37. Construcción de un Diagrama de Secuencia del Sistema Para construir un Diagrama de Secuencia del Sistema para el curso típico de eventos de un caso de uso, se siguen los siguientes pasos: 1. Representar el sistema como un objeto con una línea debajo. 2. Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada uno de ellos. 3. Partiendo del texto del curso típico 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 deberían expresarse en base a la noción de operación que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere finalizaroperación a presionadateclaenter, porque captura la finalidad de la operación sin realizar compromisos en cuanto a la interfaz usada. 87

88 Diagramas de Estados Para modelar el comportamiento del sistema pueden usarse los Diagramas de estados definidos en la unidad 2 de este módulo 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 Diseño de Alto Nivel sólo se haría para los dos últimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseño. Puesto que el sistema entero puede ser representado por un concepto, también 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 automático si se está en el transcurso de una operación. Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sería una combinación de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es opcional. Diseño de Bajo Nivel En la fase de Diseño de Bajo Nivel se crea una solución a nivel lógico para satisfacer los requisitos, basándose en el conocimiento reunido en la fase de Diseño de Alto Nivel. Los modelos más importantes en esta fase son el Diagrama de Clases de Diseño y los Diagramas de Interacción, 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 cómo colaboran entre sí para realizar las funciones que se piden al sistema, según éstas se definieron en los contratos de operaciones del sistema. Actividades Las actividades que se realizan en la etapa de Diseño de Bajo Nivel son las siguientes: 1. Definir los Casos de Uso Reales. 88

89 2. Definir Informes e Interfaz de Usuario. 3. Refinar la Arquitectura del Sistema. 4. Definir los Diagramas de Interacción. 5. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de Interacción). 6. Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura del Sistema no tiene por qué realizarse en la posición 3, puede realizarse antes o después. Casos de Uso Reales Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de entrada y de salida y su implementación. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluirá bocetos de las ventanas y detalles de la interacción a bajo nivel con los widgets (botón, lista seleccionable, campo editable, etc.) de la ventana. Como alternativa a la creación de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementación. Diagramas de Interacción Los Diagramas de Interacción 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 Interacción: 1. Diagramas de Colaboración. 2. Diagramas de Secuencia. La notación en UML para ambos es la definida unidad 2 de este módulo, los Diagramas de Colaboración tienen una mayor expresividad y mayor economía espacial (una interacción compleja puede ser muy larga en un Diagrama de Secuencia), sin embargo en ellos la secuencia de interacción entre objetos es más difícil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma información, por lo que se puede usar cualquiera de los dos para expresar la interacción entre los objetos del sistema. La creación de los Diagramas de Interacción de un sistema es una de las actividades más importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creación de estos diagramas, por tanto, debería ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero. 89

90 Lección 38. Creación de los Diagramas de Interacción Para crear los Diagramas de Colaboración o de Secuencia se pueden seguir los siguientes consejos: Crear un diagrama separado para cada operación 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 operación, y la descripción del caso de uso como punto de partida, diseñar un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. Si el diagrama se complica, dividirlo en dos diagramas más pequeños. 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 interacción se detalla en el segundo. El comportamiento dinámico del sistema que se describe en un Diagrama de Interacción debe ser acorde con la estructura estática del sistema que se refleja en el Diagrama de Clases de Diseño. Es aconsejable realizar un Diagrama de Clases de Diseño borrador antes de comenzar con los Diagramas de Interacción. La capacidad de realizar una buena asignación de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo según aumenta la experiencia en el desarrollo orientado a objetos. Responsabilidad es como un contrato u obligación de una clase o tipo. Las responsabilidades están ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Básicamente, 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 acción 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 Transacción 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 método, pero los métodos se implementan para satisfacer responsabilidades. 90

91 Lección 39. Diagrama de Clases de Diseño Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación. Incluye la siguiente información: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Métodos. Navegabilidad. Dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de entidades software más que conceptos del mundo real. En la siguiente figura se muestra un ejemplo de Diagrama de Clases de Diseño sencillo. Figura 72: Diagrama de Clases de Diseño Sencillo Relaciones de Dependencia Para Representar Visibilidad Entre Clases Cuando una clase conoce a otra por un medio que no es a través de un atributo (una asociación con la navegabilidad adecuada), entonces es preciso indicar esta situación por medio de una dependencia. 91

92 Un objeto debe conocer a otro para poder llamar a uno de sus métodos, se dice entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad más directa es por medio de atributo, cuando hay una asociación 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: Parámetro: Cuando a un método de una clase se le pasa como parámetro un objeto de otra clase, se dice que la primera tiene visibilidad de parámetro sobre la segunda. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. Local: Cuando en un método 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 relación 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 método de una clase B llama a un método de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. No es necesario representar la relación de dependencia entre clases que ya están relacionadas por medio de una asociación, que se trata de una dependencia más fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qué elementos hay que revisar cuando se realiza un cambio en el diseño 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 sólo van a tener una instancia. Suele tratarse de clases que se han creado en el Diseño de Bajo Nivel, que no aparecían en el Modelo Conceptual. Varias clases de nuestro sistema pueden querer llamar a los métodos 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 solución elegante para este caso se implementa mediante un método de clase para obtener esa única instancia (los métodos 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 sólo 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 también <> en vez de <<>>. 92

93 A continuación se muestra un ejemplo del código en Java de una clase solitario: public class Solitario { // se define la instancia como atributo de clase (static) Solitario static instancia:= null; // método 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 métodos de la clase } Cuando otra clase quiere llamar a un método de la instancia incluye el siguiente código: Variable Solitario; Variable = Solitario.dar_instancia(); Variable. Método (); // llamada al método que necesitamos Lección 40. Construcción Diagramas de Diseño Normalmente se tiene una idea de un Diagrama de Clases, con una asignación 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 solución software. Esto se lleva a cabo analizando los Diagramas de Interacción. Representarlas en un diagrama de clases. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. Añadir los métodos, según aparecen en los Diagramas de Interacción. Añadir información de tipo a los atributos y métodos. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando según se vayan completando los Diagramas de Interacción correspondientes. No existe precedencia entre la realización del Diagrama de Clases de Diseño y los Diagramas de Interacción. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero más en el de clases y otras veces se trabaja primero más en los de interacción. 93

94 No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el Diagrama de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño del sistema. No hay, por tanto, una transición directa entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensión de un dominio, y el segundo en una solución software. En el Diagrama de Clases de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán en el lenguaje de implementación escogido. Navegabilidad La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible navegar unidireccionalmente a través de la asociación, 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 implementación 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 función, deben ser necesarias, si no es así deben eliminarse. Las situaciones más comunes en las que parece que se necesita definir una asociación con navegabilidad de A a B son: A envía un mensaje a B. A crea una instancia B. A necesita mantener una conexión con B. Visibilidad de Atributos y Métodos Los atributos y los métodos deben tener una visibilidad asignada, que puede ser: + Visibilidad pública. # Visibilidad protegida. - Visibilidad privada. También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementación que sean necesarios para completar el Diagrama de Clases. Otros Aspectos en el Diseño del Sistema 94

95 En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de granularidad fina, con las clases y objetos como unidades de decisión. En el diseño de un sistema es necesario también tomar decisiones a un nivel más alto sobre la descomposición de un sistema en subsistemas y sobre la arquitectura del sistema (definición de sistemas y subsistemas unidad 2). Esta parte del Diseño de Bajo Nivel es lo que se denomina Diseño 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 cómo se realiza esta actividad. Lección 41. Implementación y Pruebas Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el lenguaje de programación 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 producción si se ha planificado una instalación gradual. Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo. Capítulo 9. PILARES DE LA ORIENTACIÓN A OBJETOS Lección 42. Abstracción 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 información aun si estos problemas pertenecen a un área en común. Y se debe tener claro que en cada fase se podrían aplicar más o menos tributos que en las fases anteriores. Ignorancia selectiva La abstracción nos ayuda a trabajos con temas complejos. Se enfoca en lo más importante y por ende ignora lo que no lo es. Una clase en una abstracción en la que: Se enfatiza las características más relevantes, por tal razón se suprimen las demás características. Una abstracción clave solo debe de ser capturada por una y solo unas clase. 95

96 Lección 43. Herencia Partimos diciendo que es la cualidad más importante de la OOP y que el concepto de objeto es la instancia de una clase que tiene todas las características de la clase de donde provienen, a estas características 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. También podríamos definir como superclase la mayor y las subclases aquellas que están dentro de la clase mayor. Recordemos que una clase se simboliza con un rectángulo y el nombre inicia con mayúscula. Igualmente, el nombre de la clase está compuesto por más 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 gráfica. Figura 73: Clase con Nombre de Ruta Tipos de herencia Herencia simple o Una clase posee una sola superclase directa. El gráfico de herencia es un árbol Herencia múltiple o Una clase posee varias superclases directas. El gráfico de herencia no es un árbol Mecanismos de herencia Enriquecimiento: Se añaden variables y/o métodos Substitución: Un método heredado recibe una nueva definición (la antigua no es adecuada al nuevo conjunto de objetos descritos por la superclase Visibilidad: Pública (public) Privada (private) Protegida (protected) 96

97 Figura 74: Herencia Lección 44. Polimorfismo En algunas oportunidades se puede dar la coincidencia de que una acción presenta el mismo nombre en diferentes clases o en la misma, pero realizará una función diferente. Se da la posibilidad de que dos métodos implementen distintas acciones, identificándose con el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe, hay que tener la salvedad de que esta se da siempre y cuando el tipo de parámetro que recibe o el número sean diferentes. Podemos identificar la sobrecarga como tipo especial del polimorfismo y la invocación como el resultado al momento de la ejecución. 97

98 Figura 75: Polimorfismo Lección 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 cómo funciona ni las partes que lo componen sino que cumple o satisface la necesidad del usuario, como jugar, escuchar música 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 más eficientes a los cambios. 98

99 Lección 46. Relaciones Cuando diferentes objetos trabajan en función a una meta o propósito y se logra por medio de la colaboración entre las partes a través de las relaciones. En pocas palabras se define como la conexión entre elementos. Para diferenciar las distintas relaciones se utilizan una Simbología con base en varios tipos de líneas. Figura 78: Tipos de Líneas que Simbolizan las Relaciones De los diferentes tipos de relaciones a las que más se les da importancias son: las dependencias, las generalizaciones y asociaciones. También existe la relación de realización. Dependencias Es una relación 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 especificación de un elemento puede afectar a otro que la utiliza, pero no necesariamente a la inversa. Las clases o paquetes utilizan en su mayoría en su contexto, para indicar que una clase utiliza a otra como argumento en la asignatura de una operación. 99

100 Figura 79: Argumento de Asignatura Generacionales Esta hace referencia a la relación de una súper clase o clase padre con una subclase o clase hija. La generalización 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 características: El hijo hereda atributos y operaciones del padre. El hijo puede agregar atributos y operaciones. Puede tener operaciones polimórficas La generalización se llama a veces relación es-un-tipo-de : un elemento (clase Animal mamífero) es-un-tipo-de un elemento más general (clase Animal). Figura 80: Generacionales 100

101 Asociaciones Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Permitiendo a una asociación entre dos clases se puede pasar de un objeto de una clase hasta un objeto de otra clase. Podemos encontrar una característica especial entre las asociaciones dependencias ya que estas pueden ser reflexivas. y las Figura 81: Asociaciones La agregación es un tipo especial de asociación, que representa una relación estructural entre todo y sus partes. Donde representa Una relación del tipo Tienen-un ejemplo, Un AnimalAves Tienen Plumas. Realización Es una relación semántica entre clasificadores donde este especifica unas normas o un reglamento con otro clasificador que garantiza que se cumplirá. Se encuentran relaciones de realización: 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 generalización y la asociación notamos que la realización es diferente a las otras relaciones mencionadas y así poderla trabajar como un tipo aparte de relación. Pero semánticamente la realización es una mezcla entre dependencia y generalización. 101

102 Figura 82: Realización 102