Está en la página 1de 90

MODULO LENGUAJE UNIFICADO DE MODELADO UML ING.

HAROLD CABRERA MEZA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA SAN JUAN DE PASTO, 2006

TABLA DE CONTENIDO INTRODUCCION .................................................................................................... 6 1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO ..................... 7 1.1. QU ES UML?................................................................................................. 7 1.1.2. UML NO ES UN MTODO ........................................................................... 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 CONSTRUCCIN 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. CARACTERSTICAS 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

2.1.1. DIAGRAMAS DE OBJETOS ...................................................................... 38 2.1.2. DIAGRAMAS DE CASOS DE USO............................................................ 40 2.1.3. DIAGRAMAS DE INTERACCIN .............................................................. 45 2.1.4. DIAGRAMAS DE ACTIVIDADES ............................................................... 47 2.2. MODELADO DINMICO ............................................................................... 51 2.2.1 EVENTOS Y SEALES............................................................................... 51 2.3.2 MQUINAS DE ESTADO............................................................................ 53 2.4.3 TIEMPO Y ESPACIO ................................................................................... 55 2.4.4 DIAGRAMAS DE ESTADO ......................................................................... 56 2.3. MODELADO ARQUITECTNICO................................................................. 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 PLANIFICACIN Y ESPECIFICACIN DE REQUISITOS ........... 68 3.2.1 ACTIVIDADES ............................................................................................. 68 3.2.2. REQUISITOS .............................................................................................. 68 3.2.3. CONSTRUCCIN DEL MODELO DE CASOS DE USO............................ 74 3.2.4. PLANIFICACIN DE CASOS DE USO SEGN CICLOS DE

DESARROLLO ..................................................................................................... 75 3.3. DISEO 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. DISEO DE BAJO NIVEL ............................................................................. 82 3.4.1 ACTIVIDADES ............................................................................................. 82 3.4.2. CASOS DE USO REALES ......................................................................... 82 3.4.3. DIAGRAMAS DE INTERACCIN .............................................................. 83 3.4.4. CONSTRUCCIN DIAGRAMAS DE DISEO ........................................... 88 3.5. FASES DE IMPLEMENTACIN Y PRUEBAS .............................................. 90

PRIMERA UNIDAD INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO

INTRODUCCION

Unas de las etapas vitales para un diseador de software, es el anlisis y diseo de sistemas, el anlisis de sistemas es el proceso de clasificacin e interpretacin de hechos, diagnstico de problemas y manejo de la informacin para hacer mejoras al sistema, siendo el diseo la fase de planificacin, reemplazo o complementacin de un sistema organizacional 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 estndar 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 estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego desplegar tales sistemas.

El curso acadmico denominado Lenguaje de Modelado -UML- Electiva, esta orientado a hacia el manejo adecuado de las herramientas que ofrece el lenguaje de modelado orientado a objetos, desde la construccin de los diagramas de interaccin del sistema hasta la aplicacin del modelo en un caso real de desarrollo.

1. INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO

1.1. Qu es Uml?

El Lenguaje Unificado de Modelado (Unifield Modelin Language UML), es un lenguaje estndar 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 estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego desplegar tales sistemas .

UML es slo un lenguaje y por tanto es tan solo una parte de un mtodo de desarrollo de software, adems, es independiente del proceso, aunque para utilizar ptimamente se debera usar en procesos que fuese dirigido por los casos de uso, centrado en la arquitectura, interactivo e incremental UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares, en 1996, el Object Management Group (OMG), public una peticin con propsito de un metamodelo orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versin 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versin 1.1. El OMG estaba actualmente en proceso de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1 de abril de 1999.

1.1.2. UML no es un mtodo Inicialmente los mtodos son una tcnica para llevar a cabo una accin, Uml es un compendio de modelos que pueden ser interpretados de forma directa a una gran variedad de lenguajes de programacin como Java, C++ o Visual Basic, e incluso a tablas en una base de datos relacional o una base de datos orientadas a objetos

UML se construye con modelos estndar sobre anlisis y diseo de sistemas orientados a objetos de las cuales las ms populares se incluyen las siguientes:

Catlisis: Un mtodo orientado a objetos que fusiona mucho del trabajo reciente en mtodos orientados a objetos, y adems ofrece tcnicas especificas para modelar componentes distribuidos.

Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson.

Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos, modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor continan actualizando su mtodo continuamente (la actualizacin ms reciente es el OOA96 report), y recientemente publicaron una gua sobre como usar la notacin UML con Shlaer/Mellor.

Fusin: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un mtodo de diseo orientado a objetos estndar. Combina OMT y Booch con tarjetas CRC y mtodos formales. (www.hpl.hp.com/fusion/file/teameps.pdf)

OMT: La Tcnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseo y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un mtodo que propone anlisis y diseo interactivo, ms centrado en el lado del anlisis.

Booch: Parecido al OMT, y tambin muy popular, la primera y segunda edicin de "Diseo Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y

1994), (Object-Oriented Design, With Applications), detallan un m odo ofreciendo tambin diseo y anlisis 'iterative', centrndose en el lado del diseo. 1.1.3. Modelos Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.

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 ms comunes en el modelo orientado a objetos y cubren las vistas de diseo esttico de un sistema.

Diagramas de Objetos: muestra un conjunto de objetos y sus relaciones, representan instancias de los elementos encontrados en los diagramas de clases, representado cubren las vistas de diseo esttico de un sistema desde la perspectiva de casos reales. Diagrama de Actividades: es un tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema, cubren la vista dinmica de un sistema. Son especialmente importantes al modelar el funcionamiento de un sistema y resaltan el flujo de control de objetos. Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de componentes, cubren la vista esttica de un sistema. Diagrama de Despliegue: muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos, cubren la vista de despliegue esttica de una arquitectura.

Diagrama de Casos de Uso: muestra un conjunto de casos de uso, actores y relaciones, cubren la vista de casos de uso esttica de un sistema. Diagrama de Secuencia: es un diagrama de interaccin que resalta la ordenacin temporal de los mensajes.

Diagrama de Colaboracin: es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensaje. Diagrama de Estados: Muestra una mquina de estados, que consta de estados, transiciones, eventos y actividades, cubren la vista dinmica de un sistema, resaltan el comportamiento dirigido por eventos de un objeto.

1.1.4. Elementos comunes a todos los diagramas

Notas

Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar informacin en un formato libre, cuando la notacin del diagrama en cuestin no nos permite expresar dicha informacin de manera adecuada. Una nota se representa como un rectngulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una lnea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.

Figura 1.

10

Dependencias La relacin de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habra que revisar el elemento origen). Una dependencia se representa por medio de una lnea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a l est la flecha). 1.2. Modelado Estructurado

Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje y esto requiere aprender tres elementos principales: los bloques bsicos de construccin de UML, las reglas que dictan cmo se pueden combinar estos bloques bsicos y algunos mecanismos comunes que se aplican a travs de UML, Una ves comprendida estas ideas, se pueden leer modelos UML y crear algunos modelos bsicos.

1.2.1. Bloques de Construccin de UML El vocabulario de UML incluye tres clases de bloques de construccin Elementos en UML Hay 4 tipos de elementos en UML, elementos estructurales, elementos de comportamiento, elementos de agrupacin y elementos de anotacin: .

Figura 2.

11

Elementos Estructurales Nombre Descripcin Smbolo Es una coleccin de operaciones que Interfaz especifica un servicio de una clase o componente, representa el comportamiento completo de una clase o componente Se definen como una interaccin y es Colaboracin 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 colaboracin representan la implementacin de patrones que forman un sistema Caso de Uso Es una descripcin de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de inters para un actor particular Se utiliza para estructurar el comportamiento en un modelo Es un clase objetos tienen uno o mas Clase Activa procesos o hilos de ejecucin y por lo tanto pueden dar origen a actividades de control Son iguales a las clases excepto en que sus objetos representan elementos cuyos comportamiento es concurrente con otros elementos Es una parte fsica y reemplazable de Componente un sistema que conforma con un conjunto de interfaces y proporciona la implementacin de dicho conjunto Representa tpicamente e empaquetamiento fsico de diferentes elementos lgicos, como clases interfaces y colaboraciones Nodo Es un elemento fsico que existe en Nodo1 tiempo de ejecucin y representa un rescursos computacional que dispone de memoria y con frecuencia capacidad de procesamiento

12

Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos) son los elementos estructurales bsicos que se pueden incluir en el modelo UML. Tambin existen variaciones de estos siete elementos, tales como actores, seales, procesos e hilos, y aplicaciones, documentos, archivos, bibliotecas, pginas y tablas.

Los elementos de comportamiento son las partes dinmicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y en el espacio. Interaccin: Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propsito especifico Mquina de Estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos

Estos dos elemento (interacciones y mquinas de estado) son los elementos de comportamiento que se pueden incluir de un modelo UML, estos elementos estn conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos.

Los Elementos de agrupacin son las partes organizativas de los modelos UML. Estos son las cajas en las que pueden descomponerse un modelo Paquete Es un mecanismo de propsito general para organizar elementos en grupos. En los paquetes se pueden agrupar los elementos estructurales, de comportamiento e incluso otros elementos de agrupacin

Los paquetes son los elementos de agrupacin bsicos con los cuales se puede organizar un modelo UML. Tambin hay variaciones, tales como los framework, los modelos y los subsistemas

13

Relaciones

Existen cuatro tipos de la relaciones en UML Dependencias Asociaciones Generalizaciones Realizacin Estas relaciones son los bloques bsicos de construccin para las relaciones de UML. Relaciones en UML

Dependencia: Es una relacin semntica entre dos elementos, en la cual un cambio a un elemento pude afectar la semntica de otro elemento Asociaciones: Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objeto y representa una relacin estructural entre un todo y sus partes

Diagramas

Un diagrama es la representacin grfica de un conjunto de elementos, visualizando la mayora de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema, un diagrama representa una vista resumida de los elementos que constituyen un sistema. (Los tipos de diagramas que utiliza UML se mencionan en el Numeral 1.1.2. de este mdulo).

14

1.2.2. Clases

Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica, las clases pueden representar cosas que sean hardware, software o completamente conceptuales. Las clases forman parte de una distribucin equilibrada de responsabilidades en el sistema UML representa una representacin grfica de las clases como se muestra en la figura ex,

Nombre

Figura Origen Mover() Visualizar()

atributos

operaciones

Figura 3. Componentes de las Clases

Una clase es un descripcin de un conjunto de objetos que comparten los mimos atributo, operaciones, relaciones y semntica, grficamente una clase se representa como un rectngulo, en el cual se describen las caractersticas 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 nmeros 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, adems, una clase puede o no contener atributos. Por ejemplo un atributo de la clase estudiante es el nombre, apellido, fecha Nacimiento, etc.

15

Estudiante nombre apellido fecha Nacimiento

atributos

Figura 4.

3. Operaciones: Es una abstraccin 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 travs de la clase estudiante.
Estudiante Nombre Apellido Fecha nacimiento Matricular() Evaluar() Aprobar()

Operaciones

Figura 5. 4. Responsabilidades: Es una obligacin 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 caractersticas por medio de la cuales se llevan a cabo las responsabilidades de la clase. Grficamente las responsabilidades se pueden expresar en un comportamiento separado al final del icono de la clase.
Estudiante nombre apellido fecha Nacimiento matricular() evaluar() aprobar() Responsabilidades Respetar el Reglamento Estudiantil

Responsabilidades

Figura 6.

16

Usos Comunes de las Clases

Las clases se utilizan para modelar y representar el conjunto de elementos de un sistema de manera general (abstracciones), para determinar los problemas que se intenta resolver y as implementar una solucin.

Para definir las clases que intervienen dentro de un sistema se recomienda como puntos de partida las siguientes consideraciones:

Identificar aquellas cosas que utilizan los usuarios o programadores para describir el problema o la solucin Identificar las responsabilidades de cada clase y asegurarse que cada clase existe Identificar los atributos y operaciones necesarios para cumplir sus responsabilidades Hacer del conjunto de clases y sus responsabilidades un modelo equilibrado donde no existan clase demasiado grandes ni pequeas Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de la clase que sean importantes, como tambin sus atributos y operaciones

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, segn la siguiente sintaxis: nombre_del_objeto:nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase.

Figura 7.

17

1.2.4. Asociaciones

Es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro. Dada una asociacin entre dos clases, se puede navegar desde un objeto de una clase hasta el objeto de otra clase, y viceversa. Una asociacin que conecta dos clases se dice binaria, s conecta ms de dos clases se denomina asociacin n-arias, las asociaciones se utilizarn cuando se quieren representar relaciones estructurales.

Caractersticas de las Asociaciones y operaciones Nombre de la Asociacin y Direccin

El nombre de la asociacin se utiliza para describir la naturaleza de la relacin, es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un pequeo tringulo negro slido que indique la direccin en la cual leer el nombre de la asociacin. En el ejemplo se puede leer la asociacin 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 informacin que se presenta, con el consiguiente riesgo de saturacin. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregacin y de herencia no se suele poner el nombre.

18

Multiplicidad

La multiplicidad es una restriccin que se pone a una asociacin, que limita el nmero de instancias de una clase que pueden tener esa asociacin con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un nmero fijo: 1. Con un intervalo de valores: 2.5. Con un rango en el cual uno de los extremos es un asterisco Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o ms. Con una combinacin de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*. Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o ms).

Roles Un rol es simplemente la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo.

Figura 9.

19

Para indicar el papel que juega una clase en una asociacin se puede especificar un nombre de rol. Se representa en el extremo de la asociacin junto a la clase que desempea dicho rol. Agregacin

El smbolo de agregacin 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 presentacin grfica de un conjunto de elementos, que la mayora 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 proyeccin grfica de los elementos que configuran un sistema. Por ejemplo, se podra tener cientos de clases en el diseo de un sistema de recursos humanos de un empresa, pero no se podra ver la estructura o el comportamiento de ese sistema observando un gran diagrama con todas sus clases y relaciones, es entonces preferible realizar varios diagramas que especifiquen las vistas relevantes solamente a ese subsistema definido, este tipo de manejo de diagramas representativos por clases permite realizar agrupaciones que muestran el funcionamiento general del sistema de forma particular pero denotando el funcionamiento general del sistema con todos sus elementos constitutivos.

20

Con el modelado de sistemas se obtienen deferentes tipos de vistas, las vistas estticas de los sistemas en UML se representan con 4 tipos de diagramas que se describen a continuacin

Diagramas Estructurales

los cuales comprenden los siguientes diagramas

Diagramas de Clases

Representa un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Los diagramas de clases los diagramas ms comunes en el modelado de sistemas orientados a objetos. Estos diagramas se utilizan para describir las vista de diseo esttica de un sistema, incluyen clases activas se utilizan para cubrir la vista de procesos esttica de un sistema Diagramas de Objetos

Representa un conjunto de objetos y sus relaciones. Se utiliza para describir estructuras de datos y las instancias de los elementos encontrados en los diagramas de clases. Cubren la vista de diseo esttica o la vista de proceso esttica de un sistema al igual que los diagramas de clases. Pero desde la perspectiva de casos reales prototipos.

Diagramas de Componentes

Muestra un conjunto de componentes y relaciones, se utilizan para describir la vista de implementacin esttica de un sistema, se relacionan con los diagramas de clases en que un componente normalmente se corresponde con una ms clases. Interfaces o colaboraciones

Diagramas de despliegue

Muestra un conjunto de nodos y sus relaciones, se utilizan para describir la vista de despliegue esttica de una arquitectura, se relacionan con los diagramas de componentes en que un nodo normalmente incluye uno o ms componentes.

21

Diagramas de Comportamiento Los cuales estn compuestos por los siguientes diagramas Diagramas de casos de uso En el modelado orientado a objetos los diagramas de casos de uso son los que representan en general el funcionamiento del sistema siendo estos los 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 interaccin que resalta la ordenacin temporal de los mensajes, este presenta un conjunto de objetos y los mensajes enviados por ellos. Los objetos suelen ser instancias con nombre, pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos, se utilizan para describir las vista dinmica de un sistema.

Diagramas de colaboracin Es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes, pueden representar instancias de otros elementos como colaboraciones, componentes y nodos. Se utilizan para describir la vista dinmica de un sistema.

Diagramas de estado Representa una mquina de estados constituida por estados, transacciones, eventos y actividades, se utilizan para representar la vista dinmica de un sistema son especialmente importantes para modelar el comportamiento de una interfaz, clase o una colaboracin, resaltan en comportamiento dirigido por eventos de un objeto.

Diagrama de Actividades

Muestra el flujo de actividades en un sistema, muestra el flujo secuencial o ramificado de actividades y los objetos en los que acta, son importantes para

22

modelar la funcin 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. Grficamente, un diagrama de clases es una coleccin de nodos y arcos. Los diagramas de clases contienen normalmente los siguientes elementos, clases, interfaces, colaboraciones, relaciones de dependencia, generalizacin y asociacin. Los diagramas pueden tambin notas, restricciones, paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes ms grandes.

Usos de los diagramas de clases

Se utilizan para modelar la vista esttica de un sistema, muestra principalmente los requisitos funcionales de un sistema y los servicios que el sistema debe proporcionar a sus usuarios finales

Los diagramas de clases se utilizan cuado se modela la vista de diseo de un sistema de la siguiente forma:

Para modelar el vocabulario de un sistema El modelado del vocabulario de un sistema implica tomar decisiones sobre que abstracciones son parte del sistema en consideracin y cuales caen fuera de sus lmites. Los diagramas de clases se utilizan para especificar estas abstracciones y sus responsabilidades

Para modelar colaboraciones simples Una colaboracin es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de todos los elementos.

23

Cuando se crea un diagrama de clases, se esta modelando una parte de los elementos y las relaciones que configuran la vista de diseo del sistema, por esta razn cada diagrama de clases debe centrarse en una colaboracin cada vez. Para modelar una colaboracin se debe tener en cuenta:

Identificar los mecanismos que se quiere modelar, un mecanismo representa una funcin o comportamiento de la parte del sistema que se est modelando que resulta de la interaccin de una sociedad de clases, interfaces y otros elementos. Identificar las clases, interfaces y otras colaboraciones que participan en esta colaboracin identificando las relaciones entre estos elementos. Usar escenarios para recorrer la interaccin entre estos elementos. Identificar las responsabilidades y hacer un reparto equilibrada de ellas en los elementos que componen el sistema

Por ejemplo la siguiente figura muestra un conjunto de clases que muestran el sistema de facturacin y control de ventas de una empresa, las clases se centran en la forma como se maneja la facturacin de inmuebles y productos de consumo, aparece una clase abstracta llamada factura que muestra a su vez 2 hijos facturacomestibles y facturainmuebles a su vez las dos clases se muestran como partes de otra clase denominada vendedor. La clase ventas tiene una asociacin uno a uno con vendedor y una asociacin uno a muchos con controlvendedor no se muestran atributos ni operaciones para la clase ventas pero s se muestran sus responsabilidades.
Ventas
1

*
1

controlventas vendedor

Responsabilidad Ventas promedio Buscar clientes

facturacomestibles

facturainmuebles

Factura

Registrar venta() Registrar proveedor() Registrar cliente() Informes()

Figura 11.

24

Para modelar un esquema lgico de base de datos Este esquema representa el plano que permite el diseo 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 diseo general de la bases de datos. Crear un diagrama de clases que contenga estas clases y marcarlas como persistentes. Expandir los detalles estructurales de estas clases, es decir, especificar los detalles de sus atributos y centrar su atencin en 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 manipulacin de datos dentro de la base de datos

La figura muestra un conjunto de clases extradas de un sistema de informacin que determina las relaciones entre los estudiantes, el profesor y el curso que el estudiante va a estudiar
Universidad Nombre: texto Direccin: texto Telefono: nmero aadirEstudiante() quitarEstudiante() obtenerEstudiante() aadirDepartamento() quitarDepartamento() obtenerDepartamento()
1

Departamento
tiene 1..*

0..1

Nombre: texto aadirProfesor() quitarProfesor () obtenerProfesor ()


1..*

1..*

Asignado a 0..1 director

Estudiante Nombre: texto idEstudiante: nmero

Curso
* asiste * ensea

Profesor Nombre: texto


* 1..*

Nombre: texto idCurso: nmero

Figura 12.

25

El anterior diagrama muestra en detalle cada una de las clases con sus respectivos atributos, los cuales permiten construir la base de datos fsica, comenzando por la parte inferior izquierda se encuentra las clases estudiantes, curso y profesores, hay una asociacin

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. Caractersticas Avanzadas de las Clases y relaciones El tipo ms importante de clasificador en UML es la clase, una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Sin embargo las clases no son el nico tipo de clasificador, existen otros tipos de clasificadores que ayudan a modelar:

Interfaz: es una coleccin de operaciones que especifican un servicio de una clase o componente

Figura 13.

Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos primitivos predefinidos.

<<type>>

int (valores entre -32000 y 320000)

Figura 14.

26

Seal: la especificacin de un estmulo asncrono enviado entre instancias

<<signal>>
DisparoAlarma

Figura 15.

Componente: una parte fsica y reemplazable de un sistema que conforma y proporciona la realizacin de un conjunto de interfaces.

Kernell32

Figura 16.

Nodo: un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, generalmente con alguna memoria y a menudo capacidad de almacenamiento.

Figura 17.

Caso de uso: descripcin de una secuencia de acciones, incluye variantes, que se ejecuta un sistema y produce un resultado observable para un actor particular

Figura 18.

27

Subsistema: agrupacin de elementos, algunos de los cuales constituyen una especificacin del comportamiento de los otros elementos contenidos

<<subsystem>> subsistema de servicio al cliente

Figura 19. Los clasificadores descritos anteriormente proporcionan al modelado de sistemas una vista general de comportamiento del sistema mostrndolo en detalle en sus atributos y operaciones

Generalidades de las clases

Es necesario saber que para el modelado de sistemas con Uml, las clases muestran en la definicin de sus atributos ciertos tipos de smbolos, los cuales determinan si los elementos asociados a cada clase son pblicos o privados por ejemplo: Si la marca de elemento es un +, indica que este elemento es de acceso pblico y por lo tanto se pueden operar desde cualquier instancia del sistema. Por 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 smbolo #.

Cuando se usa una clase, es probable que se desee caractersticas de otras clases y tambin permitir que otras clases ms especficas hereden caractersticas de ella. Tambin se puede especificar que una clase no puede tener hijos, a este elemento se le llama hoja y se especifica escribiendo la propiedad leaf bajo el nombre de la clase. Otra caracterstica de las clases es cuando esta no tiene padres, este tipo de clases se denomina raz y se denota escribiendo debajo del nombre de la clase root. Podemos observar el siguiente ejemplo de notacin:

28

Factura(root) Registrar venta() Registrar proveedor() Registrar cliente() Informes()

Clase padre principal

Facturacomestibles

Facturainmuebles

Clases hijos
Mostrarusuario() Mostrarusuario() (leaf)

Clases hoja, no puede tener mas hijos Figura 20.

Las clases tienen muchas operaciones entre s, las que se heredan entre clases se denominan polimrficas esto ocurre cuando los objetos han ejecutado una operacin que esta definida en la clase que los contiene pero con la diferencia de que la operacin 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, tambin hay que modelar cmo se relacionan entre s estos elementos, las relaciones de dependencia, las generalizaciones y las asociaciones son los tres bloques de construccin de relaciones ms importantes de UML. Observemos el comportamiento de estas relaciones.

Relaciones de Dependencia: Una dependencia es una relacin de uso, la cual especifica que un cambio en la especificacin de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente a la inversa. Grficamente, una dependencia se representa

29

como una lnea continua dirigida hacia el elemento del que se depende. Las dependencias se deben aplicar cuando se quiera representar que un elemento utiliza a otro Relaciones de Generalizacin Una generalizacin es una relacin entre un elemento (superclase o padre) y un tipo 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 relacin de generalizacin del hijo al padre, el hijo ventaconmarco heredar la estructura y comportamiento del padre ventana, en una generalizacin la instancia del hijo pueden usarse donde quiera que se puedan usar las instancias del padre.

La generalizacin se manifiesta en la herencia simple que a veces es suficiente en a mayora de las veces, aunque, la herencia mltiple es mas adecuada, grficamente 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 ElementoAsegurable y CuentaBancaria, es un tipo de activo as como un ElementoConInteres y un ElementoAsegurable

30

Relaciones de Asociacin

Una asociacin es una relacin estructural que especifica que los objetos de un elemento se conectan a los objetos de otro, por ejemplo, una clase biblioteca podra tener una asociacin uno a muchos con clase libro, indicando que cada instanci de libro pertenece a una instancia de biblioteca, adems, dado un libro, se puede encontrar su biblioteca, y dando una biblioteca se puede navegar hacia todos los libros, grficamente, un asociaciones se representa con una lnea continua entre la misma o diferentes clases. Las relaciones se utilizan para mostrar relaciones estructurales.

En la siguiente asociacin simple se muestra como se hace la navegacin entre objetos por ejemplo al modelar una asociacin entre 2 objetos como Usuario y Clave se tiene que un dado un Usuario se puede encontrar las correspondientes Claves, pero dada una Clave no se podra identificar al Usuario correspondiente. Usuario 1 * Clave

La lnea representa una asociacin y la fecha indica la direccin del recorrido 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 construccin de interfaces permite tambin el manejo de libreras estndar reutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sin necesidad de afectar el funcionamiento general del sistema. Se entiendo como interfaz como una coleccin de operaciones que sirven para especificar un servicio de una clase o un componente.

31

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

Nombre elemental IOrtografa

Nombre de camino Red::IRouter 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 mtodos, pero estas pueden contener cualquier nmero de operaciones. La siguiente notacin hace referencia a una interfaz donde se manifiesta de manera grfica su nombre y operaciones a diferencia de la notacin del crculo presentada anteriormente. Proporciona un mecanismo para modelar la conformidad esttica y dinmica de una abstraccin con una interfaz en un contexto especfico

Nombre de la interfaz

<<interface>> FlujoURL Abrirconexion() EstablecerURL() Operaciones de la interfaz

Figura 24. Notese en la representacin el nombre <<interface>> como identificador de la interfase definida.

32

Las relaciones entre interfaces se realizan de la misma manera como se relacionan con las clases puesto que las relaciones son del mismo tipo, para recordar: relaciones de generalizacin, relaciones de asociacin y relaciones de dependencia. Como se mostr anteriormente las interfaces se pueden denotar mostrndose como un crculo o con sus operaciones, dentro de un diagrama de interaccin entre clases los resultados para mostrar las relaciones entre las clases a travs de las interfaces se expresa de la siguiente manera:

Figura 25. La primera forma es la sencilla en la cual se muestra la conexin de dos clases a travs de un circulo que representa la interfaz con la cual se comunican dichas clases, la segunda forma muestra de manera mas detallada las operaciones con las cuales interactan las clases definidas antes y despus de la interfase, ntese como se representan las relaciones de dependencia de la misma forma como se mostr en las relaciones entre clases.

33

Tipos y roles Un rol representa un comportamiento de una entidad que participa en un contexto particular, por ejemplo consideremos una instancia de una clase denominada profesor, este profesor puede ser de matemticas, sociales, informtica, fsica, etc, para cada rol generado de clase profesor, se deduce que las propiedades cada rol son exclusivas y en ningn momento pueden tomar propiedades de un rol que no le corresponda. Para representar el rol que representa un objeto dentro de una relacin de clases en notacin UML se tiene por ejemplo:

Figura 26.

Figura 27.

La figura anterior representa una asociacin de clases con una interfaz especifica, como se ve existe una asociacin de entre las clases persona y empresa en cuyp contexto persona juega un rol llamado e, cuyo tipo es empleado

34

1.2.9 Paquetes e Instancias

Un paquete es un mecanismo de prposito 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 dems.

cliente

Nombre del Paquete

+FormualarioDePedido +FormularioDeSeguimiento -Pedido

Elementos contenidos en el paquete 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 manifestacin concreta de una abstraccin a la que se puede aplicar un conjunto de operaciones y que posee un estado que almacena el efecto de las operaciones. grficamente una instancia se representa subrayando su nombre
teclasPulsadas: Colas

Instancia con nombre

: Marco

Instancia annima

agente:

Figura 29.

Instancia hurfana

35

Las instancias no aparecen aisladas, casi siempre estn ligadas a una abstraccin. La mayora de las instancias que se modelan en UML sern instancias de clases (llamadas objetos), aunque se pueden tener instancias de otros elementos, como componentes, nodos, casos de usos y asociaciones.

En sentido general, un objeto es algo que ocupa espacio en el mundo real o conceptual y al que se le pueden hacer cosas. Por ejemplo, una instancia de un nodo es normalmente un computador que se encuentra fsicamente en una habitacin; una instancia de un componente ocupa algo de espacio en el sistema de archivos; una instancia de un registro de un cliente consume algo de memoria fsica, anlogamente, una instancia de un billete de avin es algo sobre lo que se pueden hacer clculos. 1.2.10. Herencia y polimorfismo

Polimorfismo

Una de las caractersticas fundamentales de la OOP es el polimorfsmo, que no es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un objeto STRING significara concatenacin ("pegar" strings uno seguido al otro)

Herencia

En programacin orientada a objetos, la herencia es un mecanismo que hace posible que una clase herede todo el comportamiento y atributos de otra clase; a travs de la herencia, una clase tiene inmediatamente toda la funcionalidad de una clase existente, debido a esto, las nuevas clases se pueden crear indicando nicamente en que se diferencian de la clase existente, es decir, que toma la definicin previa de la cual es subclase, y que solo se le agrega caractersticas especiales que la difieren de la clase de la cual procede. La relacin de herencia se representa mediante un tringulo en el extremo de la relacin que corresponde a la clase ms general o clase padre.

36

SEGUNDA UNIDAD CARACTERISTICAS DEL MODELADO UML

37

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 estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos dinmicos 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 slo la parte esttica de una interaccin, consistiendo en los objetos que colaboraran pero sin ninguno de los mensajes intercambiados entre ellos.

Los diagramas de objetos se emplean para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estticas,

En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representada por un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.

38

Figura 30. En la figura anterior se representa un conjunto de objetos extrados de la implementacin de un robot. Como indica la figura, un objeto representa al propio robot, (r es una instancia de Robot), y r se encuentra actualmente en estado movimiento. Este objeto tiene un enlace con m, una instancia de Mundo, que representa una abstraccin del modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un conjunto de instancias de Elemento, que representan entidades que el robot ha identificado, pero an no ha asignado en su vista del mundo.

En este instante, m est enlazado a dos instancias de 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 ms configuraciones posibles de

39

estos objetos. Por lo tanto, al utilizar diagramas de objetos slo se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototpicos.

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, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Figura 31. Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.

Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

40

Caso de Uso:

Figura 32. Es una operacin o tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.

Relaciones:

Las relaciones se explicaron de manera 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.

Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple. Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.

41

Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda clsica de usar o heredar. Ejemplo: Como ejemplo esta el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar lo siguiente:

Registrar el nmero de 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 botn de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos temes han sido retornados en el da. b. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: a. Informacin asociada a temes. b. Dar una alarma en el caso de que: Item se atora. No hay ms papel.

42

Como una primera aproximacin identificamos a los actores que interactan con el sistema:

Figura 33. Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la informacin de un Item o bien puede Imprimir un informe:

Figura 34. Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Figura 35.

43

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador.

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

Figura 37.

44

2.1.3. Diagramas de Interaccin Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de un sistema, lo que conlleva modelar instancias concretas o prototpicas de clases interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de objetos colaboran para proveer un comportamiento. En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboracin. Diagrama de Secuencia Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
Objetos

c : Cliente

p : ProxyODBC

<<create>>

:Transaccin
establecerValores(d,3,4)

establecerAcciones(a,d,o) Tiempo

establecerValores(a,CO) xito Lnea de vida <<destroy>> Foco de control

Figura 38.

45

Los diagramas de secuencia tienen 2 caractersticas que los distinguen de los diagramas de colaboracin, en primer lugar est la lnea de vida de un objeto que es la lnea discontinua vertical que representa la existencia de un objeto a lo largo de un periodo de tiempo. La mayora de los objetos que aparecen en un diagrama de secuencia existirn mientras dure la interaccin, los objetos se colocan en la parte superior del diagrama con sus lneas de vida dibujadas de arriba hasta abajo. Pueden crearse objetos durante la interaccin, sus lneas de vida comienzan con la recepcin de mensajes estereotipado como create. Los objetos pueden destruirse durante la interaccin, sus lneas de vida acaban con la recepcin del mensaje estereotipado como destroy, adems, se muestra la seal visual de una gran X que marca el final de sus vidas.

Diagrama de Colaboracin

Un diagrama de colaboracin destaca la organizacin de los objetos que participan en una interaccin, un diagrama de colaboracin se construye colocando en primer lugar los objetos que participan en la colaboracin como nodos de un grafo. A continuacin se representa los enlaces que conectan esos objetos como arcos de grafo, por ltimo, estos enlaces se adorna con los mensajes que envan y reciben los objetos, esto da la lector una seal visual clara del flujo de control en el contexto de la organizacin estructural de los objetos que colaboran c : Cliente
1: <<create>> 2: establecerAcciones(a,d,o) 3: <<destroy>>

Objeto

enlace <<local>>

mensaje <<global>>
2.1:establecerValores(d,3,4) 2.2: establecerValores(a,Co)

:Transaccin

P : ProxyODBC

Figura 39. Los diagramas colaboracin tienen dos caractersticas que los distinguen de los diagramas de secuencia, el primero para indicar cmo se enlaza un objeto a otro, se puede asociar un objeto al extremo 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 ordenacin temporal de los mensajes, se

46

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 ejecucin general entre los objetos que se esta ejecutando en un momento dado dentro de una mquina de estados, el resultado de un actividad es una accin que producen un cambio en el estado del sistema o la devolucin de un valor. Las acciones incluyen llamadas a otras operaciones, envo de seales, creacin o destruccin de objetos o simples clculos. Grficamente un diagrama de actividades ser un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cmo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecucin de un proceso ms complejo. Por este motivo, en un diagrama de actividades aparecern acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido.

Contenido del diagrama de actividades

Bsicamente un diagrama de actividades contiene: Estados de actividad Estados de accin Transiciones Objetos

Estados de actividad y estados de accin

La representacin de ambos es un rectngulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una accin. La forma de expresar tanto una actividad como una accin, no queda impuesta por UML, se podra utilizar lenguaje natural, una especificacin formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: Un estado que represente una accin es atmico, lo que significa que su ejecucin se puede considerar instantnea y no puede ser interrumpida En la siguiente figura, podemos ver ejemplos de estados de accin.

47

Figura 40.

En cambio un estado de actividad, s puede descomponerse en ms subactividades representadas a travs de otros diagramas de actividades. Adems estos estados s pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestin, as como definicin de submquinas, como podemos ver en la figura siguiente ProcesarFactura(Fact) Entry / SacarPrimeraFactura(Fact) Figura 41. Transiciones

Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de accin. Esta transicin se produce como resultado de la finalizacin del estado del que parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y terminar en algn momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo siguiente

Figura 41.

Estado de Accin

48

Bifurcaciones

Un flujo de control no tiene porqu ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcacin se utilizar como smbolo el rombo. Dicha bifurcacin tendr una transicin de entrada y dos o ms de salida. En cada transicin de salida se colocar una expresin booleana que ser evaluada una vez al llegar a la bifurcacin, las guardas de la bifurcacin han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecucin del flujo de control quedara interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transicin obligada a un determinado estado cuando el resto de guardas han fallado. Veamos un ejemplo de bifurcacin. Bifurcacin secuencial

Figura 42. Divisin y unin

No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en los que se requieren tareas concurrentes. UML representa grficamente el proceso de divisin, que representa la concurrencia, y el momento de la unin de nuevo al flujo de control secuencial, por una lnea horizontal ancha. Podemos ver cmo se representa grficamente.

Figura 43.

49

Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente til dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. Cada calle representa a la parte de la organizacin responsable de las actividades que aparecen en esa calle. Grficamente quedara como se muestra a continuacin

clientes
Solic Producto

ventas

almacn

Procesar Pedido Extraer Pedido

Enviar Pedido

Recibir Pedido

Fact. Cliente

Pagar Factura Cerrar Pedido

Figura 44.

50

2.2. Modelado dinmico

2.2.1 Eventos y seales

Un evento es la especificacin de un acontecimiento significativo que ocupa lugar en el tiempo y en el espacio. En el contexto de la mquinas de estado, evento es la aparicin de un estmulo que puede disparar una transicin estado. Un seal es un tipo de evento que representa la especificacin de estmulo asncrono que es transmitido entre instancias. Seales

un un de un

Una seal representa un objeto con nombre que es enviado (lanzado) asncronamente por un objeto y recibido(capturado) por otro. El tipo ms comn de seal interna que se presenta dentro de los lenguajes de programacin son las excepciones.

Una seal puede enviarse como la accin de una transicin de estado en una mquina de estados, o como el envo de un mensaje en una interaccin.. En UML, la relacin entre una operacin y los eventos que puede enviar se modela con realcion de dependencia, estereotipada como send.

Las seales y las excepciones se modelan como clases estereotipadas, se puede utilizar una dependencia, estereotipada como send para indicar que la operacin enva una seal particular.

Seal

AgenteDeMovimiento Posicin Velocidad


<<send>>

<<signal>> colisin fuerza : Float

moverA()

parmetros

Figura 44.

51

Eventos

Un evento de llamada representa una invocacin de una operacin, un evento puede disparar una transicin de estado de una mquina de estados. Cuando un objeto invoca una operacin sobre otro objeto que tiene una mquina de estados, el control pasa del emisor al receptor, el evento dispara la transicin, la operacin acaba, el receptor pasa a un nuevo estado y el control regresa al emisor. Grficamente se muestra al evento con sus parmetros, como el disparador de una transicin de estado.
evento

Manual

iniciarpilotoAutomtico(normal)

Automtico

parmetro

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 expresin que se evala para producir algn periodo de tiempo.

Un evento de cambio es un evento que representa un cambio en el estado o e cumplimiento de alguna condicin, se modela con la palabra when seguida de alguna expresin booleana.

when (11:49 PM) /AutoTest()


alter (2 Segundos) /cortarConexin()

Inactivo

Activo

Evento de cambio

Evento de tiempo

Figura 46.

52

2.3.2 Mquinas de Estado

Una mquina 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 condicin o situacin en la vida de un objeto durante la cual satisface alguna condicin, realiza una actividad o espera algn evento. Un evento es la especificacin de un aconecimietno significativo que ocupa un lugar en el tiempo y el espacio, es la estimulacin que puede disparar una transicin de estados

Un transicin es una relacin entre dos estados que indica que un objeto que est en el primer estado realizar ciertas acciones y entrar el segundo estado cuando ocurra un evento especfico y se satisfagan unas condiciones especficas y una actividad es una ejecucin no atmica en curso, dentro de una mquina de estados.

Estados

Un estado es una condcion o situacin enla vida de un objeto durante la cual satisface alguna condicin, realiza una actividad o espera un evento. Un objeto puede estar en cualquier estado durante una cantidad de tiempo determinado, por ejemplo un calentador de agua puede estar en cualquiera de los cuatro estados: inactivo, en preparacin (esperando alcanzar la temperatura adecuada), activo(cuando el calentador alcanza la temperatura ideal para calentar el agua), y pagado. Un estado tiene varias partes, nombre, acciones de entrada salida, transiciones internas, subastados y eventos diferidos. Como se muestra a continuacin un estado se representa con un rectngulo con las esquinas redondeadas.

Estado inicial

apagar

Estado final

Inactivo

teclaPulsada Terminado

Funcionando

nombre

nombre estado

Figura 47.

53

Como se observa en la grafica anterior en la mquina 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 mquina de estados o el subestado. En segundo lugar, el estado final, que indica la ejecucin de la mquina de estado o del estado que lo contiene ha finalizado

Transiciones

Una transicin es una relacin 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 especfico y se satisfagan unas condiciones especficas, cuando se produce este cambio de estado, se dice que la transicin se ha disparado, hasta que se dispara la transicin se dice que el objeto est en el estado origen, despus de dispararse se dice que esta en el estado destino.
Evento de tiempo Envo de seal Evento de disparo

Transicin sin disparador alter (2 Segundos) /send c.estaActivo autotransicin ruido

Inactivo

Inactivo

Inactivo

objetoEn(p)[representaAmenaza]/ t.aadirObjeto(p)

Inactivo

contactar

Inactivo

accin

Evento de disparo con parmetros condicion de gurda

Figura 48.

Una transicin tiene cinco partes, estado origen, evento disparado, condicin de guarda, accin y estado de destino; una transicin se representa con una lnea continua dirigida desde el estado origen hacia el destino y una autotransicin es una transicin cuyos estados origen y destino son los mimos

54

2.4.3 Tiempo y Espacio

Una marca de tiempo denota el instante en el que ocurre un evento, grficamente, una marca de tiempo es una expresin obtenida a partir del nombre dado al mensaje; una expresin de tiempo es una expresin que al evaluarse genera un valor de tiempo absoluto o relativo. Una restriccin de tiempo se representa como cualquiera otra restriccin, es decir, una cadena de texto entre llaves y normalmente conectada a un electo mediante una relacin de dependencia. La localizacin es la asignacin de un componente de un nodo. Grficamente, la localizacin se representa como un valor etiquetado, es decir, una cadena de texto entra llaves colocada debajo del nombre del elemento, o mediante la inclusin de componentes dentro de nodos.
Restriccin de tiempo {cada 1ms} c1 : notasDePrueva

c : ControladorMIDI

: ColeccinDeNotas
{executeTime <10 ms} c2 : notasDePrueba()

Restriccin de tiempo

n: Nota
c3 : a adir(k)

b: BufferDeEventosMIDI

t : TransmisionMIDI
t1 : quitar() {cada 1 ms}

Figura 49.

Restriccin de tiempo

En el grfico anterior se observa la manera como se representa el tiempo y el siguiente grfico se muestra la localizacin

Figura 50.

Localizacin por inclusin

55 t : TransmisionMIDI {location=Enrutador}

Valor etiquetado de localizacin

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 continuacin con todos sus componentes

Estado inicial

Inactivo
enviarFax

sonando Transicin sin disparador colgar evento entry/descolgar error/imprimirError exit/desconectar verificacinOK evento

Conectando

cabeceraOK

Procesando

Transmisin

Limpiando

estado accin accin Estado compuesto

Figura 51.

56

2.3. Modelado Arquitectnico

2.3.1. Componentes, despliegue, colaboraciones y patrones Componentes Un componente es una parte fsica y reemplazable de un sistema que conforma un conjunto de interfaces. Grficamente, un componente se representa como un rectngulo con pestaas, un componente debe tener un nombre que lo distinga del resto de componentes. El nombre de un componente puede ser simple o de camino que consta del nombre del componente precedido del nombre del paquete en el que se encuentra, usualmente un componente se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la siguiente figura
Agentefraudes.dll
Componente con nombre simple

agenteFraudes

PoliticaFraudes

BusquedaDePatrones

clases

Figura 52.
Interfaz
Imagen.java ObservadorDeImagen Imagen.java

Figura 53.
Relacin de dependencia realizacin

57

Despliegue

Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que generalmente tiene alguna memoria y a menudo capacidad de procesamiento, grficamente un nodo se representa como un cubo. . El nombre de un componente puede ser simple o de camino que consta del nombre del componente precedido del nombre del paquete en el que se encuentra, usualmente un nodo se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la siguiente figura nodo con nombre simple

ventas

pos.exe

Contactos.exe

componentes

Figura 54. Colaboraciones

Una colaboracin es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Una colaboracin es tambin la especificacin de cmo un elemento tal como un clasificador o un operacin, es realizado mediante un conjunto de clasificadores y asociaciones que juegan roles especficos utilizados de una forma especfica, grficamente, una colaboracin se representa como una elipse con borde discontinua. El nombre de una colaboracin puede ser simple o de camino que consta del nombre de la colaboracin precedido del nombre del paquete en el que se encuentra, usualmente un nodo se dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o con algn comportamiento que indique sus detalles. Como se muestra en la

58

siguiente figura

Nombre

Paso de mensajes entre nodos

Figura 55. Patrones

Un patrn es una solucin comn a un problema comn en un contexto dado. Los patrones ayudan a visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Hay dos tipos de patrones, patrones de diseo(Mecanismos) y frameworks.

Mecanismos

Un mecanismo simplemente muestra un conjunto de abstracciones que colaboran entre si par llevar a cabo algn comportamiento comn, estos mecanismo se muestran como colaboraciones simples, ya que solamente dan el nombre a una sociedad de clases.

frameworks

<<framework>> recepcin de pedidos

facturacin

comprobacin Figura 56. mecanismos 59

Los mecanismos pueden nombrar una plantilla formada por un conjunto de de abstracciones que colaboran entre s para llevar a cabo algn comportamiento comn, se representan como colaboraciones parametrizadas que se muestran de forma parecida a las clases plantilla, observe la siguiente figura

rol

platilla

ColaTares ligadura BarraDesplazamiento

Sujeto

Sujeto Observador

Observador Observador colaboraciones rol Figura 57.

Frameworks

Un frameworks es un patrn arquitectnico que proporciona una plantilla extensible para aplicaciones dentro de un dominio. La siguiente figura ilustra un frameworks, llamado AdministradorCiclo entre otras cosas, este frameworks incluye una colaboracin EventosComunes que contiene un conjunto de clases evento, junto con un mecanismo GestorDeEventos para procesar estos eventos de forma cclica. Un cliente que utilice este frameworks tal como un Marcapasos podra construir sobre las abtracciones en EventosComunes creando subclases y tambin podra emplear una instancia del mecanismo GestorDeEventos

60

frameworks

ligaduras

Pacificador

<<frameworks>> AdministradorCiclico Cliente Gestor

GestorDeEvento s EventosComunes

colaboraciones 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, tambin puede contener paquetes utilizados para agrupar elementos del modelo.

Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software, sean stos componentes de cdigo fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideracin los requisitos relacionados con la facilidad de desarrollo, la gestin del software, la reutilizacin, y las restricciones impuestas por los lenguajes de programacin y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes sern componentes y paquetes. Dado que los diagramas de componentes muestran los componentes software que constituyen una parte reusable, sus interfaces, y su interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama

61

de clases a gran escala. Cada componente en el diagrama debe ser documentado con un diagrama de componentes ms detallado, un diagrama de clases, o un diagrama de casos de uso.

Un paquete en un diagrama de componentes representa un divisin fsica del sistema. Los paquetes se organizan en una jerarqua de capas donde cada capa tiene una interfaz bien definida. Un ejemplo tpico de una jerarqua en capas de este tipo es: Interfaz de usuario; Paquetes especficos de la aplicacin; Paquetes reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo.

Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilacin). Puede mostrar tambin que un componente software contiene una interfaz, es decir, la soporta. Un ejemplo se muestra a continuacin

find.html pgina find.exe

nateng.dll componente biblioteca 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 tipologa de procesadores y dispositivos sobre los que reejecuta el software. Los diagramas de despliegue se utilizan para visualizar los aspectos estticos de estos nodo fsicos y sus relaciones y para especificar sus detalles para la construccin, como se muestra a continuacin

62

nodo modem

<<procesadorr>> servidor cache

<<procesadorr>> servidor cache

nodo

conexin

<<procesadorr>> servidor principal

<<procesadorr>> servidor

<<procesadorr>> servidor

<<procesadorr>> servidor

Figura 61. Un diagrama de despliegue es un diagrama que muestra la configuracin de los nodos que participan en la ejecucin y de los componentes que residen en ellos, grficamente, un diagrama de despliegue es una coleccin de nodos y arcos.

2.3.4. Sistemas y modelos

UML proporciona una representacin grfica de los sistemas y los subsistemas, esta notacin permite visualizar la descompensacin de un sistema en subsistemas ms pequeos, grficamente, un sistema y un subsistema se representa con el smbolo de un paquete estereotipado. Observemos su representacin a continuacin

63

<<system>> sistema de ventas

<<subsystem>> subsistema de servicio al cliente

<<subsystem>> subsistema de gestin de almacn

<<subsystem>> subsistema de gestin de produccin

Figura 62. Un sistema posiblemente descompuesto en una coleccin de subsistemas, es un conjunto de elementos organizados para lograr un propsito y descrito por un conjunto de modelos. Un subsistema es una agrupacin de elementos, algunos de los cuales constituyen una especificacin del comportamiento ofrecido por otros elementos.

64

TERCERA UNIDAD DESARROLLO ORIENTADO A OBJETOS CON UML

65

3. DESARROLLO ORIENTADO A OBJETOS CON UML Cuando se va a construir un sistema software es necesario conocer un lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solucin sea cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de ambos, entonces la construccin de sistemas software va a poder 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 notacin que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estndar de facto en cuanto a notacin orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentacin, pues es de esperar que cualquier desarrollador versado en orientacin a objetos conozca y use UML (o se est planteando su uso).

Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando as una visin completa y coherente de la produccin de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. As no se pierde de vista la motivacin principal que debera estar en cualquier proceso de construccin de software: el resolver una necesidad del usuario/cliente.

Visin 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 tamao medio-alto. El proceso est formado por una serie de actividades y subactividades, cuya realizacin se va repitiendo en el tiempo aplicadas a distintos elementos.

66

En este apartado se va a presentar una visin general para poder tener una idea del proceso a alto nivel, y ms adelante se vern los pasos que componen cada fase. Las tres fases al nivel ms alto son las siguientes:

Planificacin y Especificacin de Requisitos: Planificacin, definicin de requisitos, construccin de prototipos, etc. Construccin: La construccin del sistema. Las fases dentro de esta etapa son las siguientes: - Diseo de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. - Diseo de Bajo Nivel: El sistema se especifica en detalle, describiendo cmo va a funcionar internamente para satisfacer lo especificado en el Diseo de Alto Nivel. - Implementacin: Se lleva lo especificado en el Diseo de Bajo Nivel a un lenguaje de programacin. - Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificacin y Especificacin de Requisitos. - Instalacin: La puesta en marcha del sistema en el entorno previsto de uso. De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del diseo de alto y al de bajo nivel, para llegar a la implementacin y pruebas. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximacin se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente

67

3.2. Fase de Planificacin y Especificacin de Requisitos

Esta fase se corresponde con la Especificacin de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente.

3.2.1 Actividades Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigacin Preliminar. Definir los Requisitos. Registrar Trminos en el Glosario. (continuado en posteriores fases) Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) Refinar el Plan.

El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede tambin en las actividades de las fases de diseo, que se vern ms adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificacin de proyectos software, como las correspondientes a creacin de planes e informes preliminares.

3.2.2. Requisitos

El formato del documento de Especificacin de Requisitos no est definido en UML, pero se ha incluido este punto para resaltar que la actividad de definicin de

68

requisitos es un paso clave en la creacin de cualquier producto software. Para entender y describir los requisitos la tcnica de casos de uso constituye una valiosa ayuda. Casos de Uso

Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales.

Ntese que UML no define un formato para describir un caso de uso. Tan slo define la manera de representar la relacin entre actores y casos de uso en un diagrama. Sin embargo, un caso de uso individual no es un diagrama, es un documento de texto. En la siguiente seccin se define el formato textual para la descripcin de un caso de uso que se va a utilizar en este documento..

Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica de acciones e interacciones entre los actores y el sistema. Ms adelante se ver la representacin de los escenarios correspondientes a un caso de uso por medio de Diagramas de Secuencia.

En un primer momento interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con ms detalle se usa el formato expandido.

Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est usando un cajero automtico: - Caso de Uso: Realizar Reintegro - Actores: Cliente - Tipo: primario - Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.

69

En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se condensa en dos o tres frases. Es til para comprender el mbito y el grado de complejidad del sistema.

Casos de Uso Expandidos

Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencian al resto, se describen a un nivel ms detallado: en el formato expandido.

La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve en el siguiente ejemplo:

- Caso de Uso: Realizar Reintegro - Actores: Cliente (iniciador) - Propsito: Realizar una operacin de reintegro de una cuenta del banco - Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. -Tipo: primario y esencial -Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. Pide la clave de identificacin. Introduce la clave. Presenta las opciones de operaciones disponibles. Selecciona la operacin de Reintegro. Pide la cantidad a retirar. Introduce la cantidad requerida. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. 1. 2. 3. 4. 5. 6. 7. 8.

70

Cursos Alternativas: Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin. Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operacin.

Identificacin de Casos de Uso

La identificacin de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en el uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo.

Como gua para la identificacin inicial de casos de uso hay dos mtodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organizacin. 2. Para cada actor, identificar los procesos que inicia o en los que participa.

b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Ejemplos de casos de uso: Pedir un producto. Matricularse en un curso de la facultad. Comprobar la ortografa de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet Identificacin de los Lmites del Sistema En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para que los casos de uso tengan un significado completo es necesario que el sistema est definido con precisin.

71

Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son: El hardware y software de un sistema informtico. Un departamento de una organizacin. Una organizacin entera. Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere construir.

Tipos de Casos de Uso

a) Segn su Importancia Para establecer una primera aproximacin a la priorizacin de casos de uso que identifiquemos los vamos a distinguir entre: Primarios: Representan los procesos principales, los ms comunes, como Realizar Reintegro en el caso del cajero automtico. Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Aadir Nueva Operacin. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin.

Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas.

72

Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico tenemos la siguiente descripcin del Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 2. Pide el PIN (Personal Identification Number). 3. Introduce el PIN a travs del teclado numrico. 4. Presenta las opciones de operaciones disponibles. 5. etc. En principio, los casos de uso reales deberan ser creados en la fase de Diseo de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el diseo es un continuo, y una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros.

Consejos Relativos a Casos de Uso

Nombre: El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artculos o Realizar Pedido. Alternativas equiprobables: 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 Tpico de Eventos con secciones adicionales.

As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner opciones que dirigen el caso de uso a una seccin que se detalla al final del Curso Un caso Tpico de Eventos, en la siguiente forma: - Curso Tpico de Eventos: - Seccin: Principal Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando Actor llega al sistema.

73

2. 3. 4. 5.

Pide la operacin a realizar. Escoge la operacin A. Presenta las opciones de pago. Selecciona el tipo de pago: Si se paga al contado ver seccin Pago al Contado. O si se paga con tarjeta ver seccin Pago con Tarjeta. 6. Genera recibo. 7. Recoge el recibo y se va. Cursos Alternativos: Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin.

Seccin: Pago al Contado Accin 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: Lnea 3: No hay cambio suficiente. Se cancela la operacin.

3.2.3. Construccin del Modelo de Casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificacin y especificacin de Requisitos se siguen los siguientes pasos: 1. Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los actores y los casos de uso. 2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales. 3. Se dibuja el Diagrama de Casos de Uso. 4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el Diagrama de Casos de Uso. 5. Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definicin en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez.

74

6. Se crean casos de uso reales slo cuando: Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin).

3.2.4. Planificacin de Casos de Uso segn Ciclos de Desarrollo La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a tomar basndose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementacin de uno o ms casos de uso, o versiones simplificadas de casos de uso. Se asigna una versin simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo

Figura 63. Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos segn prioridad. Las caractersticas de un caso de uso especfico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes:

75

Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva o arriesgada. Representa un proceso de gran importancia en la lnea de negocio. Supone directamente un aumento de beneficios o una disminucin de costos. Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin numrica de cada uno de estos puntos, para conseguir una puntuacin total aplicando pesos a cada apartado.

Caso de Uso de Inicializacin Prcticamente todos los sistemas van a tener un caso de uso de Inicializacin. Aunque puede ser que no tenga una prioridad alta en la clasificacin realizada segn el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las necesidades de inicializacin de los casos de uso que se tratan en dicho ciclo. As se tiene un sistema en cada ciclo de desarrollo que puede funcionar. 3.3. Diseo de Alto Nivel

En la fase de Diseo de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se est tratando. Se intenta llegar a una buena comprensin del problema por parte del equipo de desarrollo, sin entrar en cmo va a ser la solucin en cuanto a detalles de implementacin.

Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseo de Alto Nivel hay una serie de actividades de planificacin. Estas actividades consisten en actualizar los modelos que se tengan segn lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseo de Alto Nivel.

76

En esta fase se trabaja con los modelos de Diseo de Alto Nivel construidos en la fase anterior, amplindolos con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual.

3.3.1 Actividades

Las actividades de la fase de Diseo de Alto Nivel son las siguientes: 1. 2. 3. 4. 5. 6. 7. Definir Casos de Uso Esenciales en formato expandido. (si no estn definidos ) Refinar los Diagramas de Casos de Uso. Refinar el Modelo Conceptual. Refinar el Glosario. (continuado en posteriores fases) Definir los Diagramas de Secuencia del Sistema. Definir Contratos de Operacin. Definir Diagramas de Estados. (opcional)

3.3.2. Modelo Conceptual

Una parte de la investigacin sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Esttica de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representacin de conceptos del mundo real, no de componentes software. El objetivo de la creacin de un Modelo Conceptual es aumentar la comprensin del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algn concepto importante.

Identificacin de Conceptos

Para identificar conceptos hay que basarse en el documento de especificacin de requisitos y en el conocimiento general acerca del dominio del problema. Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, ms concretamente, en la descripcin de los casos de uso. No es un mtodo infalible, pero puede servir de gua para empezar.

77

Para poner nombre a los conceptos se puede usar la analoga con el cartgrafo, resumida en los siguientes tres puntos: Usar los nombres existentes en el territorio: hay que usar el vocabulario del dominio para nombrar conceptos y atributos. Excluir caractersticas irrelevantes: al igual que el cartgrafo elimina caractersticas no relevantes segn la finalidad del mapa (por ejemplo datos de poblacin en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos. No aadir cosas que no estn ah: si algo no pertenece al dominio del problema no se aade al modelo.

Creacin del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: 1. Hacer una lista de conceptos candidato usando la Lista de Categoras de Conceptos y la bsqueda de sustantivos relacionados con los requisitos en consideracin en este ciclo. 2. Representarlos en un diagrama. 3. Aadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. 4. Aadir los atributos necesarios para contener toda la informacin que se necesite conocer de cada concepto. Identificacin de Asociaciones

Una asociacin es una relacin entre conceptos que indica una conexin con sentido y que es de inters en el conjunto de casos de uso que se est tratando. Se incluyen en el modelo las asociaciones siguientes: Asociaciones para las que el conocimiento de la relacin necesita mantenerse por un cierto perodo de tiempo (asociaciones necesita-conocer). Asociaciones derivadas de la Lista de Asociaciones

78

Identificacin de Atributos

Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de informacin de los casos de uso que se estn desarrollando en ese momento.

Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los tipos complejos deberan ser modelados como conceptos y ser relacionados mediante asociaciones, incluso cuando un valor es de un tipo simple es ms conveniente representarlo como concepto en las siguientes ocasiones cuando: Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el nombre de una persona, etc. Tiene operaciones asociadas, tales como validacin. Ejemplo: nmero nico de identificacin. Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin. Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesos, dlares o en euros. Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del desarrollo se va refinando segn se le aaden conceptos que se haban pasado por alto.

Glosario

En el glosario debe aparecer una descripcin textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigedad. Se ordena alfabticamente por trmino.

3.3.3. Diagramas de Secuencia del Sistema

Adems de investigar sobre los conceptos del sistema y su estructura, tambin es preciso investigar en el diseo de alto nivel sobre el comportamiento del sistema, visto ste como una caja negra. Una parte de la descripcin del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema.

En cada caso de uso se muestra una interaccin de actores con el sistema. En

79

esta interaccin los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avin, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operacin en el sistema de reservas.

Los casos de uso representan una interaccin genrica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecucin real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular.

Un Diagrama de Secuencia de Sistema se representa usando la notacin para diagramas de secuencia de UML estudiadas en la unidad 2 de este mdulo. En l se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas.

Para cada caso de uso que se est tratando se realiza un diagrama para el curso tpico de eventos, y adems se realiza un diagrama para los cursos alternativos de mayor inters. En la siguiente figura se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar Reintegro de un cajero automtico. Figura 64.

80

Construccin de un Diagrama de Secuencia del Sistema

Para construir un Diagrama de Secuencia del Sistema para el curso tpico de eventos de un caso de uso, se siguen los siguientes pasos: 1. Representar el sistema como un objeto con una lnea debajo. 2. Identificar los actores que directamente operan con el sistema, y dibujar una lnea para cada uno de ellos. 3. Partiendo del texto del curso tpico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama. 4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama. los eventos del sistema deberan expresarse en base a la nocin de operacin que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere finalizarOperacin a presionadaTeclaEnter, porque captura la finalidad de la operacin sin realizar compromisos en cuanto a la interfaz usada.

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 mdulo Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: Una clase software. Un concepto. Un caso de uso. En la fase de Diseo de Alto Nivel slo se hara para los dos ltimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseo. Puesto que el sistema entero puede ser representado por un concepto, tambin se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados. La utilidad de un Diagrama de Estados en esta fase reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automtico si se est en el transcurso de una operacin.

81

Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sera una combinacin de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es opcional.

3.4. Diseo de Bajo Nivel

En la fase de Diseo de Bajo Nivel se crea una solucin a nivel lgico para satisfacer los requisitos, basndose en el conocimiento reunido en la fase de Diseo de Alto Nivel. Los modelos ms importantes en esta fase son el Diagrama de Clases de Diseo y los Diagramas de Interaccin, que se realizan en paralelo y que definen los elementos que forman parte del sistema orientado a objetos que se va a construir (clases y objetos) y cmo colaboran entre s para realizar las funciones que se piden al sistema, segn stas se definieron en los contratos de operaciones del sistema.

3.4.1 Actividades

Las actividades que se realizan en la etapa de Diseo de Bajo Nivel son las siguientes: Definir los Casos de Uso Reales. Definir Informes e Interfaz de Usuario. Refinar la Arquitectura del Sistema. Definir los Diagramas de Interaccin. Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas de Interaccin). 6. Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura del Sistema no tiene por qu realizarse en la posicin 3, puede realizarse antes o despus. 1. 2. 3. 4. 5.

3.4.2. Casos de Uso Reales

Un Caso de Uso Real describe el diseo real del caso de uso segn una tecnologa concreta de entrada y de salida y su implementacin. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluir bocetos de las

82

ventanas y detalles de la interaccin a bajo nivel con los widgets (botn, lista seleccionable, campo editable, etc.) de la ventana. Como alternativa a la creacin de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementacin. 3.4.3. Diagramas de Interaccin

Los Diagramas de Interaccin muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato Hay dos clases de Diagramas de Interaccin: 1. Diagramas de Colaboracin. 2. Diagramas de Secuencia.

La notacin en UML para ambos es la definida unidad 2 de este mdulo, los Diagramas de Colaboracin tienen una mayor expresividad y mayor economa espacial (una interaccin compleja puede ser muy larga en un Diagrama de Secuencia), sin embargo en ellos la secuencia de interaccin entre objetos es ms difcil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma informacin, por lo que se puede usar cualquiera de los dos para expresar la interaccin entre los objetos del sistema.

La creacin de los Diagramas de Interaccin de un sistema es una de las actividades ms importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creacin de estos diagramas, por tanto, debera ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero.

Creacin de Diagramas de Interaccin

Para crear los Diagramas de Colaboracin o de Secuencia se pueden seguir los siguientes consejos: Crear un diagrama separado para cada operacin del sistema en desarrollo en el ciclo de desarrollo actual. Para cada evento del sistema, hacer un diagrama con l como mensaje inicial.

83

Usando los apartados de responsabilidades y de post-condiciones del contrato de operacin, y la descripcin del caso de uso como punto de partida, disear un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. Si el diagrama se complica, dividirlo en dos diagramas ms pequeos. Para ello se termina la secuencia de mensajes en un mensaje determinado, y en el segundo diagrama se comienza con el mensaje que termin el primero. Debe indicarse en el primer diagrama que el resto de la interaccin se detalla en el segundo. El comportamiento dinmico del sistema que se describe en un Diagrama de Interaccin debe ser acorde con la estructura esttica del sistema que se refleja en el Diagrama de Clases de Diseo. Es aconsejable realizar un Diagrama de Clases de Diseo borrador antes de comenzar con los Diagramas de Interaccin. La capacidad de realizar una buena asignacin de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo segn aumenta la experiencia en el desarrollo orientado a objetos.

Responsabilidad es como un contrato u obligacin de una clase o tipo. Las responsabilidades estn ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Bsicamente, estas responsabilidades pueden ser de tipo Conocer o de tipo Hacer: Conocer:

Conocer datos privados encapsulados. Conocer los objetos relacionados. Conocer las cosas que puede calcular o derivar. Hacer Hacer algo l mismo. Iniciar una accin en otros objetos. Controlar y coordinar actividades en otros objetos. Por ejemplo, puedo decir que un Recibo es responsable de calcular el total (tipo hacer), o que una Transaccin es responsable de saber su fecha (tipo conocer). Las responsabilidades de tipo conocer se pueden inferir normalmente del Modelo Conceptual y una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para satisfacer responsabilidades.

84

Diagrama de Clases de Diseo

Un Diagrama de Clases de Diseo muestra la especificacin para las clases software de una aplicacin. Incluye la siguiente informacin: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Mtodos. Navegabilidad. Dependencias.

A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra definiciones de entidades software ms que conceptos del mundo real. En la siguiente figura se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.

Figura 65.

85

Relaciones de Dependencia para Representar Visibilidad entre Clases Cuando una clase conoce a otra por un medio que no es a travs de un atributo (una asociacin con la navegabilidad adecuada), entonces es preciso indicar esta situacin por medio de una dependencia. Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se dice entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad ms directa es por medio de atributo, cuando hay una asociacin entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia:

- Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>. - Local: Cuando en un mtodo de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>.

- Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un mtodo de una clase B llama a un mtodo de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>.

No es necesario representar la relacin de dependencia entre clases que ya estn relacionadas por medio de una asociacin, que se trata de una dependencia ms fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qu elementos hay que revisar cuando se realiza un cambio en el diseo de un elemento del sistema.

Solitario: Caso Particular de Visibilidad global

El uso de variables globales no se aconseja por los efectos laterales que se

86

pueden presentar, pero hay un caso en el que s hay cierta globalidad: las clases que slo van a tener una instancia. Suele tratarse de clases que se han creado en el Diseo de Bajo Nivel, que no aparecan en el Modelo Conceptual.

Varias clases de nuestro sistema pueden querer llamar a los mtodos de la nica instancia de una clase de ese tipo, entonces s se considera que es beneficioso que se pueda acceder a esa instancia como un valor accesible de forma global. Una solucin elegante para este caso se implementa mediante un mtodo de clase para obtener esa nica instancia (los mtodos de clase los permiten algunos lenguajes orientados a objetos, por ejemplo Java), en vez de definirla directamente como una variable global. Para indicar que una clase slo va a tener una instancia, se etiqueta la clase con el estereotipo <>, y las relaciones de dependencia entre las clases que la usan y se etiquetan tambin <> en vez de <<>>.

A continuacin se muestra un ejemplo del cdigo en Java de una clase solitario: public class Solitario { // se define la instancia como atributo de clase (static) Solitario static instancia := null; // mtodo de clase que devuelve la instancia public static Solitario dar_instancia() { if (instancia = = null) { // si no est creada la instancia la crea instancia := new Solitario(); } return instancia; } ... // otros mtodos de la clase } Cuando otra clase quiere llamar a un mtodo de la instancia incluye el siguiente cdigo: variable Solitario; variable = Solitario.dar_instancia(); variable.mtodo(); // llamada al mtodo que necesitamos

87

3.4.4. Construccin Diagramas de Diseo

Normalmente se tiene una idea de un Diagrama de Clases, con una asignacin de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia: 1. Identificar todas las clases participantes en la solucin software. Esto se lleva a cabo analizando los Diagramas de Interaccin. 2. Representarlas en un diagrama de clases. 3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. 4. Aadir los mtodos, segn aparecen en los Diagramas de Interaccin. 5. Aadir informacin de tipo a los atributos y mtodos. 6. Aadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. 7. Aadir flechas de navegabilidad a las asociaciones para indicar la direccin de visibilidad de los atributos. 8. Aadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando segn se vayan completando los Diagramas de Interaccin correspondientes. No existe precedencia entre la realizacin del Diagrama de Clases de Diseo y los Diagramas de Interaccin. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero ms en el de clases y otras veces se trabaja primero ms en los de interaccin.

No todas las clases que aparecan en el Modelo Conceptual tienen por qu aparecer en el Diagrama de Diseo. De hecho, tan solo se incluirn aquellas clases que tengan inters en cuanto a que se les ha asignado algn tipo de responsabilidad en el diseo del sistema. No hay, por tanto, un transicin directa entre el Modelo Conceptual y el Diagrama de Clases de Diseo, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensin de un dominio, y el segundo en una solucin software.

En el Diagrama de Clases de Diseo se aaden los detalles referentes al lenguaje de programacin que se vaya a usar. Por ejemplo, los tipos de los atributos y parmetros se expresarn en el lenguaje de implementacin escogido.

88

Navegabilidad

La navegabilidad es una propiedad de un rol (un extremo de una asociacin) que indica que es posible navegar unidireccionalmente a travs de la asociacin, desde objetos de la clase origen a objetos de la clase destino. Como se vio en la unidad 2 y se representa en UML mediante una flecha.

La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementacin se traducir en la clase origen como un atributo que sea una referencia a la clase destino.

Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una funcin, deben ser necesarias, si no es as deben eliminarse. Las situaciones ms comunes en las que parece que se necesita definir una asociacin con navegabilidad de A a B son: A enva un mensaje a B. A crea una instancia B. A necesita mantener una conexin con B.

Visibilidad de Atributos y Mtodos

Los atributos y los mtodos deben tener una visibilidad asignada, que puede ser: + Visibilidad pblica. # Visibilidad protegida. - Visibilidad privada. Tambin puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementacin que sean necesarios para completar el Diagrama de Clases. Otros Aspectos en el Diseo del Sistema En los puntos anteriores se ha hablado de decisiones de diseo a un nivel de granularidad fina, con las clases y objetos como unidades de decisin. En el diseo de un sistema es necesario tambin tomar decisiones a un nivel ms alto sobre la descomposicin de un sistema en subsistemas y sobre la arquitectura del sistema (definicin de sistemas y subsistemas unidad 2). Esta parte del Diseo de

89

Bajo Nivel es lo que se denomina Diseo del Sistema. Estas decisiones no se toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Por tanto, no se va a entrar en este documento en cmo se realiza esta actividad.

3.5. Fases de Implementacin y Pruebas Una vez se tiene completo el Diagrama de Clases de Diseo, se pasa a la implementacin en el lenguaje de programacin elegido. El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en produccin si se ha planificado una instalacin gradual. Una vez se tiene una versin estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo.

90