UNIVERSIDAD DE COLIMA

Transcripción

1 UNIVERSIDAD DE COLIMA MODELO DE DISEÑO EN UML E IMPLANTACIÓN DEL SISTEMA DE GESTIÓN DE DETALLADO TELEFÓNICO PARA LAS DEPENDENCIAS DE LA UNIVERSIDAD DE COLIMA Tesis que para obtener el grado de Maestro en Ciencias área computación Presenta Aníbal Sayid Valdivia Cerda Asesor MC. Víctor Hugo Castillo Topete Coquimatlán, Colima., agosto de 2003

2 EXPEDIENTE: 607 No. CTA.: C. VALDIVIA CERDA ANIBAL SAYID DOMICILIO: ANDADOR 7 NO. 13 LOCALIDAD: COLIMA, COL Informo a Usted, que ha sido aprobado como tema de titulación para obtener el grado de MAESTRO EN CIENCIAS AFEA: COMPUTACIÓN. El solicitado por Usted bajo el título: "MODELO DE DISEÑO EN UML E IMPLANTACIÓN DEL SISTEMA DE GESTIÓN DE DETALLADO TELEFÓNICO PARA LA DEPENDENCIAS DE LA UNIVERSIDAD DE COLIMA" Desarrollado bajo los siguientes puntos: CAPITULO I CAPITULO II CAPITULO III CAPITULO IV CAPITULO V CAPITULO VI EL LENGUAJE UNIFICADO DE MODELADO (UML) COMO HERRAMIENTA DE MODELADO VISUAL EL MODELO DE DOMINIO EL MODELO DE CASOS DE USO DEFINICIÓN DE LA LÍNEA BASE DE LA ARQUITECTURA EL MODELO DE DISEÑO EL MODELO DE IMPLEMENTACIÓN CONCLUSIONES BIBLIOGRAFÍA Al mismo tiempo informo a usted que ha sido designado como asesor de titulación al suscrito M.C. VICTOR HUGO CASTILLO TOPETE. Km 9 Carretera Colima-Coquimatlán, Colima, Colima, México, C.P Tel. 01 (312) , Ext , Ext. Fax 51454

3 Exp. No.: 607 Fecha: 17 de septiembre 2003 Acta No.: C. VALDIVIA CERDA ANIBAL SAYID Domicilio: ANDADOR 7 NO. 13 Localidad: COLIMA, COL Teléfono: En cumplimiento al artículo: 13 y 14 del reglamento de titulación, al artículo 40, Inciso A del reglamento de estudios de Posgrado vigente y al artículo: 46 de las normas complementarias al reglamento de Posgrado, correspondientes al Posgrado de la Facultad de Ingeniería Mecánica y Eléctrica. Informamos a usted que ha sido autorizado por este Consejo Técnico del Posgrado su tema de Tesis para obtener el grado de Maestro en Ciencias Arca: Computación titulado: "MODELO DE DISEÑO EN UML E IMPLANTACIÓN DEL SISTEMA DE GESTIÓN DE DESTALLADO TELEFÓNICO PARA LA DEPENDENCIAS DE LA UNIVERSIDAD DE COLIMA" para ser desarrollado bajo los siguientes puntos: CAPITULO 1 CAPITULO II CAPITULO III CAPITULO IV CAPITULO V CAPITULO VI EL LENGUAJE UNIFICADO DE MODELADO (UML) COMO HERRAMIENTA DE MODELADO VISUAL EL MODELADO DE DOMINIO EL MODELO DE CASOS DE USO DEFINICIÓN DE LA LÍNEA BASE DE LA ARQUITECTURA EL MODELO DE DISEÑO EL MODELO DE IMPLEMENTACIÓN CONCLUSIONES BIBLIOGRAFÍA Así mismo hacemos de su conocimiento que de acuerdo con la línea de investigación en la cual se enmarca su proyecto ha sido autorizado como asesor de tesis al C. M.C. VICTOR HUGO CASTILLO TOPETE A partir de la fecha de aprobación tendrá como plazo un año para presentar su examen de grado, en caso contrario tendrá usted derecho a una prórroga única de seis meses so pena de perder el registro de su proyecto. Una vez concluidos los trámites de revisión de su documento de tesis e integrado su expediente de titulación deberá recoger el oficio que acompañará el visto bueno de su asesor de tesis, los cuales encabezarán cada uno de los ejemplares de su tesis.

4 H. CONSEJO ACADÉMICO DEL POSGRADO, FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA, UNIVERSIDAD DE COLIMA P R E S E N T E Por este medio notifico que el C. Aníbal Sayid Valdivia Cerda, alumno de la Maestría en Ciencias, Área Computación de esta Facultad, ha concluido el 100% de su trabajo de tesis titulado "Modelo de diseño en UML e implantación del Sistema de Gestión de Detallado Telefónico para las Dependencias de la Universidad de Colima", mismo que he asesorado desde el mes de febrero del presente año. Sin otro particular, extiendo cordial saludo.

5 DEDICATORIA Quiero dedicar esta tesis A dios, por los tropiezos que me han hecho aprender y por la alegría de seguir aprendiendo. A mi esposa y amiga, Laura, quien me acompaña en momentos difíciles y gratos, que me hacen disfrutar lo que tengo. A mi hija, Laura Merarí, porque cuando estoy cansado o busco un aliciente, ahí está su sonrisa y cariño para confortarme. A mis papás, por darme la vida, también mi padre por ser una persona de la que aprendí y me hizo ver que luchar es lo mejor que podemos hacer y mi mamá, por darme la vida y que supo dar lo mejor de sí para sus hijos, permaneciendo de pie en momentos invaluables. A mis hermanos, porque sabemos que aunque los tiempos, las personas y las cosas cambian, no ignoramos que existen puntos de equilibrio entre nosotros como los son el cariño y el respeto.

6 AGRADECIMIENTOS A todas las personas que aún sin conocerlas mucho han influido en mis decisiones acertadas. A mi asesor de tesis, que me apoyó en este proyecto. Al personal administrativo de la F.I.M.E.

7 Índice Capítulo 1 El lenguaje Unificado de Modelado (UML) como herramienta de modelado visual Reseña Histórica Principios de modelado orientado a objetos Vocabulario de UML Diagramas en UML Capítulo 2 El modelo de dominio Diagramas de clases Diagramas de actividades 31 Capítulo 3 El modelo de casos de uso Diagramas de casos de uso.. 35 Capítulo 4 Definición de la línea base de la arquitectura Diagrama de bloques representativo de acceso al sistema Diagramas de despliegue. 42 Capítulo 5 El modelo de diseño Diagramas de clases activas. 45 Capítulo 6 El modelo de implementación Pantallas de presentación y código fuente del sistema Diagramas de componentes 112 Conclusiones..113 Bibliografía.116 I

8 TABLA DE CUADROS Y FIGURAS Figura Título Página 1 Diagrama de clase ejemplo 7 2 Representación de una interfaz 7 3 Representación de una colaboración 7 4 Representación de un caso de uso 8 5 Representación de una clase activa 8 6 Representación de un componente 8 7 Representación dé un nodo 8 8 Envío de mensajes 9 9 Representación de una máquina de estados 9 10 Ejemplo de un paquete de agrupación 9 11 Un elemento de anotación Representación de relación de dependencia Ejemplo de asociación Representación de la generalización Representación de una realización Ejemplo de un diagrama de clase Ejemplo de diagramas de objetos Ejemplo de diagrama de caso de uso Ejemplo de diagramas de secuencias Ejemplo de diagramas de colaboración Representación de un estado División del icono de estado en 3 partes Ejemplo de diagrama de estado Ejemplo de diagramas de actividades Ejemplo de diagramas de componentes Ejemplo de diagramas de despliegue Diagrama de clase para acceder a cuenta de usuario Diagrama de clase para cobro del mes deseado Diagrama de clase para detalles de llamada Diagrama de clase para cambiar password Diagrama de actividades para acceder al sistema Diagrama de actividades para mostrar cobros y detallados telefónicos Diagrama de actividades para cambiar password Diagrama Caso de Usos General del Sistema Diagrama Caso de Uso Cambiar password usuario Diagrama Caso de Uso Consultar ultimo cobro Diagrama Caso de Uso Consultar penúltimo cobro Diagrama Caso de Uso Consultar antepenúltimo cobro Diagrama de bloques representativo de acceso al sistema Diagrama de despliegue para ingresar al sistema y mostrar cobros Diagrama de despliegue para mostrar detallado telefónico Diagrama de despliegue para cambiar password 44 II

9 43 Diagrama de clase para acceder a cuenta de usuario Diagrama de clase para cobro del mes deseado Diagrama de clase para detalles de llamada Diagrama de clase para cambiar password Diagrama de componentes del sistema 112 III

10 RESUMEN El lenguaje UML es usado en la actualidad para modelar sistemas orientados a objetos, el desarrollo de diagramas proporciona diferentes vistas que muestran desde el comportamiento del sistema con el equipo periférico hasta el comportamiento con los usuarios en tiempo de interacción. El proyecto de tesis "Modelo de Diseño en UML e implantación del sistema de gestión de detallado telefónico para las dependencias de la Universidad de Colima", explica las bases de UML en el desarrollo de sistemas y a la vez ejemplifica su uso en un sistema cliente - servidor con información de llamadas y costos telefónicos de las dependencias de la Universidad de Colima que será implantado para consultas de cobros por internet. Los diagramas que se utilizan son: Diagramas de clases, de actividades, de casos de uso, de despliegue, de clases activas y de componentes. La implementación del sistema está basado en el lenguaje ASP (Páginas de servidor activas), y accede a bases de datos en Access 2002, los usuarios podrán ingresar a la información correspondiente con una cuenta y clave válidas, desde cualquier explorador de internet. IV

11 ABSTRACT Nowadays, UML is used to model OO systems, the development of diagrams provides different views that show everything from the behavior of the system with the peripheral equipment to the behavior with the users, during interaction. The thesis project "Design in UML and implement of the management system of phone calls for the subsidiaries of the University of Colima", explains the basis of UML in the development of systems and simultaneously it exemplifies its use in a client-server system with information of calls and telephone costs of the subsidiaries of the University of Colima, it will be implemented for consult of telephone costs by Internet. The diagrams used are: classes, activities, use cases, deployment, active classes and component diagrams. The implementation of the system is based on ASP language(active Server Pages), and reaches data bases in Access 2002, the users will be able to access to the corresponding information with a valid login and password from any Web explorer. V

12 INTRODUCCIÓN A medida que los sistemas computacionales avanzan, sus mecanismos se transforman en una gama diversa de posibilidades, así como con mayor medida, el acercamiento a la satisfacción de las necesidades planteadas a partir de una situación real. Este cambio, origina el surgimiento de herramientas que evolucionan constantemente y sirven como base para mejorar las estrategias en la búsqueda de soluciones; tal es el caso, de los sistemas desarrollados con lenguajes orientados a objetos, quienes día a día se enfrentan a situaciones más complejas y quienes se empezaron a sobrellevar con enfoques alternativos al análisis y al diseño. El modelado es una parte importante en lo referente a cualquier actividad que conduce a la producción de buen software (Sistema). Construimos modelos para plasmar la estructura deseada y, posteriormente, nuestro sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema. Construimos modelos para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo oportunidades para la simplificación y la reutilización. Construimos modelos para controlar el riesgo. Así, como cuando un arquitecto, antes de construir una casa, requiere una planificación bien detallada, bocetos del aspecto que se quiere que tenga la casa, dibujar planos de forma que se pueda pensar en el uso pretendido de las habitaciones y los detalles prácticos de la electricidad, calefacción y fontanería, estipulando la cantidad de materiales y tiempo que se llevará en la construcción de tal casa, y todo esto, antes de golpear el primer clavo o echar los cimientos. Los modelos pueden involucrar planos detallados, así como planos más generales que ofrecen una visión global del sistema en consideración. Un buen modelo incluye aquellos elementos que tienen una gran influencia y omite aquellos elementos menores que no son relevantes para el nivel de abstracción dado. UML (Unified Modeling Language) es un lenguaje gráfico de propósito general para visualizar, especificar, construir y documentar los artefactos de aplicaciones, que permite la total abstracción de los sistemas utilizando la implementación final. Fue creado para modelar y documentar aplicaciones orientadas a objetos, UML se ha transformado en una herramienta poderosa a la hora de analizar cualquier sistema en el que seamos capaces de identificar los componentes. Según definición de los creadores modelo es "una simplificación de la realidad" que proporciona los planos de un sistema. Así pues, los diagramas UML además de una forma de documentar un proyecto, son sobre todo, una herramienta que nos ayuda en el proceso de abstracción y definición de las funcionalidades del sistema. Por ello, a partir de aclarar el uso de UML y conocer las bases de construcción de diagramas con este lenguaje, se diseñarán con el sustento de esta base los diagramas del sistema de gestión de detallados telefónicos de la Universidad de Colima, para tener una perspectiva completa de la interacción de los distintos procesos de obtención de información de adeudo telefónico mensual de la Universidad, a su vez, se implementarán estos modelos en la creación del sistema bajo el lenguaje ASP(Active Server Pages), creado para ejecutar aplicaciones dinámicas e interactivas de servidor Web, así, permitiendo por medio de una cuenta y una clave de acceso acceder al sistema a través de cualquier explorador de web y ver el consumo de los últimos tres meses de facturación por cada dependencia universitaria, obteniendo también, un beneficio económico para la Universidad de Colima, ya que este tipo de software tiene un costo muy elevado (Sobre de 70,000) en el mercado de software.

13 Capítulo 1. El lenguaje Unificado de Modelado (UML) como herramienta de modelado visual. 1.1 Reseña histórica En algún momento desde la mitad de los setentas y finales de los ochenta, surgieron muchos métodos enfocados al diseño para modelar algunas aplicaciones y sistemas de programación orientados a objetos, el número de métodos orientados a objetos se incrementó de menos de 10 a mis de 50 durante el período entre 1989 y 1994; muchos usuarios de los distintos métodos tenían problemas al intentar encontrar un lenguaje de modelado que cubriera sus necesidades completamente, alimentando de esta forma la llamada guerra de métodos. Con estas experiencias, comenzaron a aparecer nuevas generaciones de métodos, siendo destacados de manera muy clara unos pocos, entre los importantes se cuentan Fusion, Shlaer-Mellor y Coad-Yourdon, y en especial, los siguientes: El método de Booch, el método OOSE (Object - Oriented Software Engineering, Ingeniería del Software Orientada a Objetos) de Jacobson y el método OMT (Object Modeling Technique, Técnica de Modelado de Objetos) de Rumbaugh. Una masa crítica de ideas comenzó a formarse en la primera mitad de los noventa, cuando Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) y James Rumbaugh (General Electric) empezaron a adoptar ideas de cada uno de los otros dos métodos, los cuales habían sido reconocidos en conjunto como los tres principales métodos orientados a objetos a nivel mundial, debido a esto, los creadores de los 3 métodos se sintieron motivados para crear un lenguaje unificado de modelado a partir de sus propios métodos. Es así como surge UML - por sus siglas en inglés Unified Modeling Language -, Lenguaje Unificado de Modelado. UML, trascendió en las versiones 0.8, 0.9, hasta lograr la versión 1.0 gracias al esfuerzo de varias organizaciones que contribuyeron a su definición, tales organizaciones fueron Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. Esta colaboración produjo UML 1.0, un lenguaje de modelado bien definido, expresivo, potente y aplicable a un amplio espectro de dominios de problemas. UML 1.0 se ofreció para su estandarización en enero de 1997, y en respuesta a la solicitud de propuestas de Object Management Group (OMG) para un lenguaje estándar de modelado. Posteriormente, el grupo de trabajo inicial se amplió, incluyendo a más organizaciones tales como Andersen Consulting, Ericsson, ObjectTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software y Taskon, además, se incluyó un grupo de trabajo para la semántica, liderado por Cris Kobryn de MCI Systemhouse y coordinado por Ed Eykholt de Rational, para formalizar la especificación de UML y para integrar UML con otros esfuerzos de estandarización. Así, una versión revisada de UML (Versión 1.1) se ofreció al OMG para su estandarización en julio de 1997, y en septiembre de ese año, esta versión fue aceptada por la OMG Análisis and Design Task Force (ADTK) y el OMG Architecture Board y se sometió al voto de todos los miembros del OMG. UML 1.1 fue adoptado por el OMG el 14 de noviembre de 1997 convirtiéndolo en una notación estandarizada para el análisis y diseño orientado a objetos. 1

14 El control de mantenimiento de UML fue asumido pro la OMG Revisión Task Force, dirigida por Cris Kobryn. La Revisión Task Force (RTF) publicó una versión editorial, UML 1.2 en junio de 1998 en otoño de 1998, la RTF publicó UML

15 1.2 Principios de modelado orientado a objetos El uso del modelado sugiere 4 principios básicos de modelado: Primero, que modelo se va a utilizar, ya que este tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución; así que, es importante elegir el modelo de software adecuado. Un modelo adecuado puede arrojar mucha luz sobre los problemas de desarrollo más horribles, ofreciendo una comprensión que simplemente no podríamos obtener de otra manera; los modelos erróneos desorientarán, haciendo que uno se centre en cuestiones irrelevantes. En el software, los modelos elegidos pueden afectar mucho a nuestra visión del mundo. Si construimos un sistema con la mirada de un desarrollador de bases de datos, probablemente nos centraremos en los modelos entidad-relación que trasladan el comportamiento a disparadores (triggers) y procedimientos almacenados. Si construimos un sistema con la mirada de un analista estructurado, probablemente se obtendrán modelos centrados en los algoritmos, con los datos fluyendo de proceso en proceso. Si construimos un sistema con la mirada de un desarrollador orientado a objetos, se obtendrá un sistema cuya arquitectura se centra en un mar de clases y patrones de interacción que gobiernan cómo trabajan juntas estas clases. Cualquiera de estos enfoques podría estar bien para una aplicación y una cultura de desarrollo dadas, aunque la experiencia sugiere que la visión orientada a objetos es superior al proporcionar arquitecturas flexibles, incluso para sistemas que podrían tener una gran base de datos o una gran componente computacional. No obstante, la cuestión es que cada visión del mundo conduce a un tipo de sistema diferente, con diferentes costes y beneficios. Así también, el segundo principio básico de modelado establece que, todo modelo puede ser expresado a diferentes niveles de precisión, como en la construcción de un rascacielos, a veces es conveniente dar una vista general para que los inversionistas se den cuenta de la magnitud de la construcción e imaginen su aspecto externo, pero en otras ocasiones, es conveniente descender a niveles más bajos, como cuando hay un recorrido de tuberías enmarañado o un elemento estructural poco usual. En los modelos de software, a veces, un pequeño y sencillo modelo ejecutable de la interfaz del usuario es exactamente lo que se necesita; otras veces, hay que bajar y enredarse con los bits, como cuando se están especificando interfaces entre sistemas o luchando con cuellos de botella en redes. En cualquier caso, los mejores tipos de modelos son aquellos que permiten elegir el grado de detalle, dependiendo de quién está viendo el sistema y porqué necesita verlo. Un analista o un usuario final se centrará en el qué; un desarrollador se centrará en el cómo. Tanto unos como otros querrán visualizar un sistema a diferentes niveles de detalle en momentos diferentes. El tercer principio menciona que, Los mejores modelos están ligados a la realidad, es preferible tener modelos que tengan una clara conexión con la realidad, y donde esta conexión sea débil saber exactamente cómo se apartan esos modelos del mundo real. Todos los modelos simplifican la realidad; el truco está en asegurarse de que las simplificaciones no enmascaran ningún detalle importante. 3

16 En el software, el talón de Aquiles de las técnicas de análisis estructurado es el hecho de que hay una desconexión básica entre el modelo de análisis y el modelo de diseño del sistema. No poder salvar este abismo hace que el sistema concebido y el sistema construido diverjan con el paso del tiempo. En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un sistema en un todo semántico. El cuarto y último principio define que, Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes. La expresión clave aquí es "casi independientes". En este contexto significa tener modelos que podemos construir y estudiar separadamente, pero aún así están interrelacionados. Como en el caso de un edificio, podemos estudiar los planos eléctricos de forma aislada, pero también podemos ver su correspondencia con los planos de planta y quizás incluso su interacción con los recorridos de las tuberías en el plano de la fontanería. Lo mismo es cierto que para los sistemas software orientados a objetos. Para comprender la arquitectura de tales sistemas, se necesitan varias vistas complementarias y entrelazadas: una vista de casos de uso (Que muestre los requisitos del sistema), una vista de diseño (Que capture el vocabulario del espacio problema y del espacio de la solución), una vista de procesos (Que modele la distribución de los procesos e hilos (threads) del sistema), una vista de implementación (Que se ocupe de la realización física del sistema) y una vista de despliegue (Que se centre en cuestiones de ingeniería del sistema). Cada una de estas vistas puede tener aspectos tanto estructurales como de comportamiento. En conjunto, estas vistas representan los planos del software. Según la naturaleza del sistema, algunos modelos pueden ser más importantes que otros. Por ejemplo, en sistemas con grandes cantidades de datos, dominarán los modelos centrados en las vistas de diseño estáticas. En sistemas con uso intensivo de interfaces gráficas de usuario (GUI), las vistas de casos de uso estáticas y dinámicas son bastante importantes. En los sistemas de tiempo real muy exigentes, las vistas de procesos dinámicas tienden a ser más importantes. Finalmente, en los sistemas distribuidos, como los encontrados en aplicaciones de uso intensivo de la Web, los modelos de implementación y despliegue son los más importantes. Los ingenieros civiles construyen muchos tipos de modelos. Lo más frecuente es que usen modelos estructurales que les ayudan a visualizar y especificar partes de los sistemas y la forma en que esas partes se relacionan entre sí. Dependiendo de las cuestiones más importantes del sistema o de la ingeniería que les preocupen, los ingenieros podrían también construir modelos dinámicos. Por ejemplo, para ayudarles a estudiar el comportamiento de una estructura en presencia de un terremoto. Cada tipo de modelo se organiza de forma diferente, y cada uno tiene su propio enfoque. En el software hay varias formas de enfocar un modelo. Las dos formas más comunes son la perspectiva orientada a objetos y la perspectiva algorítmica. La visión tradicional del desarrollo de software toma una perspectiva algorítmica. En este enfoque, el bloque principal de construcción de todo el software es el procedimiento o función. Esta visión conduce a los desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros más pequeños. 4

17 No hay nada inherentemente malo en este punto de vista, salvo que tiende a producir sistemas frágiles. Cuando los requisitos cambian ( Lo harán!) y el sistema crece ( Lo hará!), los sistemas construidos con un enfoque algorítmico se vuelven muy difíciles de mantener. La visión actual del desarrollo de software toma una perspectiva orientada a objetos. En este enfoque, el principal bloque de construcción de todos los sistemas es el objeto o clase. Para explicarlo sencillamente, un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución; una clase es una descripción de un conjunto de objetos similares. Todo objeto tiene identidad (Puede nombrarse o distinguirse de otra manera de otros objetos), estado (Generalmente hay algunos datos asociados a él), y comportamiento (Se le pueden hacer cosas al objeto, y él a su vez puede hacer cosas a otros objetos). Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software, simplemente porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominios de problemas, abarcando todo el abanico de tamaños y complejidades. Más aún, la mayoría de los lenguajes actuales, sistemas operativos y herramientas son orientados a objetos de alguna manera, lo que ofrece más motivos para ver el mundo en términos de objetos. El desarrollo orientado a objetos proporciona la base fundamental para ensamblar sistemas a partir de componentes utilizando tecnologías como Java Beans o COM+. Varias cuestiones se derivan de la elección de ver el mundo de una forma orientada a objetos. Cuál es la estructura de una buena arquitectura orientada a objetos?, Qué artefactos debería crear el proyecto?, Quién debería crearlos?, Cómo deberían medirse?. Visualizar, especificar, construir y documentar sistemas orientados a objetos es exactamente el propósito del Lenguaje Unificado de Modelado (Unified Modeling Language). 5

18 1.3 Vocabulario de UML 6

19 Elementos estructurales.- Dentro de estos, se encuentran: ELEMENTOS Una clase describe un conjunto de objetos con características y comportamientos idénticos, se representa con un rectángulo dividido en 3 secciones: parte superior el nombre, parte medio el atributo y parte inferior las acciones. Puerta Largo Ancho Tipo Abrir Cerrar Poner seguro Figura 1: Diagrama de clase ejemplo La interfaz se representa por medio de una línea terminada en un círculo junto con su nombre y suele estar conectada a la clase o componente que la realiza. Representa un conjunto de operaciones que especifican el comportamiento completo de una clase o sólo una parte de ese comportamiento. Figura 2: Representación de una interfaz La colaboración se representa como una elipse de borde discontinuo unida mediante flechas punteadas a los objetos o clases que participan realmente en un patrón de diseño; es una forma de representar interacción entre objetos, especificando un contrato entre ellos. Las flechas punteadas pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón. Un caso de uso se representa por una elipse de borde continuo incluyendo su nombre, denota un requerimiento solucionado por el sistema. Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema. 7

20 Figura 4: Representación de un caso de uso Una clase activa se representa como una clase pero con líneas más gruesas e incluye su nombre, atributos y acciones. Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución, por lo tanto, dan origen a actividades de control. Comunicación Coartar Generar Figura 5: Representación de una clase activa Un componente se representa como un rectángulo con pestañas; muestra las dependencias lógicas entre componentes software, sean éstos componentes fuentes, binarios o ejecutables. Los componentes software tienen tipo, que indica si son útiles en tiempo de compilación, enlace o ejecución. Un componente representa el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones. Orderform.java Figura 6: Representación de un componente Un nodo que se representa como un cubo 3D; es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos. Se representa como un cubo 3D en los diagramas de implementación. Figura 7: Representación de un nodo 8 8

21 Elementos de comportamiento.- Estos son las partes dinámicas de los modelos UML. Así, una interacción es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos en una aplicación a través del tiempo; como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación; interacción involucra muchos elementos, mensajes, secuencias de acción (El comportamiento invocado por un mensaje) y enlaces (Conexiones entre objetos). Gráficamente, el envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta, incluyendo casi siempre el nombre de su operación, como se muestra en la siguiente figura: servir Figura 8: Envío de mensajes Una máquina de estados, muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro. El comportamiento de una clase individual o una colaboración de clases puede especificarse con una máquina de estados. Una máquina de estados involucra estados, transiciones (El flujo de un estado a otro), eventos (Que disparan una transición) y actividades (La respuesta a una transición). Gráficamente Se representa mediante un rectángulo con los bordes redondeados, incluyendo normalmente su nombre y sus subestados, si los tiene. Mostrando Valor Figura 9: Representación de una máquina de estados Elementos de agrupación.- En algunas ocasiones existirá la necesidad de separar los elementos de un diagrama, como parte de un sistema integral, en grupos, para ello, se utiliza un paquete. Los elementos estructurales, los elementos de comportamiento y otros elementos de agrupación pueden incluirse en un paquete, pero no sucede lo mismo con los componentes (Que existen en tiempo de ejecución), así un paquete es puramente conceptual (Sólo existe en tiempo de desarrollo). Un paquete se representa como una carpeta, que incluye sólo su nombre, y, a veces su contenido. Figura 10: Ejemplo de un paquete de agrupación 9 9

22 Elementos de anotación. Cuando es necesario explicar el porqué de alguna parte del diagrama que no esté muy clara, entonces se utilizan los elementos de anotación o notas, son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. Este elemento de anotación se llama nota y esta, muestra restricciones y comentarios formales o informales junto a un elemento o una colección de elementos. Se representa como un rectángulo con la esquina doblada, junto con un comentario textual o gráfico. Figura 11: Un elemento de anotación Relaciones Dependencia.- Es la relación que existe entre dos elementos, un elemento dependiente y otro independiente, de tal forma que, un cambio (El elemento independiente) puede afectar la semántica del otro elemento (El elemento dependiente). Y se representa de la siguiente manera: > Figura 12: Representación de relación de dependencia Asociaciones.- Cuando existe una conexión conceptual entre objetos, se está hablando de una asociación que se representa con una línea continua que une a estos dos objetos, que a veces incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los nombre de rol. Automóvil Dueño Persona Generalización.- La relación de generalización denota una relación de herencia entre clases. Se representa dibujando una línea continua con una punta de flecha sin rellenar en el lado de la superclase (El padre). La subclase (El hijo) hereda todos los atributos y mensajes descritos en la superclase (El padre). De esta forma, el hijo comparte la estructura y comportamiento del padre. Figura 14: Representación de la generalización 10 10

23 Realización.- La realización es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. Se representa como una mezcla entre una generalización y una relación; una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que apunte a la interfaz Figura 15: Representación de una realización 11 11

24 1.4 Diagramas en UML Diagramas de clases.- Estos tipos de diagramas son de los más utilizados en el modelado de sistemas orientados a objetos. Para completar un diagrama de clase se requiere un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos modelan la vista de diseño estática de un sistema, su vocabulario, su colaboración o su esquema. Las relaciones pueden ser de dependencia, generalización y asociación. Al igual que lo demás diagramas, los diagramas de clases pueden contener paquetes, notas y restricciones. Ejemplificando un diagrama de clases con el conjunto de objetos refrigerador, es de notar que cualquier cosa dentro de la clase refrigerador, consta de atributos tales como marca, modelo, número de serie, altura, ancho, entre las acciones de las cosas de esta clase se encuentra: abrir el refrigerador, meter cosas, sacar cosas, regular temperatura. La siguiente figura muestra un diagrama de clase Refrigerador. Refrigerador Marca modelo número de serie altura ancho Abrir refrigerador Meter cosas Sacar cosas Regular temperatura Figura 16: Ejemplo de un diagrama de clase Diagramas de objetos.- Los diagramas de objetos muestran un conjunto de objetos y sus relaciones en un momento concreto. Cada objeto tiene una entidad discreta con límites bien definidos, mantiene un estado y una relación precisa con los demás, en un momento determinado. En UML, el diagrama de clases se utiliza para visualizar los aspectos estáticos de los bloques de construcción y los mensajes entre ellos en un sistema; un diagrama de objetos contiene un conjunto de instancias de los elementos encontrados en un diagrama de clases, expresando la parte estática de una interacción (Y a través de ella se representa el ciclo de vida de cada objeto), en cuanto a los objetos que colaboran, pero, sin ninguno de los mensajes enviados entre ellos. Cada objeto se representa por un rectángulo con tres compartimentos. En el primero va el nombre del objeto subrayado, en el segundo sus atributos y en el tercero sus operaciones (Aunque sus operaciones pueden ser omitidas según se requiera). 12

25 Diagramas de casos de uso.- Este tipo de diagramas se utilizan para el modelado de aspectos dinámicos de un sistema, muestra las distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Para representar un sistema con sus distintas variaciones y resultados se utiliza un conjunto de casos de uso, actores y sus relaciones.; a su vez, y al igual que otros diagramas pueden contener notas y restricciones, también, pueden ser agrupados por paquetes. Para modelar un sistema con diagramas de casos de uso, se destacan los actores en torno al sistema, así, algo importante es definirlos, y de que forma interactúan para restringir la relación de actores que no se necesitan. Por ello: Hay que identificar los actores en torno al sistema, cuáles requieren realizar solo tareas; cuáles requieren ejecutar funciones; que actores interactúan con el equipo periférico u otros sistemas software; qué actores tienen que ver con cuestiones administrativas y de mantenimiento del sistema. Hay que organizar a los actores similares en jerarquías de generalización/especialización. Hay que proporcionar un estereotipo para cada uno de esos actores, si así se ayuda a entender el sistema. Hay que especificar las vías de comunicación de los actores con los casos de uso del sistema. 13

26 Un actor se representa mediante un, una elipse denota un requerimiento solucionado por el sistema, cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema. Va acompañado de un nombre significativo. Dentro de los bloques de construcción de diagramas en UML ya se vieron los diferentes tipos de relaciones que existen; para el diagrama de casos de uso, se pueden usar las relaciones de dependencia, generalización y asociación. En el siguiente caso de cuenta bancaria, se tienen como casos de uso Realizar depósito, Retirar efectivo, Procesar factura, Gestión de información de cuenta, existen diferentes actores como Cliente individual y Cliente corporativo, Empresa, Entidad financiera. 14

27 Diagramas de secuencia y de colaboración.- Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción, que se utilizan para modelar los aspectos dinámicos de los sistemas. La diferencia de los diagramas de secuencia y de colaboración radica en que los diagramas de secuencia muestran la organización temporal de los mensajes, pero no incluyen las relaciones entre objetos y los diagramas de colaboración muestran explícitamente las relaciones de los roles estructurales de los objetos que envían y reciben mensajes, también, no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes. Los diagramas de interacción son importantes también para construir sistemas ejecutables por medio de ingeniería directa e inversa. El diagrama de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interacción; la progresión vertical es la línea de vida, que representa el rol durante cierto plazo de tiempo con la interacción completa, los rectángulos con nombre (Subrayado), que son los objetos, se ordenan de forma horizontal, los mensajes son representados como líneas continuas con una punta de flecha y se colocan entre líneas de vida. Estos diagramas se forman en primer lugar, colocando los objetos que participan en la interacción en la parte superior del diagrama, a lo largo de eje. Normalmente, se coloca a la izquierda el objeto que inicia la interacción, y los objetos subordinados a la derecha. A continuación, se colocan los mensajes que estos objetos envían y reciben a lo largo del eje Y, en orden de sucesión en el tiempo, desde arriba hasta abajo. La línea de vida de un objeto se pone como una línea discontinua vertical que representa la existencia de un objeto a lo largo de un período de tiempo, así con un rectángulo de encabezado, también pueden ir rectángulos a través de la línea de vida que denotan la ejecución de métodos; el rectángulo de encabezado contiene el nombre del objeto y el de su clase, en un formato nombreobjeto: nombreclase. Las líneas de vida de los objetos comienzan con la recepción del mensaje estereotipado como create. 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). Para los diagramas de colaboración, vale la pena reafirmar a más detalle algunas características que los diferencian de los diagramas de secuencia. Una de ellas es el camino. Para indicar cómo se enlaza un objeto a otro, se puede asociar un estereotipo de camino al extremo más lejano de un enlace (Como <<local>>), que indica que el objeto designado es local al emisor). Normalmente, sólo se necesita representar explícitamente el camino de enlace para los caminos local, parameter, global y self (pero no association). Otra característica es el número de secuencia. Para indicar la ordenación temporal de un mensaje, se precede de un número de un número (comenzando con el mensaje número 1), que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control (2,3, etc.). Por ello, para representar el anidamiento, se utiliza la numeración decimal de Dewey (1 es el primer mensaje; 1.1 es el primer mensaje dentro del mensaje 1; 1.2 es el segundo mensaje dentro del mensaje 1; etc.). El anidamiento se puede representar 15

28 a cualquier nivel de profundidad. Nótese también, a través del mismo enlace, se pueden mostrar varios mensajes (posiblemente enviados desde distintas direcciones), y cada uno tendrá un número de secuencia único. La mayoría de las veces se modelarán flujos de controles simples y secuenciales. Sin embargo, también se pueden modelar flujos más complejos, que impliquen iteración y bifurcación. Una iteración representa una secuencia repetida de mensajes. Para modelar una iteración, el número de secuencia de un mensaje se precede de una expresión de iteración, como en * [i: =1..n] (o sólo * si se quiere indicar iteración pero no se desea especificar los detalles). Una iteración indica que el mensaje (y cualquier mensaje anidado) se repetirá de acuerdo con la expresión dada. Análogamente, una condición representa un mensaje cuya ejecución depende de la evaluación de una expresión booleana. Para modelar una condición, el número de secuencia de un mensaje se precede de una cláusula de condición [x >0]. Los distintos caminos alternativos de una bifurcación tendrán el mismo de secuencia, pero cada camino debe ser distinguible de forma única por una condición que no se solape con las otras. Tanto para la iteración como para la bifurcación, UML no impone el formato de la expresión entre corchetes; se puede utilizar pseudocódigos o la sintaxis de un lenguaje de programación específico. 16

29 Figura 20: Ejemplo de diagramas de colaboración Diagramas de Estados.- Estos diagramas permiten modificar los procedimientos con el tiempo y son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante de tiempo, así mismo, el objeto puede tener un tiempo de vida en la aplicación, y este puede ser representado por varios estados que interactúan entre sí con sus respectivos cambios que permiten pasar de un estado a otro. El estado en que se encuentra un objeto determina su comportamiento, éste muestra la forma en que las partes de un modelo UML cambia con el tiempo, así mismo, cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento. Asimilando la transición de estados por medio de un ejemplo podría definirse así: La fabricación de un automóvil requiere de diferentes etapas o estados de armado del todo y cada una de sus partes, para tal proceso, se adquiere el material con que va a ser hecho, se arman las partes del automóvil de acuerdo a las características definidas en el diseño inicial, se realizan pruebas de resistencia de distintos tipos para evitar defectos que no son fáciles de distinguir, se almacena en una bodega especial y se entrega el coche a la agencia especializada en ventas. Obviamente, este es un ejemplo muy general sobre los distintos estados por los que puede pasar este objeto durante el periodo de vida de la fabricación del mismo, pero también, sirve para reconocer que todo objeto desde una vista de 17

30 comportamiento, puede pasar por cambios necesarios en un tiempo determinado. En algún sistema que interactúe con los usuarios y posiblemente con otros sistemas, los objetos que lo conforman pasarán por cambios necesarios para obtener una respuesta prevista, esto se obtiene ajustando sus interacciones, así, si se van a modelar sistemas, es necesario contar con un mecanismo para los cambios en el modelo. El diagrama de estado UML captura este tipo de cambios. Presenta los estados en los que puede centrarse un objeto junto con las transiciones entre los estados, y muestra también, los puntos inicial y final de una secuencia de cambios de estado. Un diagrama de estados también se conoce como un motor de estado. Es importante aclarar que un diagrama de estados es intrínsecamente distinto de uno de clase, de objeto o de caso de uso. Se han visto diagramas que modelan el comportamiento de un sistema, o al menos un grupo de clases, objetos o cases de uso. Un diagrama de estados muestra las condiciones de un solo objeto, esto no quiere decir que no se puedan definir más objetos, pero estos una vez identificados, se pueden manejar por separado. Simbología La forma de representar el diagrama de estado es a través de un rectángulo de vértices redondeados, junto con una línea continua y una punta de flecha, mismas que representan a una transición. La punta de la flecha apunta hacia el estado hacia donde se hará la transición. La figura también muestra un círculo relleno que simboliza un punto inicial y la diana que representa a un punto final. No solo las clases se pueden dividir en tres áreas (Nombre. atributos y operaciones), el lenguaje UML da la opción de agregar detalles al icono de estado, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado. El área superior contendrá el nombre del estado, el área central contendrá las variables de estado y el área inferior las actividades. Figura 22: División del icono de estado en 3 partes 18 18

31 Las variables de estado como cronómetros o contadores son, en ocasiones, de ayuda. Las actividades constan de sucesos y acciones: tres de las mas utilizadas son entrada (que sucede cuando el sistema entra al estado), salida (que sucede cuando el sistema sale del estado) y hacer (que sucede cuando el sistema esta en el estado). Se pueden agregar otros conforme sea necesario. Ejemplificando lo que el objeto cuenta de usuario puede hacer dentro de un sistema, quedaría de la siguiente manera: Figura 23: Ejemplo de diagrama de estado Diagrama de actividades.- Un diagrama de actividades representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Es una variante del diagrama de estados, organizado respecto de las acciones y principalmente destinado a representar el comportamiento interno de un método (la realización de una operación) o de un caso de uso. Una de las características de un diagrama de actividades es que no posee transiciones internas, ni transiciones desencadenadas por eventos. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. 19

32 Un diagrama de actividades contiene estados de actividad que representa la ejecución de una secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo; en vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminación de su cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del diagrama. Una transición de terminación es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por transiciones en estados que los incluyen. Un diagrama de actividades puede contener también estados de acción, que son similares a los de actividad pero son atómicos y no permiten transiciones mientras están activos. Los estados de acción se deben utilizar para las operaciones cortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos concurrentes, los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia además del control secuencial. Con respecto a la notación de este tipo de diagramas, un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripción de actividad. Las transacciones simples de terminación se muestran como flechas. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con múltiples flechas de salida etiquetadas. Una división o una unión de control se representan con múltiples flechas que entran o salen de la barra gruesa de sincronización. Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un disparador en una transición, o como un símbolo especial que denota la espera de una señal. A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de asignación puede mostrarse organizando las actividades en regiones distintas separadas por líneas en el diagrama. Debido a su aspecto, esto es conocido como Calles. Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua desde el objeto a una actividad. 20