Embed Size (px)
Citation preview
1
MODULO
LENGUAJE UNIFICADO DE MODELADO UML ING. HAROLD CABRERA MEZA
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
SAN JUAN DE PASTO, 2006
2
TABLA DE CONTENIDO
INTRODUCCION .................................................................................................... 6
1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO ..................... 7
1.1. QUÉ ES UML?................................................................................................. 7
1.1.2. UML NO ES UN MÉTODO ........................................................................... 8
1.1.3. MODELOS .................................................................................................... 9
1.1.4. ELEMENTOS COMUNES A TODOS LOS DIAGRAMAS .......................... 10
1.2. MODELADO ESTRUCTURADO ................................................................... 11
1.2.1. BLOQUES DE CONSTRUCCIÓN DE UML................................................ 11
1.2.2. CLASES...................................................................................................... 15
1.2.3. OBJETOS ................................................................................................... 17
1.2.4. ASOCIACIONES......................................................................................... 18
1.2.5. DIAGRAMAS .............................................................................................. 20
1.2.6. DIAGRAMAS DE CLASE ........................................................................... 23
1.2.7. CARACTERÍSTICAS AVANZADAS DE LAS CLASES Y RELACIONES . 26
1.2.8. INTERFACES, TIPOS Y ROLES................................................................ 31
1.2.9 PAQUETES E INSTANCIAS ...................................................................... 35
1.2.10. HERENCIA Y POLIMORFISMO ............................................................... 36
2. CARACTERISTICAS DEL MODELADO UML ................................................. 38
2.1. DIAGRAMAS UTILIZADOS EN UML............................................................ 38
3
2.1.1. DIAGRAMAS DE OBJETOS ...................................................................... 38
2.1.2. DIAGRAMAS DE CASOS DE USO............................................................ 40
2.1.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 45
2.1.4. DIAGRAMAS DE ACTIVIDADES............................................................... 47
2.2. MODELADO DINÁMICO ............................................................................... 51
2.2.1 EVENTOS Y SEÑALES............................................................................... 51
2.3.2 MÁQUINAS DE ESTADO............................................................................ 53
2.4.3 TIEMPO Y ESPACIO ................................................................................... 55
2.4.4 DIAGRAMAS DE ESTADO ......................................................................... 56
2.3. MODELADO ARQUITECTÓNICO................................................................. 57
2.3.1. COMPONENTES, DESPLIEGUE, COLABORACIONES Y PATRONES... 57
2.3.2. DIAGRAMAS DE COMPONENTES ........................................................... 61
2.3.3. DIAGRAMAS DE DESPLIEGUE ................................................................ 62
2.3.4. SISTEMAS Y MODELOS ........................................................................... 63
3. DESARROLLO ORIENTADO A OBJETOS CON UML ................................... 66
3.2. FASE DE PLANIFICACIÓN Y ESPECIFICACIÓN DE REQUISITOS........... 68
3.2.1 ACTIVIDADES............................................................................................. 68
3.2.2. REQUISITOS .............................................................................................. 68
3.2.3. CONSTRUCCIÓN DEL MODELO DE CASOS DE USO............................ 74
3.2.4. PLANIFICACIÓN DE CASOS DE USO SEGÚN CICLOS DE
4
DESARROLLO ..................................................................................................... 75
3.3. DISEÑO DE ALTO NIVEL ............................................................................. 76
3.3.1 ACTIVIDADES............................................................................................. 77
3.3.2. MODELO CONCEPTUAL........................................................................... 77
3.3.3. DIAGRAMAS DE SECUENCIA DEL SISTEMA......................................... 79
3.3.4. DIAGRAMAS DE ESTADOS...................................................................... 81
3.4. DISEÑO DE BAJO NIVEL ............................................................................. 82
3.4.1 ACTIVIDADES............................................................................................. 82
3.4.2. CASOS DE USO REALES ......................................................................... 82
3.4.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 83
3.4.4. CONSTRUCCIÓN DIAGRAMAS DE DISEÑO ........................................... 88
3.5. FASES DE IMPLEMENTACIÓN Y PRUEBAS.............................................. 90
5
PRIMERA UNIDAD
INTRODUCCIÓN AL LENGUAJE UNIFICADO DE
MODELADO
6
INTRODUCCION
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 existen. Para estas fases del desarrollado 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 Modelin Language UML), es un lenguaje estándar para escribir planos de software, UML se puede utilizarse 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: 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, esta 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
1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO
1.1. Qué es Uml? El Lenguaje Unificado de Modelado (Unifield Modelin Language UML), es un lenguaje estándar para escribir planos de software, UML se puede utilizarse 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: 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 fuese dirigido por los casos de uso, centrado en la arquitectura, interactivo e incremental
UML es una consolidación de muchas de las notaciones y conceptos más usadas 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 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. 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 1999.
8
1.1.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 orientadas a objetos
UML se construye con modelos estándar sobre análisis y diseño de sistemas orientados a objetos de las cuales las más populares se incluyen las siguientes:
Catálisis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas especificas 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 como 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. (www.hpl.hp.com/fusion/file/teameps.pdf)
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 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
9
1994), (Object-Oriented Design, With Applications), detallan un mFodo ofreciendo también diseño y análisis 'iterative', centrándose en el lado del diseño.
1.1.3. 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.
Los modelos de UML que se tratan en esta parte son los siguientes:
• 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.
10
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 temporal de los mensajes.
• 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.
1.1.4. Elementos comunes a todos los diagramas
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 no 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 sola como unida a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
Figura 1.
11
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).
1.2. 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 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 ves comprendida estas ideas, se pueden leer modelos UML y crear algunos modelos básicos.
1.2.1. 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 2.
12
Elementos Estructurales Nombre Descripción Símbolo Interfaz • Es una colección de operaciones que
especifica un servicio de una clase o componente, representa el comportamiento completo de una clase o componente
Colaboración • Se definen como una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos
• las colaboración representan la implementación de patrones que forman un sistema
Caso de Uso • Es una descripción de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular
• Se utiliza para estructurar el comportamiento en un modelo
Clase Activa • Es un clase objetos tienen uno o mas procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control
• Son iguales a las clases excepto en que sus objetos representan elementos cuyos comportamiento es concurrente con otros elementos
Componente • 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
Nodo • Es un elemento físico que existe en tiempo de ejecución y representa un rescursos computacional que dispone de memoria y con frecuencia capacidad de procesamiento
Nodo1
13
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 e 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: Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propósito especifico
• Máquina de Estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos
Estos dos elemento (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
14
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. Relaciones en UML Dependencia: Es una relación semántica entre dos elementos, en la cual un cambio a un elemento pude afectar la semántica de otro elemento
Asociaciones: Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objeto y representa 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 1.1.2. de este módulo).
15
1.2.2. 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 que sean hardware, software o completamente conceptuales. Las clases 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 ex,
Figura 3.
Componentes de las Clases
Una clase es un descripción de un conjunto de objetos que comparten los mimos atributo, operaciones, relaciones y semántica, 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 1. Nombre: una clase a de contener un nombre que la identifique, compuesto por cualquier numero de letras y números exceptuado los dos puntos pues estos se utilizan para separar el nombre de una clase y el paquete que lo contiene.
2. Atributos: es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Un atributo representa alguna propiedad del elemento que se está modelando que es compartida por todos los objetos de esa clase, además, una clase puede o no contener atributos. Por ejemplo un atributo de la clase estudiante es el nombre, apellido, fecha Nacimiento, etc.
Figura
Origen
Mover()
Visualizar()
Nombre
atributos
operaciones
16
Figura 4.
3. Operaciones: Es una abstracción de de algo que se puede haber a un objeto y que es compartido por todos los objetos de la clase, las clases pueden tener o no operaciones. Ejemplo en la clase estudiante se puede a los objetos generados por ella, matricular, evaluar, aprobar y estas operaciones son comunes a todos los objetos que se describen a través de la clase estudiante.
Figura 5.
4. Responsabilidades: Es una obligación de las clases, al crear una clase, se esta expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento, de forma mas general los atributos y operaciones son las características por medio de la cuales se llevan a cabo las responsabilidades de la clase. Gráficamente las responsabilidades se pueden expresar en un comportamiento separado al final del icono de la clase.
Figura 6.
Estudiante
nombre
apellido
fecha Nacimiento
atributos
Estudiante
Nombre
Apellido
Fecha nacimiento
Matricular()
Evaluar()
Aprobar()
Operaciones
Estudiante
nombre
apellido
fecha Nacimiento
matricular()
evaluar()
aprobar()
Responsabilidades
Respetar el
Reglamento
Estudiantil
Responsabilidades
17
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
1.2.3. 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.
Figura 7.
18
1.2.4. 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 en la cual leer el nombre de la asociación. En el ejemplo se puede leer la asociación como “Director manda sobre Empleado”.
Figura 8.
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.
19
Multiplicidad
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 9.
20
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. 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 10.
1.2.5. Diagramas
Un diagrama es una presentación gráfica de un conjunto de elementos, que la mayoría de la veces se dibuja como un conjunto de elementos relacionados, los diagramas se utilizan para representar un sistema desde diferentes perspectivas, por esto UML a definido varios diagramas que permiten centrarse en diferentes aspectos del sistema independientemente. 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.
21
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 • 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 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.
22
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 mas utilizados como base del desarrollo de un modelo real, representa 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 las vista dinámica de un sistema. Diagramas de colaboración Es un diagrama 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. Diagramas de estado Representa 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
23
modelar la función de un sistema así como para resaltar el flujo de control entre objetos
1.2.6. 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 cuado 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.
24
Cuando se crea un diagrama de clases, se esta 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 facturacomestibles y facturainmuebles 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 11.
Factura
Registrar venta()
Registrar proveedor()
Registrar cliente()
Informes()
facturacomestibles facturainmuebles
Ventas
Responsabilidad
Ventas promedio
Buscar clientes
controlventas
vendedor
*
1
1 1
1
1
25
• 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 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 la asociaciones que estructuran estas clases.
• Identificar las relaciones de las bases de datos sea uno a uno, uno a varios y sus asociaciones.
• Definir de manera clara las reglas de negocio relativas a la manipulación de datos dentro de la base de 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 12.
Universidad
Nombre: texto
Dirección: texto
Telefono: número
añadirEstudiante()
quitarEstudiante()
obtenerEstudiante()
añadirDepartamento()
quitarDepartamento()
obtenerDepartamento()
Estudiante
Nombre: texto
idEstudiante: número
Curso
Nombre: texto
idCurso: número
Profesor
Nombre: texto
Departamento
Nombre: texto
añadirProfesor()
quitarProfesor ()
obtenerProfesor ()
* asiste * enseña
* 1..*
1..*
1..*
Asignado a
0..1
director
0..1
tiene
1 1..*
26
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 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.
1.2.7. 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 13.
• Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos
primitivos predefinidos.
Figura 14.
<<type>>
int (valores entre -32000 y 320000)
27
• Señal: la especificación de un estímulo asíncrono enviado entre instancias
Figura 15.
• Componente: una parte física y reemplazable de un sistema que conforma y
proporciona la realización de un conjunto de interfaces.
Figura 16.
• Nodo: un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, generalmente con alguna memoria y a menudo capacidad de almacenamiento.
Figura 17.
• Caso de uso: descripción de una secuencia de acciones, incluye variantes, que se ejecuta un sistema y produce un resultado observable para un actor particular
Figura 18.
<<signal>> DisparoAlarma
Kernell32
28
• Subsistema: agrupación de elementos, algunos de los cuales constituyen una
especificación del comportamiento de los otros elementos contenidos
Figura 19. 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 lo 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 semi privados, solo se relacionan con las clases que han sido descendientes de la clase padre se marcan con el símbolo #. Cuando se usa una clase, es probable que se desee 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:
<<subsystem>>
subsistema de servicio al
cliente
29
Figura 20.
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 esta definida en la clase que los contiene pero con la diferencia de que la operación cambia de significado dependiendo del contexto donde se este 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. 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
Factura(root)
Registrar venta()
Registrar proveedor()
Registrar cliente()
Informes()
Facturacomestibles
Mostrarusuario()
Facturainmuebles
Mostrarusuario() (leaf)
Clase padre principal
Clases hijos
Clases hoja, no puede
tener mas hijos
30
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 mas efectivo de ese elemento (subclase o hijo). Por ejemplo, se puede encontrar la clase general ventana junto a un tipo mas especifico 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 a mayoría de las veces, aunque, la herencia múltiple es mas adecuada, gráficamente se muestra de la siguiente forma:
Figura 21.
En la figura anterior se muestra la clase activo con tres hijos: CuentaBancaria, inmueble y valor dos de estos hijos (CuentaBancaria, Inmueble) tienen sus propios hijos por ejemplo Accion 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
31
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 instanci 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 22.
1.2.8. 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.
1 * Usuario Clave
La línea representa una asociación y la fecha indica la
dirección del recorrido
32
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
Figura 23.
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 24.
Notese en la representación el nombre <<interface>> como identificador de la interfase definida.
IOrtografía
Red::IRouter
Nombre elemental
Nombre de camino
<<interface>>
FlujoURL
Abrirconexion()
EstablecerURL()
Operaciones de la interfaz
Nombre de la interfaz
33
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:
Figura 25.
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 mas detallada las operaciones con las cuales interactúan las clases definidas antes y después de la interfase, nótese como se representan las relaciones de dependencia de la misma forma como se mostró en las relaciones entre clases.
34
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 26.
Figura 27.
La figura anterior representa una asociación de clases con una interfaz especifica, como se ve existe una asociación de entre las clases persona y empresa en cuyp contexto persona juega un rol llamado e, cuyo tipo es empleado
35
1.2.9 Paquetes e Instancias
Un paquete es un mecanismo de próposito general para organizar elementos en grupos, graficamente un paquete se representa como una carpeta. Cada paquete a de contener un nombre que lo distingue de los demás.
Figura 28. 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
Figura 29.
+FormualarioDePedido
+FormularioDeSeguimiento
-Pedido
cliente Nombre del Paquete
Elementos contenidos en el
paquete
teclasPulsadas: Colas
: Marco
Instancia con nombre
Instancia anónima
agente: Instancia huérfana
36
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.
1.2.10. Herencia y polimorfismo
Polimorfismo
Una de las características fundamentales de la OOP es el polimorfísmo, 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 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”.
37
SEGUNDA UNIDAD
CARACTERISTICAS DEL MODELADO UML
38
2. CARACTERISTICAS DEL MODELADO UML
2.1. Diagramas Utilizados en UML
2.1.1. 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 sistemas, 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.
39
Figura 30. 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 Area. 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
40
estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototípicos.
2.1.2. 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 31.
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.
41
Caso de Uso:
Figura 32.
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 especifica en el apartado 1.2.4 de este modulo, 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.
42
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 (<<extends>>).
Este tipo de relación esta 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 esta la duda clásica de usar o heredar.
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar lo siguiente:
• Registrar el número de ítemes ingresados. • Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado b. El valor de cada item c. Total
• El usuario/cliente presiona el botón de comienzo • Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo
depositado en el día. • El operador debe además poder cambiar:
a. Información asociada a ítemes. b. Dar una alarma en el caso de que:
• Item se atora.
• No hay más papel.
43
Como una primera aproximación identificamos a los actores que interactúan con el sistema:
Figura 33.
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:
Figura 34.
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Figura 35.
44
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Figura 36.
Entonces, el diseño completo del diagrama casos de uso es:
Figura 37.
45
2.1.3. 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 y Diagramas de Colaboración. 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 38.
c : Cliente
:Transacción
p : ProxyODBC
Foco de control
<<create>>
éxito
<<destroy>>
establecerAcciones(a,d,o) establecerValores(d,3,4)
establecerValores(a,”CO”)
Línea de vida
Objetos
Tiempo
46
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 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. 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 la lector una señal visual clara del flujo de control en el contexto de la organización estructural de los objetos que colaboran
Figura 39.
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 mas lejano de un enlace con la palabra local que indica que el objeto designado es local al emisor. En segundo lugar esta el numero de secuencia, para indicar la ordenación temporal de los mensajes, se
c : Cliente
:Transacción P : ProxyODBC
1: <<create>>
2: establecerAcciones(a,d,o)
3: <<destroy>>
Objeto
<<local>>
<<global>>
2.1:establecerValores(d,3,4)
2.2: establecerValores(a,”Co”)
enlace
mensaje
47
precede de un numero iniciando con el numeral 1, que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control
2.1.4. Diagramas de Actividades
Un diagrama de actividades muestra el flujo de actividades, siendo un actividad una ejecución general entre los objetos que se esta 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” En la siguiente figura, podemos ver ejemplos de estados de acción.
48
Figura 40.
En cambio un estado de actividad, sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Ademá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 41.
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 Figura 41.
ProcesarFactura(Fact)
Entry / SacarPrimeraFactura(Fact)
Estado de Acción
49
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 42. 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 43.
Bifurcación secuencial
50
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 44.
clientes ventas almacén
Solic Producto
Procesar Pedido
Extraer Pedido
Enviar Pedido
Recibir Pedido Fact. Cliente
Pagar Factura
Cerrar Pedido
51
2.2. Modelado dinámico
2.2.1 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 la máquinas de estado, un evento es la aparición de un estímulo que puede disparar una transición de estado. Un 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 realcion 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 44.
<<signal>>
colisión
fuerza : Float
AgenteDeMovimiento
Posición
Velocidad
moverA() <<send>>
Señal
parámetros
52
Eventos 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 45.
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 e cumplimiento de alguna condición, se modela con la palabra when seguida de alguna expresión booleana.
Figura 46.
Manual Automático iniciarpilotoAutomático(normal)
evento
parámetro
Inactivo Activo alter (2 Segundos)
/cortarConexión()
when (11:49 PM) /AutoTest()
Evento de cambio Evento de tiempo
53
2.3.2 Máquinas de Estado
Una máquina de estados 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 aconecimietno significativo que ocupa un lugar en el tiempo y el espacio, es la estimulación que puede disparar una transición de estados Un 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 condcion o situación enla 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 47.
Inactivo Funcionando teclaPulsada
Terminado
apagar
estado
nombre nombre
Estado inicial Estado final
54
Como se observa en la grafica anterior en la máquina de estados de un objeto se pueden definir dos estados especiales, en primer lugar e punto inicial que indica el puno 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 del estado que lo contiene ha finalizado Transiciones Una transición es una relación entre dos estados que indica que un objeto que esté en el primer lugar estado realizará ciertas acciones y entrará en el segundo estado cuando ocurra un evento específico y se satisfagan unas condiciones específicas, 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 esta en el estado destino.
Figura 48.
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 mimos
Inactivo Inactivo Inactivo
Inactivo Inactivo
alter (2 Segundos) /send c.estaActivo
ruido
contactar
objetoEn(p)[representaAmenaza]/
t.añadirObjeto(p)
Evento de tiempo Envío de señal
autotransición
Evento de disparo
Transición sin disparador
Evento de disparo con parámetros
condicion de gurda acción
55
2.4.3 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 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 49. 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 50.
c : ControladorMIDI : ColecciónDeNotas
n: Nota
t : TransmisionMIDI b: BufferDeEventosMIDI
{cada 1ms}
c1 : notasDePrueva
{executeTime <10 ms}
c2 : notasDePrueba()
c3 : a ñadir(k)
t1 : quitar()
{cada 1 ms}
Restricción de tiempo
Restricción de tiempo
Restricción de tiempo
t : TransmisionMIDI
{location=Enrutador}
Localización por inclusión
Valor etiquetado de localización
56
2.4.4 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
Figura 51.
Inactivo
Transmisión
Conectando Procesando
Limpiando
sonando
cabeceraOK
verificaciónOK
entry/descolgar
exit/desconectar
colgar
error/imprimirError
enviarFax
Estado inicial
estado
acción
Estado compuesto
evento evento
acción
Transición sin
disparador
57
2.3. Modelado Arquitectónico
2.3.1. 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 52.
Figura 53.
Agentefraudes.dll
agenteFraudes PoliticaFraudes BusquedaDePatrones
Componente con nombre
simple
clases
Imagen.java
Imagen.java
ObservadorDeImagen
Relación de dependencia realización
Interfaz
58
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 54. 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 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
ventas
pos.exe
Contactos.exe
nodo con nombre
simple
componentes
59
siguiente figura
Figura 55. 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 si par llevar a cabo algún comportamiento común, estos mecanismo se muestran como colaboraciones simples, ya que solamente dan el nombre a una sociedad de clases. Figura 56.
Paso de mensajes
entre nodos
Nombre
facturación
comprobación
<<framework>>
recepción de pedidos
mecanismos
frameworks
60
Los mecanismos pueden nombrar una plantilla formada por un conjunto de 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
Figura 57.
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 abtracciones en EventosComunes creando subclases y también podría emplear una instancia del mecanismo GestorDeEventos
ColaTares
BarraDesplazamiento
Observador
Sujeto
Observador
Sujeto
Observador
ligadura
rol
rol
platilla
colaboraciones
61
Figura 58.
2.3.2. 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 su interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama
GestorDeEvento
s
Cliente
Gestor
EventosComunes
<<frameworks>>
AdministradorCiclico
Pacificador
colaboraciones
ligaduras frameworks
62
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 un 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 60.
2.3.3. 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 nodo físicos y sus relaciones y para especificar sus detalles para la construcción, como se muestra a continuación
find.exe
nateng.dll
find.html
componente
página
biblioteca
63
Figura 61.
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.
2.3.4. 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
<<procesadorr>>
servidor cache
<<procesadorr>>
servidor cache
<<procesadorr>>
servidor principal
<<procesadorr>>
servidor
<<procesadorr>>
servidor
<<procesadorr>>
servidor
modem
conexión
nodo
nodo
64
Figura 62. 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.
<<system>>
sistema de
ventas
<<subsystem>>
subsistema de
gestión de
producción
<<subsystem>>
subsistema de
gestión de
almacén
<<subsystem>>
subsistema de
servicio al
cliente
65
TERCERA UNIDAD
DESARROLLO ORIENTADO A OBJETOS CON UML
66
3. 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 mantenible 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 ser planificable 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. Visión General El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos 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.
67
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. Las tres fases al nivel más alto son las siguientes: • Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. • Construcción: 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
68
3.2. 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.
3.2.1 Actividades
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.
3.2.2. 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
69
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.. 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.
70
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. -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.
71
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
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.
72
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: Representan los procesos principales, los más comunes, como Realizar Reintegro en el caso del cajero automático.
• Secundarios: Representan 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.
73
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 de
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 un 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.
Así, si en un determinado número de línea hay una bifurcación se pueden poner opciones que dirigen el caso de uso a una sección que se detalla al final del Curso
Un caso Típico de Eventos, en la siguiente forma:
- Curso Típico de Eventos: - Sección: Principal Acción del Actor Respuesta del Sistema
1. Este caso de uso empieza cuando Actor llega al sistema.
74
2. Pide la operación a realizar. 3. Escoge la operación A. 4. Presenta las opciones de pago. 5. Selecciona el tipo de pago: Si se paga al contado ver sección Pago al Contado.
O si se paga con tarjeta ver sección Pago con Tarjeta. 6. Genera recibo. 7. Recoge el recibo y se va.
Cursos Alternativos:
Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.
Sección: Pago al Contado Acción del Actor Respuesta del Sistema
1. Mete los billetes correspondientes 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad está satisfecha 3. Devuelve el cambio.
Cursos Alternativos:
Línea 3: No hay cambio suficiente. Se cancela la operación.
3.2.3. Construcción del Modelo 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.
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.
75
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).
3.2.4. 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 63.
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:
76
• 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.
3.3. 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.
77
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.
3.3.1 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)
3.3.2. 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.
78
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 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: 1. 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.
2. Representarlos en un diagrama. 3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer.
4. 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
79
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.
• 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.
3.3.3. Diagramas de Secuencia del Sistema
Además de investigar sobre los conceptos del sistema y su estructura, también es preciso investigar en 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
80
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.
Figura 64.
81
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.
3.3.4. 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.
82
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.
3.4. 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.
3.4.1 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. 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.
3.4.2. 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
83
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.
3.4.3. 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. Creación de 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.
84
• 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, puedo 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.
85
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 65.
86
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. 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
87
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 <<>>.
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
88
3.4.4. 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:
1. Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción.
2. Representarlas en un diagrama de clases. 3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual.
4. Añadir los métodos, según aparecen en los Diagramas de Interacción. 5. Añadir información de tipo a los atributos y métodos. 6. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida.
7. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos.
8. 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.
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, un 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.
89
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 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
90
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.
3.5. Fases de 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.
