Resumen Uml

INSTITUTO PLITECNICO NACIONAL ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
SECCION DE ESTUDIOS DE POSGRADO

PROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
MAESTRIA EN CIENCIAS EN INGENIERIA DE SISTEMAS
SISTEMAS DE INFORMACION ORIENTADOS A OBJETOS
EL LENGUAJE UNIFICADO DE MODELADO

RESUMEN DEL LIBRO
PROFESOR:
INSTITUTO POLITECNICO NACIONAL ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA SECCION DE ESTUDIOS DE POSGRADO PROGRAMA DE POSGRADO EN INGENIERIA DE SISTEMAS
ING. JUAN MANUEL MRQUEZ Marzo, 2003
EL LENGUAJE UNIFICADO DE MODELADO

RESUMEN DEL LIBRO
GRADY BOOCH JAMES RUMBAUGH IVAR JACOBSON
EDITORIAL ADISON WESLEY Resumen del libro realizado por los alumnos de Agosto a Diciembre 2002 Elvira Amaya Flores Carlos Estrada Espinosa Joel Manrique Ramirez
Pgina de 97
Ing. Juan Manuel Mrquez Vite
Contenido: Seccin 1 Introduccin.........................................................................................2 Captulo 1 Por qu modelamos..........................................................................3 Capitulo 2 Presentacin de UML ..................................................................... 6 Capitulo 3 Hola Mundo!...................................................................................18 Seccin 2 Modelado estructural bsico..............................................................19 Captulo 4 Clases.............................................................................................20 Captulo 5 Relaciones......................................................................................26 Captulo 6 Mecanismos Comunes................................................................35 Captulo 7 Diagramas...................................................................................38 Captulo 8 Diagramas de clases...................................................................40 Seccin 3 Modelado estructural avanzado.....................................................47 Captulo 9 Caractersticas avanzadas de las clases........................................48 Captulo 10 Caractersticas avanzadas de las relaciones..................................51 Captulo 11 Interfaces, tipos y roles...................................................................54 Captulo 12 Paquetes.........................................................................................59 Captulo 13 Instancias........................................................................................64 Captulo 14 Diagramas de objetos.....................................................................69 Seccin 4 Modelado bsico del comportamiento................................................72 Captulo 15 Interaciones......................................................................................73 Captulo 16 Casos de uso....................................................................................78 Captulo 17 Diagramas de Caso de uso...............................................................82 Captulo 18 Diagramas de interacin...................................................................86 Captulo 19 Diagramas de actividades.................................................................92
Pgina de 97
El LENGUAJE UNIFICADO DE MODELADO
SECCION 1
INTRODUCCION
Pgina de 97
CAPITULO 1 POR QU MODELAMOS

Una empresa de software con xito es aqulla que produce de una manera consistente software de calidad que satisface las necesidades de sus usuarios y la empresa; para producir software que cumpla su propsito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los requisitos reales del sistema., hay que idear una slida base arquitectnica que sea flexible al cambio, software rpido, eficiente, hay que tener gente apropiada y el enfoque apropiado, hay que disponer de un proceso de desarrollo slido que pueda adaptarse a las necesidades cambiantes del problema y la tecnologa. El modelado es una parte central de todas las actividades que conducen a la produccin de buen software. Construimos modelos para comunicar la estructura y el comportamiento del sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema. Construimos modelos para comprender mejor el sistema que estamos construyendo. Construimos modelos para controlar el riesgo.
La importancia de modelar El modelar es una tcnica de ingeniera probada y bien aceptada; por eso los arquitectos de casas y rascacielos ayudan a los usuarios a visualizar el producto final, y no solo es parte de la industria de la construccin, sino en todos los mbitos se utiliza el modelado. Un modelo proporciona los planos de un sistema, y estos pueden involucrar planos detallados, as como los generales que ofrecen una visin global del sistema. Un buen modelo incluye aquellos elementos que tienen una gran influencia. En el modelado, conseguimos cuatro objetivos: Ayudan a visualizar cmo es o queremos que sea un sistema Permite especificar la estructura o el comportamiento de un sistema Proporcionan plantillas que nos guan en la construccin de un sistema Documentan las decisiones que hemos adoptado.
Pgina de 97
1. Principios del modelado 1.- La eleccin de qu modelos crear tiene una profunda influencia sobre cmo se acomete un problema y cmo se da forma a una solucin. En el software, los modelos elegidos pueden afectar mucho a nuestra visin Si construimos un sistema con la mirada de un desarrollador de bases de datos, nos centraremos en los modelos entidad-relacin. Si construimos un sistema con la mirada de un analista estructurado, se obtendrn modelos centrados en los algoritmos. Si construimos un sistema con mirada de un desarrollador orientado a objetos, arquitectura con un mar de clases y patrones de interacciones. Por lo tanto cada visin del mundo conduce a un tipo de sistema diferente, con diferentes costos y beneficios. 2. Todo modelo puede ser expresado a diferentes niveles de precisin. Con los modelos de software, a veces un pequeo y sencillo modelo ejecutable de la interfaz del usuario es exactamente lo que se necesita; otras veces, hay que bajar y enredarse con los bits, como cuando se estn especificando interfaces entre sistemas o luchando con cuellos de botella en redes por ejemplo. Un analista o un usuario final se centrar en el qu; un desarrollador se centrar en el cmo. Tanto uno como otros querrn visualizar un sistema a diferentes niveles de detalle en momentos diferentes. 3. Los mejores modelos estn ligados a la realidad. En el software, el taln de aquiles de las tcnicas de anlisis estructurado es el hecho de que hay una desconexin bsica entre los modelos de anlisis y el modelo de diseo de sistema. No poder salvar este abismo hace que el sistema concebido y el sistema construido diverjan con el paso del tiempo. En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un sistema en un todo semntico. se centra en una
Pgina de 97
4. Un nico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes. Dependiendo de la naturaleza del sistema pueden ser ms importantes que otros. MODELADO ORIENTADO A OBJETOS En el software hay varias formas de enfocar un modelo. Las dos formas ms comunes son la perspectiva orientada a objetos y la perspectiva algortmica, esta ltima tiene una visin conduce a los desarrolladores a centrarse en cuestiones de control y de descomposicin de algoritmos grandes en otros ms pequeos y es algo complejo, mientras la visin orientada o objetos el principal bloque de construccin de todos los sistemas software es objeto o clase, es decir un objeto es una cosa, generalmente extrada del vocabulario del espacio del problema o del espacio de la solucin; una clase es una descripcin de un conjunto de objetos similares. Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software, simplemente porque ha demostrado ser vlido en la construccin de sistemas en toda clase de dominios de problemas, abarcando todo el abanico de tamaos y complejidades. ( UML)
Pgina de 97
CAPITULO 2 PRESENTACIN DE UML
El Lenguaje Unificado de Modelado (Unified Modeling Language, UML), es un lenguaje estndar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. Visin general de UML UML es un lenguaje para: Visualizar Especificar Construir Documentar
UML es un lenguaje Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representacin conceptual y fsica de un sistema, por lo tanto es un lenguaje estndar para los planos del software. UML es un lenguaje para visualizar Un programador cuando esta modelando tiene que pensar en: Primero, la comunicacin de esos modelos conceptuales a otros est sujeta a errores a menos que cualquier persona implicada hable del mismo lenguaje. Segundo, que el software no puede entender a menos que se construyan modelos que trasciendan el lenguaje de programacin textual. Tercero, si el desarrollador que escribi el cdigo no dej documentacin sobre los modelos, esa informacin se perder y ser parcialmente reproducible a partir de la implementacin. En UML es algo ms que un simple montn de smbolos grficos, en cada smbolo hay una semntica definida.
Pgina de 97
UML es un lenguaje para especificar Especificar, significa construir modelos precisos, no complejos. Y UML de gran cantidad de software. UML es un lenguaje para construir En UML, sus modelos pueden conectarse en forma directa a gran variedad de lenguajes de programacin, esta correspondencia permite ingeniera directa: la generacin de cdigo a partir de un modelo UML implementacin. UML es un lenguaje para documentar Una organizacin de software que trabaje bien produce: Requisitos Arquitectura Diseo Cdigo fuente Planificacin de proyectos Pruebas Prototipos Versiones en un lenguaje de programacin, tambin se puede reconstruir a partir de una cubre las especificaciones de todas las decisiones de anlisis, diseo e implementacin que deben realizarse al desarrollar un sistema
UML cubre la documentacin de la arquitectura y proporciona requisitos y pruebas y las actividades de planificacin de proyectos. Dnde puede utilizarse UML? Sistemas de informacin de empresas Bancos y servicios financieros Telecomunicaciones Transporte Defensa / industrias aeroespacial Comercio Electrnica mdica mbito cientfico Servicios distribuidos basados en la Web
Pgina de 97
Un modelo conceptual de UML Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto se 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
Bloques de construccin de UML UML tiene tres clases de bloques de construccin: Elementos Relaciones Diagramas
Los elementos son abstracciones que son cuidados de primera clase en un modelo, las relaciones ligan estos elementos entre s; y los diagramas agrupan colecciones interesantes de elementos ELEMENTOS ESTRUCTURALES Son los nombres de los modelos, son parte esttica de un modelo y representan cosas que son conceptuales, hay 7:
Ventana
Primero.- Es una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica; implementa una o ms interfaces
Origen Tamao Abrir() Cerrar() Mover() Dibujar()
Segundo Una interfaz es una coleccin de operaciones que especifican un servicio de una clase o componente, esta describe el comportamiento visible externamente de ese elemento, puede representar el comportamiento completo de una clase o componente Una interfaz define un conjunto de especificaciones de operaciones, pero nunca un conjunto de implementaciones de operaciones.
Pgina de 97
10
Tercero, Una colaboracin define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamiento de sus elementos, tienen dimensin tanto estructural como de comportamiento, estas representan la implementacin de patrones que forman un sistema Una clase puede participar en varias colaboraciones, Cuarto Un caso de uso es una descripcin de un conjunto de secuencias de acciones que produce un resultado observable de inters para un actor en particular, es estructurar los aspectos de comportamiento de un modelo. Es realizado por una colaboracin Quinto Clase activa, es una clase cuyos objetos tienen uno o ms
Cadena de responsabilidad
Realizar Pedido
GestorEventos Suspender() VaciarCola()
procesos o hilos de ejecucin y por lo tanto pueden dar origen a actividades de control, presentan elementos cuyo comportamiento es concurrente con otros. Sexto Un componente es una parte fsica y reemplazable de un sistema que conforma con de un conjunto de interfaces y proporciona tpicamente la el implementacin dicho conjunto. Representa
Orderform.jav a
empaquetamiento fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones.
Sptimo Es un Nodo, un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que por lo general dispone de algo de memoria y con frecuencia, capa con capacidad de procesamiento.
servidor
Los siete elementos anteriores son los estructurales bsicos que se puede incluir en un modelo UML. Pgina de 97 Ing. Juan Manuel Mrquez Vite 11
Tambin existen variaciones de estos siete elementos, tales como actores, seales, utilidades, procesos e hilos, y aplicaciones, documentos, archivos, bibliotecas, pginas y tablas Elementos de comportamiento Son las partes dinmicas de los modelos, son los verbos y representan comportamiento en el tiempo y el espacio. Hay dos tipos principales de elementos de comportamiento: Primero Una 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 especfico. Una interaccin, involucra muchos otros elementos, incluyendo mensajes, secuencias de accin, y enlaces.
Dibujar Mensajes
Segundo Una 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, junto con sus reacciones a estos eventos.
El comportamiento de una clase individual o una colaboracin de clases pueden especificarse con una mquina de estado, e involucra a otros elementos, incluyendo estados, transiciones, eventos, y actividades
Esperando
Estados
Estos dos elementos bsicos estn conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos.
Elementos de agrupacin descomponerse un modelo. Pgina de 97
Son las partes organizativas de los modelos, son cajas en las que puede Un paquete es un mecanismo de propsito general para organizar Ing. Juan Manuel Mrquez Vite 12
elementos en los grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros elementos de agrupacin pueden incluirse en un paquete., tambin es puramente conceptual.
Reglas del negocio
Elementos de anotacin Son las partes explicativas de los modelos., pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo, la Nota es simplemente un smbolo para mostrar las restricciones y comentarios junto a un elemento o una coleccin de elementos.
Devuelve una copia del objeto receptor Nota
RELACIONES EN UML Primero Dependencia
Hay cuatro relaciones: Es una relacin semntica entre dos elementos, en la cual un cambio a un
elemento independiente puede afectar a la semntica del otro elemento dependiente
Depndencias
Segundo Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregacin es un tipo especial de asociacin, en que representa una relacin estructural entre un todo y sus partes
0....1 patrn
* empleado
Tercero Generalizacin Es una relacin de especializacin / generalizacin en la cual los objetos del elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre.
Pgina de 97
13
Generalizaciones
Cuatro Realizacin. Es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en dos sitios: entre interfaces y las clases y componentes que las realizan, entre los casos de uso y las colaboraciones que los realizan.
Realizacin
Estos cuatro elementos son los bsicos relacionales y sus variaciones son como el refinamiento, la traza, la inclusin y la extensin.
DIAGRAMAS DE UML Un diagrama es la representacin grfica de un conjunto de elementos, visualizado la mayora de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Son 9 los diagramas que incluye UML Diagrama de clases Muestra un conjunto de clases, interfaces y colaboraciones, as como sus
relaciones, cubren la vista de diseo esttico de un sistema, incluyen clases activas cubren la vista de procesos estticos de un sistema. Diagrama de objetos Muestra un conjunto de objetos y sus relaciones representan instantneas de instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseo y proceso esttico de un sistema. Diagrama de casos de uso Muestra un conjunto de casos de uso y actores y sus relaciones Cubren la vista de casos de uso esttica de un sistema.
Estos diagramas son especialmente importantes en el modelado y organizacin del comportamiento de un sistema.
Pgina de 97
14
Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenacin temporal de los mensajes. Es importante mencionar que los diagramas de interaccin entre un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Diagrama de colaboracin Es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes. Diagrama de estados (statechart) Muestra una mquina de estados, que consta de estados
transiciones, eventos y actividades. Cubren la vista dinmica de un sistema y el comportamiento de una interfaz, una clase o una colaboracin y resaltan el comportamiento dirigido por eventos de un objeto. Diagrama de actividades objetos. Diagrama de componentes Muestra la organizacin y las dependencias entre un conjunto de Muestra el flujo de actividades dentro de un sistema. Cubren la vista
dinmica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de
componentes, cubren la vista de implementacin esttica, se relacionan con diagramas de clase en que un componente se corresponde con una o ms clases, interfaces o colaboraciones. Diagrama de despliegue Muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos. Su relacin con los diagramas de componentes en que un nodo incluye, uno o ms componentes.
Mecanismos comunes de UML Hay cuatro mecanismos que se aplican de forma consistente a travs de todo el lenguaje 1. Especificaciones 2. Adornos 3. Divisiones comunes 4. Mecanismos de Extensibilidad. Las especificaciones, proporcionan una explicacin textual de la semntica de ese bloque de construccin; se utiliza para visualizar un sistema, y tambin para detallar el sistema. Las especificaciones en UML proporcionan una base semntica que incluye a todos los elementos de todos los modelos de un sistema, y cada elemento est relacionado con otros de manera consistente. Pgina de 97 Ing. Juan Manuel Mrquez Vite 15
Los diagramas de UML son as simples proyecciones visuales de esa base y cada diagrama revela un aspecto especfico interesante del sistema. Adornos. La notacin de la clase tambin revela los aspectos ms importantes de una clase a saber: su nombre, atributos y operaciones. La especificacin de una clase puede incluir otros detalles, tales como si es abstracta o la visibilidad de sus atributos y operaciones. Muchos de estos detalles se pueden incluir como adornos grficos o textuales en la notacin rectangular bsica de la clase.
Transaccin
+ Ejecutar() + Rollback() # prioridad()
Divisiones comunes, la primer divisin entre clase y objeto, una clase es una abstraccin; un objeto es una manifestacin concreta de esa abstraccin; Arquitectura
Ciente
Juan:Cliente
Nombre Direccin telfono
:Cliente
Elisa
La segunda divisin la tenemos entre interfaz e implementacin. forma fidedigna la semntica completa de la interfaz Pgina de 97 Ing. Juan Manuel Mrquez Vite 16 Una interfaz declara un contrato, y una
implementacin representa una realizacin concreta de ese contrato, responsable de hacer efectiva la
Asistenteortog.dll
Mecanismos de Extensibilidad son: Estereotipos Valores etiquetados Restricciones
Estereotipo, extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construccin que deriven de los existentes pero sean especficos a un problema
ColaEventos exception Overflow (versin =3.2 autor = egb) Aadir() Quitar() Vaciar() {ordenado}
Valor etiquetado
extiende las propiedades de un bloque de construccin de UML, permitiendo aadir
nueva informacin en la especificacin de ese elemento. Restriccin extiende la semntica de un bloque de construccin de UML, permitiendo aadir nuevas reglas o modificar las existentes. ARQUITECTURA Es el conjunto de decisiones significativas sobre: La organizacin de un sistema de software La eleccin de los elementos estructurales y sus interfaces a travs de los cuales constituye el sistema Su comportamiento, como se especifica en las colaboraciones entre esos elementos. La composicin de esos elementos estructurales y de comportamiento en subsistemas progresivamente ms grandes. El estilo arquitectnico que gua esta organizacin: los elementos estticos y dinmicos y sus interfaces, sus colaboraciones y su composicin. Pgina de 97 Ing. Juan Manuel Mrquez Vite 17
Vocabulario, funcionalidad
Ensamblado del sistema Gestin de configuraciones
Vista de Diseo
Vista de implementacin
Comportamiento
Vista de Casos de uso Vista de procesos Vista de Despliegue
Funcionamiento Capacidad De crecimiento, rendimiento
Modelado de la arquitectura de un sistema
Topologa del sistema, Distribucion, Entrega instalacin
La vista de casos de uso, describe el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas. La vista de diseo de un sistema comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solucin. Con UML, los aspectos estticos de esta vista se capturan en los diagramas de clases y de objetos; los aspectos dinmicos se capturan en los diagramas de interaccin, diagramas de estados y diagramas de actividades. La vista de procesos de un sistema comprende los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia del sistema. Esta vista cubre principalmente el funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos estticos y dinmicos de esta vista se capturan en el mismo tipo de diagramas
que la vista de diseo, pero con nfasis en las clases activas que representan estos hilos y procesos. Vista de implementacin de un sistema comprende los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema fsico, se preocupa de la gestin de configuracin de las distintas versiones de un sistema, a partir de componentes y archivos un tanto independientes y que pueden ensamblarse de varias formas para producir un sistema en ejecucin. Pgina de 97 Ing. Juan Manuel Mrquez Vite 18
La vista de despliegue de un sistema contiene los nodos que forman la topologa hardware sobre la que se ejecuta del sistema, la distribucin, entrega e instalacin de las partes que constituyen el sistema fsico. En UML los aspectos estticos de esta vista se capturan en los diagramas de despliegue; los aspectos dinmicos de esta vista se capturan en los diagramas de interaccin, diagramas de estado y diagramas de actividades.
Pgina de 97
19
Captulo 3 Hola, Mundo

En este captulo Clases y componentes. Modelos estticos y modelos dinmicos Conexiones entre modelos Extensin de UML
UML, no es un lenguaje de programacin visual, aunque, como se muestra a continuacin UML, permite un alto acoplamiento con varios lenguajes de programacin como Java. UML, est diseado para permitir transformar los modelos en cdigo y permitir ingeniera inversa del cdigo a modelos. Algunas cosas se escriben mejor en la sintaxis de un lenguaje de programacin textual, mientras que en otras se visualizan mejor grficamente en UML.
HolaMundo
Paint( )
g.drawString (Hola, Mundo!, 10,10)
Este diagrama de clases captura los aspectos bsicos de la aplicacin "!Hola Mundo", pero deja afuera varias cosas. Como especifica el cdigo precedente, otras dos clases ()Applet y Graphics intervienen en la aplicacin y cada una se utiliza de forma diferente. La clase Applet se utiliza como padre* de Hola Mundo y la Clase Graphics se utiliza en la asignatura e implementacin de una de sus operaciones, paint. Estas clases y sus diferentes relaciones como la clase Hola Mundo se pueden representar en un diagrama de clases,
Pgina de 97
20
Applet HolaMundo Paint () Graphics
Pgina de 97
21
SECCION 2
MODELADO ESTRUCTURAL BASICO
Pgina de 97
22
CAPITULO 4
CLASES
El modelado de un sistema implica identificar las cosas que son importantes desde un cierto punto de vista particular. Estas cosas forman el vocabulario del sistema que se est modelando. QUE SON? Las clases son los bloques de construccin ms importantes de cualquier sistema orientado a objetos. Como se puede observar en la figura, una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.
Figura Atributos origen Mover() Suspender() VaciarCola()
Nombre
Operaciones
Objetivos: Se utilizan para capturar el vocabulario del Sistema que esta modelando. Se pueden utilizar para representar cosas que sean software, hardware o puramente conceptuales. Las clases bien estructuradas forman parte de una distribucin equilibrada de responsabilidades en el sistema. Representacin grfica: Esta notacin permite visualizar una abstraccin (caractersticas esenciales de una entidad que la distingue entre otras entidades, una abstraccin define una frontera) independientemente de cualquier lenguaje de programacin especifico y de forma que permite resaltar las partes ms importantes de una abstraccin: su nombre, sus atributos, sus operaciones y responsabilidades.
Pgina de 97
23
CLASES nombre atributos Cliente Nombre Direccin Alta Baja -Solicitar pedidos -Presentar documentacin
operaciones
responsabilidades
Nombre: Es aquel nombre que la distinga de otras clases. Este nombre es una cadena de texto, y por lo general son nombres cortos o expresiones nominales extrados del vocabulario del sistema, y existen 2 tipos: Nombre simple: Nombre de camino: Nombre de la clase precedido por el nombre del paquete en el que se encuentra.
Clientes Reglas de negocio AgenteFraudes
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. Esta propiedad es compartida por todos los objetos de esa clase. En un momento dado un objeto de una clase tendr valores especficos para cada uno de los atributos de su clase.
Cliente atributos nombre direccin telfono
Cliente Nombre: char Direccin: char Clave: int
Nombredireccin Un atributo se puede especificar ms su clase y su valor Operaciones: Una operacin es una abstraccin de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase.
Pgina de 97
24
operaciones
Alta Bajas cambios
Responsabilidades: Es un contrato o una obligacin de la clase, cuando se crea la clase se especifica que todos los objetos de sta tienen el mismo tipo de estado y el mismo tipo de comportamiento. Al modelar las clases, un buen comienzo consiste en especificar las responsabilidades de los elementos del vocabulario:
responsabilidades
-Solicitar pedidos -Presentar documentacin
Otras caractersticas: A veces se necesita visualizar o especificar otras caractersticas, como la visibilidad de atributos y operaciones individuales, por ejemplo si es polimrfica o constante, de las cuales se hablar en captulos posteriores.
Finalmente se dir que las clases rara vez se encuentran solas. Al construir los modelos uno se centra en grupos de clases que interactan entre si. En UML estas sociedades de clases forman colaboraciones y normalmente se representan en Diagramas de Clases.
Tcnicas comunes de modelado MODELADO DEL VOCABULARIO DE UN SISTEMA: Los usuarios identifican las abstracciones, extrayndolas normalmente de objetos que ellos ya usan para describir su sistema. Las tcnicas como las tarjetas CRC y el anlisis de casos de uso son formas para ayudar a los usuarios a encontrar esas abstracciones. Pgina de 97 Ing. Juan Manuel Mrquez Vite 25
Para modelar el vocabulario de un sistema: Identificar aquellas cosas que utilizan los usuarios, para describir el problema o la solucin. Para cada abstraccin hay que identificar un conjunto de responsabilidades bien repartidas Definir los atributos y operaciones necesarias en cada clase para cumplir estas Al ir aumentando de tamao los modelos, muchas de las clases tienden a agruparse en grupos relacionados conceptual y semnticamente. En UML se pueden utilizar los paquetes para modelar estos grupos de clases. MODELADO DE LA DISTRIBUCIN DE RESPONSABILIDADES DE UN SISTEMA: Una vez que se ha modelado, habr que asegurarse que se tenga un equilibrio de responsabilidades. Esto es que no se desea que ninguna clase sea demasiado grande ni demasiado pequea. UML ayuda a visualizar y especificar este reparto de responsabilidades.
1.Identificar un conjunto de clases que colaboren entre ellas para realizar un comportamiento
3.- Dividir las clases con demasiadas responsabilidades. As como meter las pequeas en otras mayores Modelar la Distribucin de Responsabilidad es en un Sistema
2.Identificar responsabilidades para cada una de las clases
4.Equilibrar las responsabilidades para que ninguna clase en colaboracin
MODELADO DE COSAS QUE NO SON SOFTWARE: UML tiene como objetivo principal el modelado de sistemas con gran cantidad de software, pero a veces, las cosas que se modelan pueden no tener un equivalente en el software. Para modelar lo que no es software: Pgina de 97 Ing. Juan Manuel Mrquez Vite 26
Hay que modelar la cosa que se esta abstrayendo como una clase. Para distinguirlos de los bloques de construccin de UML . Crear un nuevo bloque de construccin utilizando estereotipos para especificar la nueva semntica y proporcionar una representacin visual que lo caracterice. Si lo que se est modelando segn el tipo de hardware que a su vez contiene software ,hay que considerar modelarlo como un tipo de nodo, de forma que ms tarde sea posible completar su estructura.
MODELADO DE TIPOS PRIMITIVOS: Las cosas que se modelan pueden extraerse directamente del lenguaje de programacin que se utilice para implementar la solucin. Normalmente, estas abstracciones involucrarn tipos primitivos ,como enteros, cadenas e incluso tipos enumerados ,que uno mismo podra crear. Para modelar tipos primitivos: Hay que modelar la cosa que se esta abstrayendo como un tipo o una enumeracin ,que se representa como una clase con el estereotipo adecuado. Si se necesita especificar el rango de valores asociado al tipo ,hay que utilizar restricciones
<<type>> Int {valores entre -2**31-1 y +2**31}
Sugerencias y consejos: Cada clase debe corresponderse con una abstraccin tangible o conceptual en el dominio del usuario final. Una clase bien estructurada: Proporciona una abstraccin precisa de algo extrado del vocabulario del dominio del problema o del dominio de la solucin. Contiene un pequeo conjunto bien definido de responsabilidades, y las lleva a cabo todas y bien. Pgina de 97 Ing. Juan Manuel Mrquez Vite 27
Proporciona una distincin bien definida entre la especificacin de la abstraccin y su implementacin. Es comprensible y sencilla a la vez que es extensible y adaptable.
Cuando se dibuje una clase: Hay que mostrar solo aquellas propiedades de la clase que sean importantes para comprender la abstraccin en su conjunto. Hay que organizar las listas largas de atributos y operaciones, agrupndolos de acuerdo a su categora. Mostrar las clases relacionadas en el mismo diagrama de clases.
Pgina de 97
28
CAPITULO 5 RELACIONES
Las clases son elementos del vocabulario del sistema y no se encuentran aisladas, la mayora colaboran con otras de varias maneras, es por esto que es importante, modelar como se relacionan estos elementos entre s. Que son? La forma en que las cosas se conectan entre s, bien lgica o fsicamente se modelan como relaciones. Existen tres tipos de relaciones muy importantes que son : Dependencias, generalizaciones y asociaciones.
Objetivos: Estos tres tipos de relaciones cubren las formas importantes en que colaboran unas cosas con otras. Esta notacin permite visualizar relaciones independientemente de cualquier lenguaje de programacin especifico, y de forma que permita destacar las partes mas importantes de una relacin: su nombre, los elementos que conecta y sus propiedades.
Representacin grfica: Grficamente una relacin se representa por una lnea, dependiendo del tipo de relacin ser el tipo de lnea. Dependencia Generalizacin Asociacin
Pgina de 97
29
Dependencias: Es una relacin de uso, en la que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza, pero no necesariamente a la inversa. Las dependencias se utilizan para indicar que una clase utiliza a otra como argumento en la signatura de una operacin. Se usan cuando se quiera indicar que un elemento utiliza a otro.
Ejemplo: Las tuberas dependen del calentador para calentar el agua que conducen
Pelcula/Video Reproducir() Iniciar() Canal
La clase Pelcula usa o depende de la clase Canal. Si la clase utilizada cambia, la operacin de la otra clase puede verse tambin afectada.
Generalizacin: Es una relacin entre un elemento general (superclase o padre) y un caso ms especifico de ese elemento (subclase o hijo). Se llama a veces es-un-tipo-de. Caractersticas: Los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa. El hijo puede sustituir al padre, una clase hijos hereda las propiedades de sus clases padres. El hijo puede aadir atributos y operaciones a los que hereda de sus padres. Existencia del polimorfismo. Una operacin de un hijo con la misma signatura que una operacin del padre redefine la operacin del padre. Una clase puede tener ninguno, uno o ms padres. Una clase sin padre y uno o ms hijos se llama clase raz o clase base. Una clase sin hijos se llama clase hoja Pgina de 97 Ing. Juan Manuel Mrquez Vite 30
Ejemplo Generalizacin: :
REINO ANIMAL
INVERTEBRADOS VERTEBRADOS
Clase base
Figura origen Mover cambiarTamao() dibujar()
generalizacin
Rectngulo Esquina:Punto
Circulo Radio:Float
Polgono Puntos:Lista
cuadrado Clase hoja
ASOCIACIN: Es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro. Las asociaciones se utilizan cuando se quieran representar relaciones estructurales. Caractersticas: Dada una relacin entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto de la otra clase, y viceversa. Es posible que ambos extremos de una asociacin estn conectados a la misma clase. Esto significa que, dado un objeto de la clase, se puede conectar con otros objetos de la misma clase. 31 Pgina de 97 Ing. Juan Manuel Mrquez Vite
Binaria Asociaciones N-arias
Asociacin que conecta exactamente dos clases. Asociaciones que conectan ms de dos clases.
Adornos que se aplican a las asociaciones: Nombre: Una asociacin puede tener un nombre, que se utiliza para describir la naturaleza de la relacin. Se puede dar una direccin al nombre por medio de una flecha que apunte en la direccin en la que se pretende que se lea el nombre.
Nombre direccin del nombre
Persona
Trabaja para
Empresa
Rol: Una clase tiene un rol especifico que juega en la asociacin. Ese rol es la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo.
Persona Empleado Empresa patrn
Se puede nombrar explcitamente el rol que juega una clase, por ejemplo: una persona que juega el rol de empleado esta asociada a una Empresa que juega el rol de patrn.
Multiplicidad: En el modelado es importante sealar cuantos objetos pueden conectarse a travs de una instancia de asociacin. Cuantos = Multiplicidad del rol de la asociacin. Se escribe como una expresin que se evala a un rango de valores o a un valor explicito.
Pgina de 97
32
Multiplicidad
Persona
1..*
Empleado
*
patrn
Persona
Asociacin
Agregacin: Una asociacin normal entre dos clases representa una relacin estructural entre iguales, ambas clases estn al mismo nivel, sin ser ninguna ms importante que la otra. Una agregacin representa una relacin del tipo tiene- un , es decir un objeto del todo tiene objetos de la parte. La agregacin, es cuando una clase representa una cosa grande (el todo), que consta de elementos ms pequeos (las partes) . todo Empresa 1
* parte rombo vaci en la parte del todo. El significado de esta forma es conceptual. El rombo vaci distingue el todo de la parte Otras caractersticas: A veces se necesita visualizar o especificar otras caractersticas, como la agregacin compuesta, discriminantes, clases asociacin, etc , estas y otras, de las cuales se hablar en captulos posteriores. Las dependencias, la generalizacin y las asociaciones son elementos estticos que se definen a nivel de clases. Pgina de 97 Ing. Juan Manuel Mrquez Vite 33 Departamento La agregacin es un tipo especial de asociacin, y se grfica aadiendo a una asociacin normal un
En UML se muestran normalmente en los diagramas de clases.
MODELADO DE DEPENDENCIAS SIMPLES. El tipo ms comn de dependencia es la conexin entre una clase que solo utiliza otra como parmetro de una operacin. Para modelar esta relacin de uso: Hay que crear una dependencia que vaya desde la clase con la operacin hasta la clase utilizada como parmetro de la operacin.
PlanDelCurso Aadir(c:Curso) Eliminar(c:Curso) Curso
Esta figura muestra una dependencia desde PlanDelCurso hacia Curso, porque Curso se utiliza en las dos operaciones aadir y eliminar de PlanDelCurso.
Iterador MODELADO DE LA HERENCIA SIMPLE Al modelar el vocabulario de un sistema existen clases similares a otras estructuralmente o en el comportamiento. Una mejor manera de formar estas es extraer las caractersticas comunes de estructura y comportamiento y colocarlas en clases ms generales de las que heredan las clases especializadas. Para modelar relaciones de herencia: Dado un conjunto de clases, hay que buscar responsabilidades, atributos y operaciones comunes a dos o ms clases. Hay que elevar las caractersticas anteriores a una clase ms general. Si es necesario hay que crear una nueva, teniendo cuidado de no crear en ella muchos niveles. Hay que especificar que las clases ms especficas heredan de la clase ms general, a travs de una relacin de generalizacin, desde cada clase especializada a su padre.
Pgina de 97
34
Valor valorActual() historia()
CuentaCorriente
Accin valorActual()
Bono valorActual() historia()
Propiedad Transaccin valorActual() valorActual() historia()
TasaDeInteres valorActal()
AccinCapPequeo
AccinCapGrande
En la figura se observa una relacin de generalizacin desde cuatro clases hijas (Cuenta corriente, Accin, Bono, Propiedad) hacia la clase ms general Valor, que es el padre, el cual tiene dos operaciones (valorActual e historia), como Valor es el padre las hijas heredan estas dos operaciones, as como tambin cualquier otro atributo. Las jerarquas de generalizacin / especializacin, es frecuente encontrarse con ms de dos niveles de herencia, por ejemplo AccinCapPequeo y AccinCapGrande son hijas de Accin, la cual a su vez es hija de Valor. MODELADO DE RELACIONES ESTRUCTURALES. Cuando se modela con relaciones de asociacin, se modelan clases que son del mismo nivel. Dada una asociacin entre dos clases, ambas dependen de la otra de alguna forma y se puede navegar en ambas direcciones.
Pgina de 97
35
Para cada par de clases, si se navega de los objetos de una a los de otra, hay que especificar una asociacin entre las dos (vista dirigida por datos)
Si los objetos de una clase necesitan interactuar con los objetos de la otra aparte de cmo parmetros de una operacin. Hay que especificar una asociacin. (vista dirigida x comportam)
Para Modelar relaciones estructurales

Para cada asociacin hay que especificar la multiplicidad (especialmente cuando no sea *, que es el valor por defecto) as como los nombres de rol. Si una de las clases es un todo, comparada con las clases en el otro extremo, que parecen las partes, hay que marcarlas como una agregacin (rombo en el todo)
Cmo se sabe cuando deben interactuar los objetos de una clase dada con los objetos de otra clase? .Las tarjetas CRC y el anlisis de casos de uso , son muy tiles pues consideran escenarios estructurales y de comportamiento. Donde se descubra que dos ms clases interactan, se debe especificar una asociacin. Ejemplo: 1 tiene Universidad 1..* miembro * Estudiante * 1..* asiste * Curso * ensea 1..* 1..* Departament o 1..* 1..* Asignado A AAA 1..* Profesor 0..1 director
La figura muestra un conjunto de clases en donde: 1. Hay un asociacin entre Estudiante y Curso, se detalla que los estudiantes asisten a los cursos. 2. Cada estudiante puede asistir a cualquier nmero de cursos y cada curso puede tener nestudiantes. 3. Existe asociacin entre Curso y profesor especificando que los profesores imparten cursos. 4. Para cada curso hay al menos un profesor y cada profesor puede impartir cero o ms cursos. 5. Hay relaciones de agregacin entre Universidad , Estudiante y Departamento. 6. Una Universidad tiene cero o ms estudiantes, cada estudiante puede ser miembro de una o ms universidades. Pgina de 97 Ing. Juan Manuel Mrquez Vite 36
7. Una Universidad tiene uno o ms departamentos y cada departamento pertenece exactamente a una universidad. 8. Existe la agregacin en donde se especifica que Universidad es un todo y que Estudiante y Departamento son algunas de sus partes 9. Hay dos asociaciones entre Departamento y Profesor. Una de ellas especifica que cada profesor est asignado a uno o ms departamentos y que cada departamento tiene uno o ms profesores. Esto se modela como una agregacin, porque organizativa mente los departamentos estn a un nivel superior que los profesores. 10. La otra asociacin especifica que para cada departamento hay exactamente un profesor que es el director del departamento. Sugerencias y consejos. Cuando se modelan relaciones en UML: Hay que usar dependencias solo cuando la relacin que se este modelando no sea estructural. Hay que usar la generalizacin solo cuando se tenga una relacin es-un-tipo-de; la herencia mltiple se puede reemplazar por la agregacin. Hay que tener cuidado de no introducir relaciones de generalizacin cclicas. En general hay que mantener las relaciones de generalizacin equilibradas. Hay que usar asociaciones principalmente donde existan relaciones estructurales entre objetos.
Cuando se dibuje una relacin en UML: Hay que utilizar consistentemente lneas rectas u oblicuas. El empleo de ambos tipos de lneas en el mismo diagrama es til para llamar la atencin sobre diferentes grupos de relaciones. Hay que evitar los cruces de lneas. Hay que mostrar solo aquellas relaciones necesarias para comprender una agrupacin particular de elementos. Las relaciones superfluas (especialmente las asociaciones redundantes) deberan omitirse.
Pgina de 97
37
CAPITULO 6 MECANISMOS COMUNES

En este captulo se ve: Notas, Estereotipo, valores etiquetados y restricciones. Modelado de comentarios Modelado de nuevos bloques de construccin. Modelado de nuevas propiedades. Modelado de nueva semntica. Formas de extender UML. Las notas son el tipo de adorno ms importante que pude aparecer aislado. Una nota es un smbolo grfico para mostrar restricciones o comentarios asociados a un elemento o a una coleccin de elementos. La nota se utiliza para aadir a un modelo informacin tal como requisitos, observaciones, revisiones y explicaciones
Nota Considerar aqu el uso del patrn de diseo
Los estereotipos, los valores etiquetados y las restricciones son los mecanismos que proporciona UML para aadir nuevos bloques de construccin, crear nuevas propiedades y especificar nueva semntica. Tambin permiten introducir nuevos smbolos grficos, para proporcionar seales visuales en los modelos, relacionadas con el lenguaje del dominio y la cultura de desarrollo.
Pgina de 97
38
estereotipo system Facturacin {versin = 3.2 }
Valor etiquetado Un valor etiquetado es una extensin de las propiedades de un elemento de UML, permitiendo aadir nueva informacin en la especificacin de ese elemento. Grficamente, un valor etiquetado se representa con una cadena de caracteres entre llaves colocadas debajo del nombre de otro elemento.
Nodo estereotipado
Servidor
{lnea > 10M/seg}
Concentrador
Restriccin
Una restriccin es una extensin de la semntica de un elemento de UML, que permite aadir nuevas reglas o modificar las existentes. Grficamente, una restriccin se representa como una cadena de caracteres entre llaves colocada junto al elemento al que est asociada o conectada a ese elemento por relaciones de dependencia. SUGERENCIAS Y CONSEJOS Cuando se adorne un modelo con notas: Hay que usar las notas slo para los requisitos, observaciones, revisiones y explicaciones que no se puedan expresar de un modo simple y con sentido con las caractersticas existentes de UML Hay que usar las notas como un tipo de notas pos-it electrnicas, para seguir los pasos del trabajo en desarrollo. Cuando se dibujen notas.
Pgina de 97
39
No hay que complicar los modelos con grandes bloques de comentarios. En vez de ello, si se necesita realmente un comentario largo, deben usarse las notas como lugar donde enlazar o incluir un documento que contenga el comentario completo. Cuando se exista un modelo con estereotipos, valores etiquetados o restricciones: Hay que homologar un conjunto pequeo de estereotipos, valores etiquetados y restricciones para usar en el proyecto y evitar que los desarrolladores creen a ttulo individual muchas extensiones nuevas. Hay que elegir nombres cortos y significativos para los estereotipos y los valores etiquetados. Donde se pueda relajar la precisin, hay que usar texto libre para especificar las restricciones. Si es necesario un mayor rigor, puede usar OCL para escribir expresiones de restricciones.
Pgina de 97
40
CAPITULO 7 DIAGRAMAS
Diagramas, vistas y, modelos Modelado de las diferentes vistas de un sistema Modelado de las diferentes niveles de abstraccin Modelado de vistas complejas Organizacin de diagramas y otros artefactos. Un diagrama es solo una proyeccin grfica de los elementos que configuran un sistema. Normalmente, las partes estticas de un sistema se representarn mediante uno de los cuatro diagramas siguientes: Diagrama de clase Diagrama de objetos Diagrama de componentes Diagrama de despliegue
Para las partes dinmicas Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de estado Diagrama de actividades. clases muestra un conjunto de clases, interfaces y colaboraciones, as como sus
Diagrama de
relaciones, cubren la vista de diseo esttico de un sistema, incluyen clases activas cubren la vista de procesos estticos de un sistema. Diagrama de objetos muestra un conjunto de objetos y sus relaciones representan instantneas de instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseo y proceso esttico de un sistema. Pgina de 97 Ing. Juan Manuel Mrquez Vite 41
Diagrama de casos de uso muestra un conjunto de casos de uso y actores y sus relaciones Cubren la vista de casos de uso esttica de un sistema.
Estos diagramas son especialmente importantes en el modelado y organizacin del comportamiento de un sistema. Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenacin temporal de los mensajes. Es importante mencionar que los diagramas de interaccin entre un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Diagrama de colaboracin es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes. Diagrama de estados (statechart) muestra una mquina de estados, que consta de estados
transiciones, eventos y actividades. Cubren la vista dinmica de un sistema y el comportamiento de una interfaz, una clase o una colaboracin y resaltan el comportamiento dirigido por eventos de un objeto. Diagrama de actividades objetos. Diagrama de componentes muestra la organizacin y las dependencias entre un conjunto de muestra el flujo de actividades dentro de un sistema. Cubren la vista
dinmica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de
componentes, cubren la vista de implementacin esttica, se relacionan con diagramas de clase en que un componente se corresponde con una o ms clases, interfaces o colaboraciones. Diagrama de despliegue muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos. Su relacin con los diagramas de componentes en que un nodo incluye, uno o mas componentes.
Pgina de 97
42
CAPITULO 8 DIAGRAMAS DE CLASES

Los diagramas de clases son los ms utilizados en el modelado de sistemas orientados a objetos. Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Los diagramas de clases se utilizan para modelar la vista de diseo esttica de un sistema. Principalmente, esto incluye modelar el vocabulario del sistema, modelar las colaboraciones o modelar esquemas. Los diagramas de clases tambin son la base para un par de diagramas relacionados: los diagramas de componentes y los diagramas de despliegue. Los diagramas de clases son importantes no slo para visualizar, especificar y documentar modelos estructurales, sino tambin para construir sistemas ejecutables, aplicando ingeniera directa e inversa. Cuando se construye una casa, se comienza con un vocabulario que incluye bloques de construccin bsicos, tales como paredes, suelos, ventanas, puertas, techos y vigas. Estos elementos son principalmente estructurales (las paredes tienen una altura, una anchura y un grosor), pero tambin tienen algo de comportamiento (diferentes tipos de paredes pueden soportar diferentes cargas, las puertas se abren y cierran, hay restricciones sobre la extensin de un suelo sin soporte). La construccin de software coincide en muchas de estas caractersticas con construccin de una casa, excepto que, dada la fluidez del software, es posible definir bloques de construccin bsicos desde cero. Con UML, los diagramas de clases emplean para visualizar el aspecto esttico de estos bloques y sus relaciones y para especificar los detalles para construirlos, como se muestra en la Figura 8.1.
Pgina de 97
43
FIGURA 8.1 Un diagrama de clases
Definicin
Un diagrama de clases es un diagrama que muestra un conjunto de interfaces,
colaboraciones y sus relaciones. Grficamente, un diagrama de clases es una coleccin nodos y arcos. Propiedades comunes Los diagramas de clases contienen normalmente los siguientes elementos: Clases. Interfaces. Colaboraciones. Relaciones de dependencia, generalizacin y asociacin.
Los diagramas de clases se utilizan en las siguientes tres formas: Pgina de 97 Ing. Juan Manuel Mrquez Vite 44
1. Para modelar el vocabulario de un sistema. 2. Para modelar colaboraciones simples. 3. Para modelar un esquema lgico de base de datos. Para modelar una colaboracin: Hay que identificar los mecanismos que se quieren modelar. Un mecanismo representa una funcin o comportamiento de la parte del sistema que se modelando que resulta de la interaccin de una sociedad de clases, interfaces y otros elementos. Para cada mecanismo, hay que identificar las clases, interfaces y otras colaboraciones que participan en esta colaboracin. Asimismo, hay que identificar relaciones entre estos elementos. Hay que usar escenarios para recorrer la interaccin entre estos elementos. Durante el recorrido, se descubrirn partes del modelo que faltaban y partes que semnticamente incorrectas. Hay que asegurarse de rellenar estos elementos con su contenido. Para las clases hay que comenzar obteniendo un reparto equilibrado de responsabilidades, Despus, a lo largo del tiempo, hay que convertir stas en atributos y operaciones concretos. Por ejemplo, la Figura 8.2 muestra un conjunto de clases extradas de la implementacin de un robot autnomo. La figura se centra en las clases implicadas en el mecanismo para mover el robot a travs de una trayectoria. Aparece una clase abstracta (Motor) dos hijos concretos, MotorDireccion y MotorPrincipal. Ambas clases heredan cinco operaciones de la clase padre, motor. A su vez, las dos clases se muestran como partes de otra clase, Conductor. La clase AgenteTrayectoria tiene una asociacin uno a uno con Conductor y una asociacin uno a muchos con SensorColision. No se muestran atributos ni operaciones para AgenteTrayectoria, aunque s se indican sus responsabilidades.
Pgina de 97
45
Figura 8.2. Modelado de colaboraciones simples. Modelado de un esquema lgico de base de datos Para modelar un esquema: Hay que identificar aquellas clases del modelo cuyo estado debe trascender el tiempo de vida de las aplicaciones. Hay que crear un diagrama de clases que contenga estas clases y marcarlas como persistentes (un valor etiquetado estndar). Se puede definir un conjunto propio de valores etiquetados para cubrir detalles especficos de bases de datos. Hay que expandir los detalles estructurales de estas clases. En general, esto significa especificar los detalles de sus atributos y centrar la atencin en las asociaciones que estructuran estas clases y en sus cardinalidades. Hay que buscar patrones comunes que complican el diseo fsico de bases de datos, tales como asociaciones cclicas, asociaciones uno a uno y asociaciones n-arias. Donde sea necesario, deben crearse abstracciones intermedias para simplificar la estructura lgica. Hay que considerar tambin el comportamiento de las clases persistentes expandiendo las operaciones que sean importantes para el acceso a los datos y la integridad de los datos. En general, para proporcionar una mejor separacin de intereses, las reglas del negocio relativas a la manipulacin de conjuntos de estos objetos deberan encapsularse en una capa por encima de estas clases persistentes. Donde sea posible, hay que usar herramientas que ayuden a transformar un diseo lgico en un diseo fsico. Pgina de 97 Ing. Juan Manuel Mrquez Vite 46
La Figura 8.3 muestra un conjunto de clases extradas de un sistema de informacin de una universidad. Esta figura es una extensin de un diagrama anterior, y ahora se muestran las clases a un nivel suficientemente detallado para construir una base de datos fsica. Comenzando por la parte inferior y a la izquierda de este diagrama, se encuentran las clases Estudiante, Curso y Profesor. Hay una asociacin entre Estudiante y curso, que especifica que los estudiantes asisten a los cursos. Adems, cada estudiante puede asistir a cualquier nmero de cursos y cada curso puede tener cualquier nmero de estudiantes.
Figura 8.3. Modelado de un esquema.
Pgina de 97
47
Ingeniera directa e inversa Para hacer ingeniera directa con un diagrama de clases: Hay que identificar las reglas para la correspondencia al lenguaje o lenguajes de implementacin elegidos. Esto es algo que se har de forma global para el proyecto o la organizacin. Segn la semntica de los lenguajes escogidos, quizs haya que restringir el uso de ciertas caractersticas de UML. Por ejemplo, UML permite modelar herencia mltiple, pero Smalltalk slo permite herencia simple. Se puede optar por prohibir a los desarrolladores el modelado con herencia mltiple (lo que hace a los modelos dependientes del lenguaje) o desarrollar construcciones especficas del lenguaje de implementacin para transformar estas caractersticas ms ricas (lo que hace la correspondencia ms compleja). Hay que usar valores etiquetados para especificar el lenguaje destino. Se puede hacer esto a nivel de clases individuales si se necesita un control ms preciso. Tambin se puede hacer a un nivel mayor, tal como colaboraciones o paquetes. Hay que usar herramientas para hacer ingeniera directa con los modelos.
La Figura 8.4 ilustra un sencillo diagrama de clases que especifica una instanciacin del patrn cadena de responsabilidad. Esta instanciacin particular involucra a tres clases: Cliente, GestorEventos y GestorEventosGUI. Cliente y GestorEventos se representan como clases abstractas, mientras que GestorEventosGUI es concreta. GestorEventos tiene la operacin que normalmente se espera en este patrn (gestionarSolicitud), aunque se han aadido dos atributos privados para esta instanciacin.
Figura 8.4. Ingeniera directa.
Pgina de 97
48
Para hacer ingeniera inversa sobre un diagrama de clases: Hay que identificar las reglas para la correspondencia desde el lenguaje o lenguajes de implementacin elegidos. Esto es algo que se har de forma global para el proyecto o la organizacin. Con una herramienta, hay que indicar el cdigo sobre el que se desea aplicar ingeniera inversa. Hay que usar la herramienta para generar un nuevo modelo o modificar uno existente al que se aplic ingeniera directa previamente. Con la herramienta, hay que crear un diagrama de clases inspeccionando el modelo. Por ejemplo, se puede comenzar con una o ms clases, despus expandir el diagrama, considerando relaciones especficas u otras clases vecinas. Se pueden mostrar u ocultar los detalles del contenido de este diagrama de clases, segn sea necesario, para comunicar su propsito. Sugerencias y consejos Un diagrama de clases bien estructurado: Se centra en comunicar un aspecto de la vista de diseo esttica de un sistema. Contiene slo aquellos elementos que son esenciales para comprender ese aspecto. Proporciona detalles de forma consistente con el nivel de abstraccin, mostrando slo aquellos adornos que sean esenciales para su comprensin. No es tan minimalista que deje de informar al lector sobre la semntica importante.
Cuando se dibuje un diagrama de clases: Hay que darle un nombre que comunique su propsito. Hay que distribuir sus elementos para minimizar los cruces de lneas. Hay que organizar sus elementos espacialmente de modo que los que estn cercanos semnticamente tambin lo estn fsicamente. Hay que usar notas y colores como seales visuales para llamar la atencin sobre caractersticas importantes del diagrama. Hay que intentar no mostrar demasiados tipos de relaciones. En general, un tipo de relacin tender a dominar cada diagrama de clases.
Pgina de 97
49
SECCION 3
MODELADO ESTRUCTURAL AVANZADO
Pgina de 97
50
CAPITULO 9 CARACTERISTICAS AVANZADAS DE LAS CLASES

Las clases son solo un tipo de clasificador, los clasificadores son los bloques de construccin mas general en el UML , estos tienen tanto caractersticas estructurales como de comportamiento. As cada instancia de un clasificador comparten unas mismas caractersticas. Los tipos de clasificadores son: Interfase. Una coleccin de operaciones Tipo de dato. Valores no identificados Seal. Comunicacin asncrona entre las instancias Componente. Una parte fsica y reemplazable de un sistema Nodo. Representa un recurso computacional que posee memoria y capacidad de proceso Caso de Uso. Secuencia de acciones Subsistema. Grupo de elementos
Visibilidad La visibilidad es una caracterstica que indica si puede ser usado por otro clasificador, se dividen en: public. Puede usarlo cualquiera lo precede un smbolo + Protected. Solamente los descendientes pueden usarlos lo precede el smbolo # Private. Unicamente el mismo clasificador puede usarlo
Al realizar diagramas se acostumbra poner solo aquellas caractersticas que se emplean en ese momento no es necesario dibujar las todas a menos que se vayan a usar. Alcance Para determinar si una caracterstica de algn clasificador tiene alcance en sus instancias o solo esta presente en ese clasificador se denota por un una lnea, si la caracterstica esta subrayada entonces solo aparece en el clasificador si no entonces esta presente tambin en todas las instancias. Elementos abstractos, races, hojas y polimorficos Si una clase no tiene instancias se dice que es abstracta y se representa con letras itlicas, si la clase no tiene hijos entonces es una clase hoja. Si la clase no tiene padres entonces se trata de una clase raz; y Pgina de 97 Ing. Juan Manuel Mrquez Vite 51
si la clase es polimorfica indica que cualquier mensaje enviado en tiempo de ejecucin el tipo de dato es escogido polimrfica mente. Multiplicidad Se refiere al numero de instancias que una clase puede tener como mximo, se especifica con un numero entero en la parte superior derecha del recuadro de la clase. Atributos El nombre del atributo contiene varias caractersticas: Visibilidad Alcance Multiplicidad tipo Valor inicial
De acuerdo a la nomenclatura establecida anteriormente, existen otros tres atributos: changeable. No hay restricciones para modificar el valor del atributo addOnly. Se puede aadir valores, aunque una vez creado ya no es posible deshacer el cambio frozen. Inicializado el objeto el valor del atributo no es posible modificarlo
Operaciones Los nombres de las operaciones tambin pueden especificar las siguientes caractersticas: Visibilidad Alcance Parmetros Tipo de retorno Concurrencia {direccin} nombre: tipo [= valor por default] direccin puede tomar cualquiera de los siguiente valores
En su forma completa la sintaxis de una operacin en UML es
Pgina de 97
52
in parmetro de entrada. No se puede modificar out. Parmetro de salida. Puede modificarse para comunicar informacin de invocador inout. Parmetro de entrada. Puede ser modificado.
Adems de la propiedad left hay otras cuatro que pueden ser usadas con las operaciones isQuery la ejecucin de la operacin no cambia el estado del sistema sequential Los invocadores deben coordinarse para que en el objeto exista un nico flujo guarded La integridad del objeto es asegurada en presencia de mltiples flujos concurrent Pueden ocurrir mltiples llamadas la integridad del objeto se conserva
Clases plantilla Definen una familia de clases que pueden ser instanciadas por elementos especficos. Para modelar una clase plantilla en UML se procede como una clase normal solo que se dibujo un recuadro en la parte superior derecha que contendr los parmetros de la plantilla Tcnicas comunes de modelado Una vez que se han identificado todas las abstracciones el siguiente paso es especificar su semntica. Se debe decidir el nivel apropiado de detalle para comunicar su modelo. Si usted quiere comunicarse con usuarios le conviene manejar un nivel bajo, si usted desea establecer un flujo entre los modelos y el cdigo sus diagramas deben ser formales. Si usted quiere describir matemticamente un modelo sus diagramas deben ser muy formales. Para modelar la semntica de una clase se sigue el siguiente procedimiento especificar las responsabilidades de cada clase especificar la semntica de la clase por medio de espaol estructurado especificar el cuerpo de cada mtodo especificar las condiciones de cada operacin especificar una maquina de estados para cada clase especificar el diagrama de colaboracin especificar las condiciones de cada operacin
Pgina de 97
53
CAPITULO 10 CARACTERISTICAS AVANZADAS DE LAS RELACIONES

Al modelar sistemas se necesitan de relaciones. Una relacin es una conexin entre elementos, se clasifican en dependencias generalizaciones y asociaciones. Dependencia Una dependencia especifica que un cambio en un elemento puede afectar a otro elemento que lo utiliza. Hay ocho estereotipos que se aplican a las dependencias entre objetos y clases
Bind Derive Friend InstanceOf Instantiate Powertype Refine Use la dependencia instancia a la plantilla destino con los parmetros reales dados el origen puede calcularse a partir del destino el origen tiene una visibilidad especial en el destino el objeto origen es una instancia del clasificador destino el origen crea instancias del destino el destino es un supratipo del origen; un supratipo es u clasificador cuyos objetos son todos los hijos de un padre dado. el origen esta en un grado de abstraccin ms detallado que el destino la semntica del elemento origen depende de la semntica de la parte publica del destino.
Hay dos estereotipos que se aplican a las dependencias entre paquetes access import el paquete origen tiene permiso para referenciar elementos del paquete destino los contenidos pblicos del paquete destino entran en el espacio de nombres del origen.
Dos estereotipos se aplican a las relaciones de dependencia entre casos de uso extend include caso de uso. Hay tres estereotipos que surgen al modelar interacciones entre objetos become call copy el destino es el mismo objeto que el origen, pero en un instante posterior y posiblemente con diferentes valores, estados o roles. la operacin origen invoca a la operacin destino el objeto destino es un acopia exacta, pero independiente del origen. el caso de uso destino extiende el comportamiento del origen el caso de uso origen incorpora explcitamente el comportamiento de otro
Un estereotipo que aparece en el contexto de las maquinas de estado es send. Especifica que la operacin origen enva el evento destino Pgina de 97 Ing. Juan Manuel Mrquez Vite 54
Por ltimo hay un estereotipo que aparecer en el contexto de la organizacin de los elementos de u sistema en subsistemas y modelos: trace especifica que el destino es un antecesor histrico del origen. Generalizacin Una generalizacin es una relacin entre un elemento general y un tipo mas especifico de ese elemento llamado subclase o hijo, este heredara la estructura y comportamiento del padre, aunque puede aadir nueva estructura y comportamiento, en ocasiones esta herencia es mltiple. UML define un estereotipo y cuatro restricciones para las generalizaciones. El estereotipo es implementation, hereda la implementacin del padre pero no hace pblicas ni soporta sus interfaces. Las restricciones son complete incomplete disjoint overlapping todos los hijos en la generalizacin se han especificado en el modelo y no se no se han especificado todos los hijos en la generalizacin los objetos del padre no pueden tener mas de uno de los hijos como tipo los objetos del padre pueden tener mas de uno de los hijos como tipo permiten hijos adicionales
Asociacin Especifica que los elementos de un objeto se conectan a los objetos de otro. Por ejemplo, una clase biblioteca podra tener una asociacin uno a muchos con una clase libro. Hay cuatro adornos bsicos que se aplican a las asociaciones: nombre, rol en cada extremo de la asociacin, multiplicidad en cada extremo y agregacin. Para usos avanzados, hay otras propiedades que permiten modelar detalles sutiles, como la navegacin, calificacin y algunas variantes de la agregacin. Navegacin. Se puede representar de forma explcita la direccin de la navegacion con una flecha que
apunte en la direccin de recorrido Visibilidad Calificacin sintaxis Pgina de 97 Ing. Juan Manuel Mrquez Vite 55 Los objetos de una clase pueden ver y navegar hasta los objetos de la otra Es un calificador, es un atributo de una asociacin cuyos valores particionan el conjunto
de objetos relacionados con un objeto a travs de una asociacin. Se puede evidenciar el tipo con la
Composicin Es realmente una asociacin Clases asociacin Es un elemento de modelado con propiedades tanto de asociacin como de clase Restricciones UML define cinco restricciones que se aplican a las asociaciones. implicit La relacin es solo conceptual ordered changeable addOnly el conjunto de objetos en un extremo de una asociacin sigue un orden explcito Se pueden aadir, eliminar y modificar libremente los enlaces entre los objetos se pueden aadir nuevos enlaces
frozen Un enlace, una vez aadido desde un objeto del otro extremo de la asociacin, no se puede modificar ni eliminar. Realizacin Es una relacin en la cual un clasificador especifica un contrato que otro clasificador garantiza que cumplir. La mayora de las veces empleara la realizacin para especificar la relacin entre una interfaz y la clase o el componente que proporciona una operacin o servicio para ella. Tambin se utiliza la realizacin para especificar la relacin entre un caso de uso y la colaboracin que realiza ese caso de uso. Tcnicas comunes de modelado Modelado de redes de relaciones Cuando modele redes de relaciones considere que: No hay que comenzar de manera aislada comenzar modelndolas relaciones estructurales que estn presentes Identificar las posibles relaciones de generalizacin/especializacin buscar dependencias Hay que comenzar con su forma bsica no es deseable ni necesario modelar un diagrama nico
La clave para tener xito al modelar redes complejas de relaciones es hacerlo de forma incremental
Pgina de 97
56
CAPITULO 11 INTERFACES, TIPOS Y ROLES

Las interfaces definen una lnea entre la especificacin de lo que una abstraccin hace y la implementacin de cmo lo hace. Una interfaz es una coleccin de operaciones que sirven para especificar un servicio de una clase o componente. Las interfaces se utilizan para visualizar, especificar, construir y documentar las lneas de separacin dentro de un sistema. Los tipos y los roles proporcionan un mecanismo para modelar la conformidad esttica y dinmica de una abstraccin con una interfaz en un contexto especfico. Una interfaz bien estructurada proporciona una clara separacin entre las vistas externa e interna de una abstraccin, haciendo posible comprender y abordar una abstraccin sin tener que sumergirse en los detalles de su implementacin. INTRODUCCIN No tendra sentido construir una casa donde hubiese que romper los cimientos cada vez que hubiese que pintar las paredes. Asimismo, nadie deseara vivir en un sitio donde hubiese que reinstalar los cables cada vez que se cambiara una lmpara. Por ejemplo tenemos que hay tamaos estndar para bloques de madera, que hacen fcil construir paredes que sean mltiplos de un tamao comn. Hay tamaos estndar de puertas y ventanas, lo que significa que no hay que construir artesanalmente cada abertura en el edificio. Incluso hay estndares para los enchufes elctricos y de telfono que hacen fcil combinar y acoplar equipos electrnicos. Adems al elegir las interfaces apropiadas, se pueden tomar componentes estndar, bibliotecas y frameworks para implementar interfaces, sin tener que construirlas uno mismo. Al ir descubriendo mejores implementaciones, se pueden reemplazar las viejas sin afectar a sus usuarios. En UML , las interfaces se emplean para modelar las lneas de separacin de un sistema. Una interfaz es una coleccin de operaciones que sirven para especificar un servicio de una clase o un componente. Al declarar una interfaz, se puede anunciar el comportamiento deseado de una abstraccin independiente de una implementacin de ella. Los clientes pueden trabajar con esa interfaz, y se puede construir o comprar cualquier implementacin de la misma, siempre que esta responsabilidades y el contrato indicado en la interfaz. Pgina de 97 Ing. Juan Manuel Mrquez Vite 57 implementacin satisfaga las
UML
proporciona una representacin grfica de la interfaces, como se muestra en la figura 1. Esta
notacin permite ver la especificacin de una abstraccin separada de cualquier implementacin.
TERMINOS Y CONCEPTOS Una interfaz es una coleccin de operaciones que se usa para especificar un servicio de una clase o de un componente. Un tipo es un estereotipo de una clase utilizado para especificar un dominio de objetos, junto a las operaciones aplicables al objeto. Un rol es el comportamiento de una entidad participante en un contexto particular. Grficamente, una interfaz se representa como un circulo; de forma expandida, una interfaz se puede ver como una clase estereotipada para mostrar sus operaciones y otras propiedades. Nombres Cada interfaz ha de tener un nombre que la distinga de otras interfaces. Un nombre es una cadena de texto. Ese nombre slo se denomina nombre simple; un nombre de camino consta del nombre de la interfaz precedido por el nombre del paquete en el que se encuentra. Una interfaz puede dibujarse mostrando slo su nombre. Operaciones Cuando se representa una interfaz en su forma normal como un crculo, por definicin, se omite la visualizacin de estas operaciones. Sin embargo, si es importante para entender el modelo actual, se puede dibujar una interfaz como una clase estereotipada, listando sus operaciones en el comportamiento apropiado. Las operaciones se pueden representar slo con su nombre o pueden extenderse para mostrar la signatura completa y otras propiedades.
Pgina de 97
58
Relaciones Al igual que una clase, una interfaz puede participar en relaciones de generalizacin, asociacin y dependencia. Adems, una interfaz puede participar en relaciones de realizacin. La realizacin es una relacin semntica entre dos clasificadores en la que un clasificador especifica un contrato que el otro clasificador garantiza llevar a cabo. Una interfaz especifica un contrato para una clase o un componente sin dictar su implementacin. Una clase o un componente puede realizar muchas interfaces. Una interfaz especifica un contrato, y el cliente y el proveedor de cada lado pueden cambiar independientemente, siempre que cada uno cumpla sus obligaciones en el contrato. Comprender una interfaz En UML se puede proporcionar mucha ms informacin a una interfaz para hacerla comprensible y manejable. En primer lugar, se pueden asociar pre y poscondiciones a cada operacin e invariantes a la clase o componente. Tipos y roles Una clase puede realizar muchas interfaces. Una instancia de sea clase debe, por tanto, soportar todas esas interfaces, ya que una interfaz define un contrato, y cualquier abstraccin que conforme con la interfaz debe, por definicin, llevar a cabo fielmente ese contrato. Por ejemplo, considrese una instancia de la clase persona. Segn el contexto, esa instancia de persona puede jugar el papel de Madre, Asistente Contable, Empleado, Cliente, Directivo, Piloto, Cantante, etc. En UML se puede especificar el rol que una abstraccin presenta a otra abstraccin adornando el
nombre de un extremo de la asociacin con una interfaz especifica. Para modelar formalmente la semntica de una abstraccin y su conformidad con una interfaz especfica, se utilizar el estereotipo type. Type es un estereotipo de clase, y se emplea para especificar un dominio de objetos, junto a las operaciones aplicables a los objetos de ese tipo.
Pgina de 97
59
Tcnicas comunes de Modelado MODELADO DE LAS LNEAS DE SEPARACIN DE UN SISTEMA Cuando se reutiliza un componente de otro sistema o cuando se adquiere a terceros, probablemente lo nico que se tiene es un conjunto de operaciones con alguna documentacin mnima sobre el significado de cada una. Para modelar las lneas de separacin de un sistema: Dentro de la coleccin de clases y componentes del sistema, hay que dibujar una lnea alrededor de aquello que tienden a acoplarse estrechamente con otros conjuntos de clases y componentes. Hay que refinar la agrupacin realizada considerando el impacto del cambio. Las clases o componentes que tienden a cambiar juntos deberan agruparse juntos como colaboraciones. Hay que considerar las operaciones y las seales que cruzan estos lmites, desde instancias de un conjunto de clases y componentes hacia instancias de otros conjuntos de clases y componentes. Hay que empaquetar los conjuntos lgicamente relacionados de estas operaciones y seales como interfaces. Para cada colaboracin del sistema, hay que identificar las interfaces en las que se basa (importa) y las que suministra a otros (exporta). Se debe modelar la importacin de interfaces con relaciones de dependencia y la exportacin de interfaces con relaciones de realizacin. Para cada interfaz del sistema, hay que documentar su dinmica mediante pre y poscondiciones para cada operacin, y casos de uso y mquinas de estados para la interfaz como un todo. MODELADO DE TIPOS ESTTICOS Y DINMICOS Para modelar un tipo dinmico: Hay que especificar los diferentes tipos posibles del objeto, representando cada tipo como una clase estereotipada con type( si la abstraccin requiere estructura y comportamiento) o interfaces (Si la abstraccin slo requiere comportamiento). Hay que modelar todos los roles que puede asumir la clase del objeto en cualquier momento. Esto se puede hacer de dos formas: 1. Primera, en un diagrama de clases, asociar explcitamente un tipo a cada rol que la clase juega en su asociacin con otras clases. Al hacer esto se especifica el aspecto que presentan las instancias de esa clase en el contexto del objeto asociado. Pgina de 97 Ing. Juan Manuel Mrquez Vite 60
2. Segunda, tambin en un diagrama de clases, especificar las relaciones de clases a tipos mediante generalizaciones. En un diagrama de interaccin, hay que representar apropiadamente cada instancia de la clase tipada dinmicamente. Debe mostrarse el rol de la instancia entre corchetes debajo del nombre del objeto. Para mostrar el cambio del rol de un objeto, hay que dibujar el objeto una vez por cada rol que juega en la interaccin, y conectar estos objetos con un mensaje estereotipado, como become. Sugerencias y Consejos Al modelar una interfaz en UML, hay que recordar que cada interfaz debe representar una lnea de separacin en el sistema, separando especificacin de implementacin. Una interfaz bien estructurada: Es sencilla, aunque completa, y proporciona todas las operaciones necesarias y suficientes para especificar un nico servicio. Es comprensible, proporcionando suficiente informacin tanto para permitir su uso como para su realizacin sin tener que examinar algn uso ya existente o alguna implementacin. Es manejable, proporcionando informacin para guiar al usuario hacia sus propiedades claves sin estar sobrecargado por los detalles de un gran nmero de operaciones. Cuando se dibuje una interfaz en UML: Hay que emplear la notacin en forma de pirueta cuando slo sea necesario especificar la presencia de una lnea de separacin en el sistema. La mayora de las veces esto es lo que se necesitar para los componentes, no para las clases. Hay que emplear la forma expandida cuando sea necesario visualizar los detalles del propio servicio. La mayora de las veces esto es lo que se necesita para especificar las lneas de separacin en un sistema asociado a un paquete o a un subsistema.
Pgina de 97
61
CAPITULO 12 PAQUETES
Visualizar, especificar, construir y documentar grandes sistemas conlleva manejar una cantidad de clases, interfaces, componentes, nodos, diagramas y otros elementos que puede ser muy elevada. Conforme va creciendo el sistema hasta alcanzar un gran tamao, se hace necesario organizar estos elementos en bloques mayores. En UML organizar elementos de modelado en grupos. Los paquetes bien diseados agrupan elementos cercanos semnticamente y que suelen cambiar juntos. Por tanto, los paquetes bien estructurados son cohesivos y poco acoplados, estando muy controlado el acceso a su contenido. INTRODUCCIN Todos los sistemas grandes se jerarquizar en niveles de esta forma. De hecho, quizs la nica forma de comprender un sistema complejo sea agrupando las abstracciones en grupos cada vez mayores. UML proporciona una representacin grfica de lo paquetes. Esta notacin permite visualizar grupos de elementos que se pueden manipular como un todo y en una forma que permite controlar la visibilidad y el acceso a elementos individuales. Trminos y concepto Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Grficamente, un paquete se representa como una carpeta. Nombres Cada paquete ha de tener un nombre que lo distinga de otros paquetes. Un nombre es una cadena de texto. El nombre solo denomina nombre simple; un nombre de camino consta del nombre del paquete precedido por el nombre del paquete en el que se encuentra, si es el caso. Un paquete se dibuja normalmente mostrando slo su nombre. el paquete es un mecanismo de propsito general para
Pgina de 97
62
Elementos contenidos Un paquete pueden contener otros elementos, incluyendo clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes. Si el paquete se destruye, el elemento es destruido. Cada elemento pertenece exclusivamente a un nico paquete. Sin los paquetes, se acabara con grandes modelos planos en los que todos los elementos eberan tener nombre nicos (una situacin inimaginable, especialmente cuando se compran clases y otros elementos desarrollados por varios equipos). Los paquetes ayudan a controlar los elementos que componente un sistema mientras evolucionan a diferentes velocidades a lo largo del tiempo. Visibilidad Se puede controlar la visibilidad de lo elementos contenidos en un paquete del mismo modo que se puede controlar la visibilidad de loa atributos y operaciones de una clase. Importacin y exportacin Supongamos que tenemos dos clases llamadas A y B, que se conocen mutuamente. Al ser compaeras, A puede ver a B y B puede ver A, as que cada una depende de la otra. Dos clases tan slo constituyen un sistema trivial, as que realmente no se necesita ningn tipo de empaquetamiento. Generalizacin Existen dos tipos de relaciones que pueden darse entre paquetes: las dependencias de acceso e importacin, utilizadas para importar en un paquete los elementos exportados por otro, y las generalizaciones, para especificar familias de paquetes. La generalizacin entre paquetes es muy parecida a la generalizacin entre clases. Por ejemplo tenemos que el paquete windowsGUI hereda de GUI, de forma que incluye las clases GUI::Ventana y GUI::GestorEventos. Adems, windowsGUI redefine una clase (Formulario) y aade otra nueva (VBForm).
Pgina de 97
63
Elementos estndar Todos los mecanismos de extensibilidad de UML se aplican a los paquetes. UML define cinco estereotipos estndar que se aplican a los paquetes: 1. facade 2. framework 3. Stub 4. Subsystem 5. System Especifica un paquete que es slo un vista de algn otro paquete. Especifica un paquete que consta principalmente de patrones. Especifica un paquete que sirve de proxy para el contenido pblico de otro paquete. Especifica un paquete que representa una parte independiente del sistema completo que se est modelando. Especifica un paquete que representa el sistema completo que se est modelando. UML no especifica iconos para ninguno de estos estereotipos. Adems de estos cinco estereotipos de
paquetes, tambin se emplearn las dependencias con la importacin estndar de estereotipos. Tcnicas comunes de modelado MODELADO DE GRUPOS DE ELEMENTOS El objetivo ms frecuente para l que se utilizan los paquetes es organizar elementos de modelado en grupos a los que se puede dar un nombre y manejar como un conjunto. Hay una distincin importante entre clases y paquetes: las clases son abstracciones de cosas encontradas en el problema o en la solucin; los paquetes son los mecanismos que se emplean para organizar los elementos del modelo. Los paquetes tambin se pueden emplear para agrupar diferentes tipos de elementos. Por ejemplo, en un sistema en desarrollo por un equipo distribuido geogrficamente, se podra utilizar los paquetes como las unidades bsicas para la gestin de configuraciones, colocando en ellos todas las clases y diagramas que cada equipo puede registrar y verificar independientemente.
Pgina de 97
64
Para modelar grupos de elementos. Hay que examinar los elementos de modelado de una determinada vista arquitectnica en busca de grupos definidos por elementos cercanos entre s desde un punto de vista conceptual o semntico. Hay que englobar cada uno de esos grupos en un paquete. Para cada paquete, hay que distinguir los elementos que podrn ser accedidos desde fuera. Deben marcarse estos elementos como pblicos, y los dems como protegidos o privados. En caso de duda debe ocultarse el elemento. Hay que conectar explcitamente los paquetes que dependen de otros a travs de dependencias de importacin. En el caso de familias de paquetes, hay que conectar los paquetes especializados con sus partes ms generales por medio de generalizaciones. MODELADO DE VISTAS ARQUITECTNICAS El uso de paquetes para agrupar elementos relacionados es importante; no se pueden desarrollar modelos complejos sin utilizarlos. Recurdese que una vista es una proyeccin de la organizacin y estructura de un sistema, centrada en un aspecto particular del sistema. Para modelar vistas arquitectnicas: Hay que identificar el conjunto de vistas arquitectnicas que son significativas en el contexto del problema. En la prctica, normalmente se incluyen una vista de diseo, una vista de procesos, una vista de implementacin, una vista de despliegue y una vista de casos de uso. Hay que colocar en el paquete adecuado los elementos (y diagramas) necesarios y suficientes para visualizar, especificar, construir y documentar la semntica de cada vista. Si es necesario, hay que agrupar an ms estos elementos en sus propios paquetes. Normalmente existirn dependencias entre los elementos de diferentes vistas. As que, en general, hay que permitir a cada vista en la cima del sistema estar abierta al resto de vistas en el mismo nivel.
Pgina de 97
65
SUGERENCIAS Cuando se modelan paquetes en UML hay que recordar que existen slo para ayudar a organizar los
elementos del modelo. Si se tienen abstracciones que se manifiestan como objeto en el sistema real, no se deben utilizar paquetes. En vez de ello, se utilizarn elementos de modelado, tales como clases o componentes. Un paquete bien estructurado: Es cohesivo, proporcionando un lmite bien definido alrededor de un conjunto de elementos relacionados. Est poco acoplado, exportando slo aquellos elementos que otros paquetes necesitan ver realmente, e importando slo aquellos elementos necesarios y suficientes para que los elementos del paquete hagan su trabajo. No est profundamente anidado, porque las capacidades humanas para comprender estructuras profundamente anidadas son limitadas. Posee un conjunto equilibrado de elementos; los paquetes de un sistema no deben ser demasiado grandes en relacin a los otros (si es necesario, deben dividirse) ni demasiado pequeos (deben combinarse los elementos que se manipulen como un grupo). Cuando se dibuje un paquete en UML: Hay que emplear la forma simple del icono de un paquete a menos que sea necesario revelar explcitamente el contenido. Cuando se revele el contenido de un paquete, hay que mostrar slo los elementos necesarios para comprender el significado del paquete en el contexto. Especialmente si se estn usando los paquetes para modelar elementos sujetos a una gestin de configuraciones, hay que revelar los valores de las etiquetas asociadas a las versiones.
Pgina de 97
66
Captulo 13 Instancias
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. Instancia y Objeto son sinnimos. Los objetos son instancias de clases, todos los objetos son instancias aunque algunas instancias no son objetos (por ejemplo, una instancia de una asociacin no es un objeto es solo una instancia llamada enlace. Una abstraccin denota la esencia ideal de una cosa; Una instancia denota una manifestacin concreta as en una instancia habr una abstraccin que especifique las caractersticas ms comunes a todas las instancias. Las instancias no aparecen aisladas estn ligadas a una abstraccin en la mayora de las instancias que se modelen en UML sern instancias de clases (estas se llama objetos. Para identificar una instancia se subraya el nombre. Instancias:
Instancia con nombre Teclas pulsadas: Cola

Instancia annima : Marco
Una clase abstracta no pudo tener instancias directas sin embargo se pueden modelar instancias indirectas; Cuando se modelan instancias, ests se colocan en los diagramas de objetos o en diagramas de interaccin y de actividades para esto se necesita. NOMBRES Cada instancia debe tener un nombre que la distinga de las otras instancias dentro de su contexto, un nombre es una cadena de texto de una operacin. Cuando se da nombre a un objeto se puede dar nombre simple a un objeto tal como un cliente.
Pgina de 97
67
En muchos casos el nombre real de un objeto slo es conocido por el computador en el que existe en tales casos se representa un objeto annimo tal como Multimedia: :AudioStream , Incluso si se conoce la abstraccin asociada al objeto se le puede dar un nombre explcito tal como agente. Especialmente cuando se modelan grandes colecciones de objetos se denominan multiobjetos(tal como: cdigo clave) como se muestra a continuacin.
mi cliente
Instancia con nombre

T: Transaccin
: Multimedia:: AudioStream
Instancia annima
multiobjeto
: cdigo clave : cdigo clave
Agente :
Instancia hurfana
El nombre de una instancia puede ser texto formado por cualquier nmero de letras excepto signos como los dos puntos que se utilizan para separar el nombre de una instancia del nombre de su abstraccin. Operaciones Las operaciones que se pueden ejecutar sobre un objeto se declaran en la abstraccin del objeto se puede definir la operacin commit() entonces dada la instancias cual sea t se puede escribir las expresiones como t.commit() donde commit es la (operacin. Estado Un objeto tambin tiene estado, este incluye todas las propiedades (normalmente estticas. Estas propiedades incluyen los atributos del objeto. Ejemplo:
Instancia con valores de atributos Mi Cliente Id: SSN =432-89-1783 Activo =True Instancia con estado explcito
C: telfono [esperando Respuesta]
Pgina de 97
68
Otras caractersticas Los procesos e hilos con un elemento de la vista de procesos de un sistema, proporcionan una seal visual para distinguir los elementos activos (aquellos que representan una raz de un flujo de control)de los pasivos. La mayora de las veces utilizarn los objetos activos que modelan mltiples flujos de control. Y puede utilizarse para nombrar a distintos flujos. Por lo tanto un enlace es una conexin semntica entre objetos. Una instancia de una asociacin es por tanto un enlace, un enlace se representa con una lnea, al igual que una asociacin puede distinguirse porque los enlaces slo conectan objetos. Un atributo o una operacin de clase. Una caracterstica de clases es un objeto de clase compartido para todas las instancias de la clase. Elemento estndar Normalmente no se aplica un estereotipo directamente a una instancia ni se le da un valor etiquetado propio. En vez de eso se derivan del estereotipo y valores etiquetados de su abstraccin asociada. UML define dos estereotipos: 1. -InstanceOf 2. -Instantiate Especifica que el objeto origen es una instancia del clasificador destino Especifica que la clase origen crea instancias de la clase destino.
Tambin hay dos estereotipos relacionados: 1. -become 2. -Copy Especifica que el destino es le mismo pero en un instante posterior y con valor, estados o roles posiblemente diferentes. Especifica que el objeto destino es una copia exacta pero independiente del origen.
UML define una restriccin: Transient Especifica que una instancia del rol es creada durante la ejecucin de la interaccin que lo engloba pero se destruye antes de complementar la ejecucin.
Pgina de 97
69
Tcnicas comunes de Modelado. MODELADO DE INSTANCIAS CONCRETAS Una de las cosas para las cosas para las que se emplean los objetos es para modelar instancias concretas ste podra mostrar las relaciones estructurales entre instancias dibujando un diagrama de objetos. Para modelar instancias concretas: Hay que identificar aquellas instancias necesarias para visualiza especificar, construir o documentar el problema que se est modelando. Hay que representar objetos en UML como instancias sea posible, hay que dar un nombre a cada
objeto. Si no hay un nombre significativo puede representarse como un objeto annimo.
Hay que mostrar el estereotipo, los valores etiquetados y los tributos y suficientes para modelar el problema. Hay que representar estas instancias y sus relaciones en un diagrama de objetos u otro diagrama apropiado al tipo de instancia (nodo, componente, etc.). Ejemplo
Actual : Transaccin Agente Principal [trabajando] Transaccin :: Transaccin <<instanceOf> Agente Fraudes
MODELO DE INSTANCIAS PROTOTPICAS La utilizacin ms importante que se hace de las instancias es modelar las interacciones dinmicas entre objetos. Generalmente cuando se modelan tales interacciones, no se estn modelando instancias concretas. Ms bien modelan objetos conceptuales son bsicamente proxies o sustitutos estos son objetos prototpicos por tanto son con los que conforman instancias. Pgina de 97 Ing. Juan Manuel Mrquez Vite 70
La diferencia semntica entre objetos concretos y objetos prototpicos solamente importante para modeladores avanzados. UML utiliza el trmino rol clasificador para denotar un rol con el que conforman algunas instancias, los objetos concretos aparecen en lugares estticos, tales como diagramas de objetos, diagramas de componentes, de despliegue. Los objetos prototpicos aparecen como los diagramas de interaccin y los diagramas de actividades. Para modelar instancias prototpicas: Hay que identificar aquellas instancias prototpicas para visualizar, especificar, construir o documentar el problema. Representar objetos en UML como instancias. Hay que mostrar las propiedades de cada instancia necesarias y suficientes para modelar el problema. Hay que representar estas instancias y sus relaciones en un diagrama de interaccin o de actividades. Ejemplo
2.1: Iniciar CostoLlamada 1 : crear A : Agente Llamada C: Conexin 2: activar Conexin T1 : Terminal 1.2: aadir 1.1 : aadir T2 : Terminal
Toda instancia debe denotar una manifestacin concreta de alguna abstraccin, normalmente una clase componente nodo caso de uso o asociacin.
Pgina de 97
71
Captulo 14 Diagramas de Objetos

Un diagrama de objetos es un diagrama que representa la parte esttica de una interaccin consistiendo en los objetos que colaboran pero sin ninguno de los mensajes enviados entre ellos, este tambin representa un conjunto de objetos y sus relaciones en un momento concreto. Grficamente, un diagrama de objetos es una coleccin de nodos y arcos o enlaces. Sus propiedades es un tipo especial de diagrama que comparte las propiedades comunes al resto de los diagramas (un nombre y un contenido grafico para el desglose para proyeccin del modelo) Lo que puede distinguir al diagrama de objetos de entre los dems es su contenido particular. Para los diagramas de objetos normalmente contienen: Objetos Enlaces
Y la igual puede tener notas y restricciones. Los diagramas de Objetos pueden contener paquetes o subsistemas los que se usan para agrupar elementos de un modelo en partes ms grandes Usos comunes En los diagramas de objetos se emplean usualmente para darle una perspectiva de instancias reales o prototpicas. Al modelar la vista diseo esttica o la vista de procesos esttica de un sistema normalmente los diagramas de objetos se utilizan para modelar estructuras de objetos, esto implica tomar los objetos en un sistema en cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representada por un diagrama de interaccin. Los Diagramas se emplean para especificar, construir documentar ciertas instancias en el sistema con sus relaciones.
Pgina de 97
72
Tcnicas comunes de modelado Modelado de estructuras de Objetos Con los diagramas de objetos no se puede especificar completamente la estructura de objetos del sistema puede existir una multitud de posibles instancias de una clase particular y para un conjunto de clases con relaciones entre ellas pueden existir muchas ms configuraciones posibles de esos objetos. Al utilizar diagramas de objetos se pueden mostrar significativamente conjuntos interesantes de objetos concretos o prototpicos. Para modelar una estructura de Objetos: Hay que identificar el mecanismo que se desea modelar, un mecanismo representa alguna funcin o comportamiento de la parte del sistema que se est modelando. Cada mecanismo hay que identificar las clases, interfaces y otros elementos que participan en la colaboracin del mecanismo. Considerar el escenario en le que intervenga este mecanismo as tambin cada objeto que participe en el mecanismo. Hay que mostrar el estado y valores de los atributos de cada uno de los objetos. Mostrar los enlaces entre estos objetos que representan las instancias.
R: Robot [movimiento]
m : Mundo
<<global>> sin Asignar : Elemento
A1 : rea
A1 : rea
P1: Pared Anchura = 36
D8: Puerta Anchura = 36
Pgina de 97
73
INGENIERA DIRECTA E INVERSA. Hacer Ingeniera Directa es la creacin de un cdigo a partir de un modelo esto con un diagrama de objetos, aunque a veces este limitado ya que las instancias son creadas y destruidas por la aplicacin en tiempo de ejecucin por lo tanto se puede instanciar los objetos desde el exterior. La Ingeniera Inversa es algo muy distinto es mientras s esta depurando el sistema, esto es algo que el programador o las herramientas estn haciendo continuamente ir tomando seguimientos para verificar el recorrido del proceso en ciertos pasos o tiempos para reconocer donde se invalida el proceso y as poder corregir el estado de los objetos. Para hacer Ingeniera inversa con un diagrama de objetos: Hay que elegir el objetivo este se establecer en el contexto dentro de una operacin. Detener la ejecucin en un determinado instante utilizando herramientas o simplemente recorriendo un escenario. Hay que identificar el conjunto de objetos que colaboran en le texto representarlos en el diagrama de objetos. Mostrar el estado de estos objetos Si el diagrama termina complicndose hay que recortarlo eliminando aquellos objetos que no sean pertinentes para las cuestiones sobre los escenarios. Si el diagrama es demasiado simple hay que expandir los vecinos de objetos interesantes para mostrar una mayor profundidad de los objetos. En los diagramas de objetos en UML para que estn bien estructurados deben tomarse en cuenta El diagrama se centra en un aspecto de diseo esttica o la vista de un proceso esttica de un sistema. Representa una escena histrica presentada por un diagrama de interaccin. Solo elementos esenciales que comprenden ese aspecto. Forma consistente en el nivel de abstraccin mostrando solo aquellos valores de atributos y otros procesos para su comprensin. Darle un nombre que comunique su propsito. , Minimizar los cruces de las lneas organizar los elementos de manera semntica utilizar comentarios y relevantes. Pgina de 97 Ing. Juan Manuel Mrquez Vite 74
Hay que incluir los valores, estado y rol de cada objeto, si es necesario para comunicar su propsito.
SECCION 4
MODELADO BASICO DEL COMPORTAMIENTO
Pgina de 97
75
Captulo 15 INTERACCIONES
Introduccin En UML, los aspectos estticos de un sistema se moderan mediante elementos tales como los diagramas de clases y los diagramas de objetos. Estos diagramas permiten especificar, construir y documentar los elementos del sistema, incluyendo clases, interfase es, componentes, nodos y casos de uso e instancias de ellos, as como la forma en la que estos elementos se relacionan entre s. En UML, los aspectos dinmicos de un sistema se modelan mediante interacciones. Al igual que un diagrama de objetos, una interaccin tiene una naturaleza esttica, ya que establece el escenario para un comportamiento del sistema introduciendo todos los objetos que colaboran para realizar alguna accin. Pero, a diferencia de los diagramas de objetos, las interacciones incluyen los mensajes enviados entre objetos. La mayora de las veces, un mensaje implica la invocacin de una operacin o el envo de una seal; un mensaje tambin puede incluir la creacin o la destruccin de objetos. Las interacciones se utilizan para modelar el flujo de control dentro de una operacin, una clase, un componente, un caso de uso o el propio sistema.
Nmero de Secuencia
t : Planif ic adorTraf icoAereo
1: obtenerPos icion
p: PlanDeVuelo
1.1: obt enerUlt im oControl()
objeto
Enlace
Mensaje
Figura 1 Mensajes, enlaces y secuenciamiento
Trminos y conceptos Una interaccin es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto que alude a un propsito. Un mensaje es la especificacin de una comunicacin entre objetos que transmite informacin, con la expectativa de que se desencadenara una actividad. Pgina de 97 Ing. Juan Manuel Mrquez Vite 76
Contexto Una interaccin puede aparecer siempre que unos objetos estn enlazados a otros. Objetos y roles Los objetos que participan en una interaccin son o bien elementos concretos o bien elementos prototpicos. Como elemento concreto, un objeto representa algo del mundo real. Por ejemplo, una instancia de la clase persona, podra de notar a una persona particular. Enlace Un enlace es una conexin semntica entre objetos. En general, un enlace es una instancia de una asociacin. Un enlace especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro (o asimismo). Mensajes Un mensajero es la especificacin de una comunicacin entre objetos que transmite informacin, con la expectativa de que se desencadenara una actividad. La recepcin de una instancia de un mensaje puede considerarse una instancia de un evento. Cuando es un mensaje, la accin resultante es una instruccin ejecutable que constituye una abstraccin de un procedimiento computacional. Un accin puede producir un cambio en el estado. En UML , se puede modelar varios tipos de acciones. Llamada Retorno Envo Creacin Destruccin Invoca una operacin sobre un objeto; un objeto puede enviarse un mensaje a s mismo, lo que resulta en la invocacin local de una operacin. Devuelve un valor al invocador. Enviar una seal a un objeto. Crear un objeto. Destruye un objeto; un objeto puede suicidarse al destruirse asimismo.
Secuenciacin Cuando un objeto enva un mensaje a otro, el objeto receptor puede, a su vez, enviar un mensaje a otro objeto, el cual puede enviar un mensaje a otro objeto diferente, etc. este flujo de mensajes forma una secuencia. Pgina de 97 Ing. Juan Manuel Mrquez Vite 77
Creacin modificacin y destruccin La mayora de las veces, los objetos que participan en una interaccin existen durante todo el tiempo que dura la interaccin. Sin embargo, algunas interacciones pueden conllevar la creacin y destruccin de objetos. Para especificar si un objeto un enlace aparece y/o desaparece durante una interaccin, se puede asociar una de las siguientes restricciones al elemento: new destroyed transient Especifica que la instancia o el enlace se crea durante la ejecucin de la interaccin que la contiene. Especifica que la instancia o el enlace se destruye antes de completarse la ejecucin de la interaccin que la contiene. Especifica que en la instancia o el enlace se crea durante la ejecucin de la interaccin que la contiene, pero se destruye antes de completarse su ejecucin Representacin Dndose mote la una interaccin, normalmente se incluirn tanto objetos como mensajes. Los objetos y mensajes implicados en una interaccin se pueden visualizar de dos formas: destacando la ordenacin temporal de sus mensajes, o destacando la organizacin estructural de los objetos que envan y reciben los mensajes. En UML tipo de diagramas de interaccin. , el primer tipo de representacin se llama diagrama de secuencia; el segundo tipo de representacin se llama diagrama de colaboracin, siendo estos dos del
Pgina de 97
78
Tcnicas comunes de modelado MODELADO DE UN FLUJO DE CONTROL Para modelar un flujo de control: Hay que establecer el contexto de la interaccin, si es el sistema global, una clase o una operacin individual. Hay que establecer el escenario para la interaccin, identificando que objetos juegan un rol; deben establecer sus propiedades iniciales, los valores de sus atributos, estado y rol. Si el modelado destaca la organizacin estructural de esos objetos, hay que identificar los enlaces que los conectan y que sean relevantes para los trayectos de comunicacin que tienen lugar en la interaccin. Si es necesario, hay que especificar la naturaleza de los enlaces con los estereotipos de estndar y las restricciones de UML . Hay que especificar los mensajes que pasan de 1 objet otro mediante una ordenacin temporal. Si es necesario, hay que distinguir los diferentes tipos de mensajes; se deben incluir parmetros y valores de retorno para expresar los detalles necesarios de las interacciones. Para expresar los detalles necesarios de la interaccin, hay que adornar cada objeto con su estado y rol, siempre que sea preciso. Sugerencias y consejos Cuando se modelan interacciones en UML, hay que recordar que cada interaccin representa los aspectos dinmicos de una sociedad de objetos. Una interaccin bien estructurada: Es sencilla y debe incluir slo aquellos objetos que colaboran para llevar a cabo algn comportamiento mayor que la suma de los comportamientos de esos elementos. Tiene un contexto claro y puede representar la interaccin de objetos en el contexto de una operacin, una clase o el sistema completo. Es eficiente y debe llevar a cabo su comportamiento con un equilibrio ptimo de tiempo y recursos. Es adaptable y los elementos ms proclives a cambiar deberan al separar que puedan ser fcilmente modificados. Pgina de 97 Ing. Juan Manuel Mrquez Vite 79
Es comprensible y debera ser sencilla, y no debe incluir trucos, efectos laterales ocultos ni semntica oscura. Cuando se dibuje una interaccin en UML: Hay que elegir el aspecto destacar que en la interaccin. Se puede destacar la ordenacin temporal de los mensajes con la secuencia de los mensajes en el contexto de alguna organizacin estructural de objetos. No se pueden hacer ambas cosas al mismo tiempo. Hay que mostrar slo aquellas propiedades de cada objeto (valores de atributos, rol y estado) que sean importantes para comprender la interaccin en su contexto. Hay que mostrar slo aquellas propiedades de los mensajes (parmetros, semntica de concurrencia, valor de retorno) que sean importantes para comprender la interaccin en su contexto.
Pgina de 97
80
Captulo 16 CASOS DE USO

Los casos de uso bien estructurados denotan slo comportamientos esenciales del sistema o de un subsistema. Introduccin Un caso de uso describe un conjunto de secuencias donde cada secuencia representa la interaccin de los elementos externos al sistema (sus actores) con el propio sistema(y con sus abstracciones claves). En realidad, un estos comportamientos son funciones a nivel del sistema que se utilizan durante la captura de requisitos y la anlisis para visualizar, especificar, construir y documentar el comportamiento esperado del sistema. Un caso de uso involucra la interaccin de actores y el sistema. Un acto representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interactuar con estos. Los actores pueden ser personas o puede ser sistemas mecnicos. Los casos de uso se pueden aplicar al sistema completo. Tambin se pueden aplicar a partes del sistema, incluyendo sus sistemas e incluso clases de interfases individuales.
actor caso de uso
ResponsablePrestamos
Procesar prstamo
nombre
Figura 2 Actores y casos de uso
Pgina de 97
81
Trminos y conceptos Nombres Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Casos de uso y actores Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan en interaccin con estos. Normalmente, un acto representa un rol que es jugado por una persona, un dispositivo hardware o incluso otro sistema al intelectual con nuestro sistema. Los actores slo se pueden conectar a los casos de uso a travs de asociaciones. Una asociacin entre un actor y un caso de uso indican que el actor y el caso de uso se comunican entre s, y cada uno puede enviar y recibir mensajes.
actor
Cliente
generalizacin
actor
Cliente comercial
Figura 3 Actores
Casos de uso y flujo de eventos Un caso de uso describe que hace un sistema pero no especifica cmo lo has. El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo entienda fcilmente. Nota: el flujo de lentos de un caso de uso se puede especificar de muchas formas, incluyendo texto estructurado y formal(como el ejemplo anterior), un texto estructurado formal (con pre y poscondiciones) y pseudo cdigo. Casos de uso y escenarios Normalmente, primeros se describe el flujo de eventos de un caso de uso mediante texto. Se usa un diagrama de secuencia para especificar el flujo principal de un caso de uso, y se usan variaciones de ese diagrama para especificar los flujos excepcionales del caso de uso.
Pgina de 97
82
Casos de uso y colaboraciones El objetivo de la arquitectura de un sistema es encontrar el conjunto mnimo de colaboracin es bien estructuradas que satisfacen el flujo de eventos, especificado en todos los casos de uso del sistema. Organizacin de casos de uso Los casos de uso tambin pueden organizarse especificando relaciones de generalizacin, inclusin y extensin de entre ellos. Que estas relaciones se utilizan para factor izar el comportamiento comn y para factores a variantes. La generalizacin entre casos de uso es como la generalizacin entre clases. Una relacin de inclusin entre casos de uso significa que un caso de uso base incorpora explcitamente comportamiento de otro caso de uso en el lugar especificado en el caso base. Una relacin de extensin entre casos de uso significa que un caso de uso base incorpora implcitamente comportamiento de otro caso de uso en el lugar de especificados indirectamente por el caso de uso que extiende a la base. Otras caractersticas Los casos de uso tambin son clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases. Como clasificador es que son, tambin se pueden asociar mquinas de Estados a los casos de uso. Las mquinas de Estados se pueden usar como otra forma de describir el comportamiento representado por un caso de uso. Tcnicas comunes de modelado MODELADO DEL COMPORTAMIENTO DE UN ELEMENTO Cuando se modelan comportamiento de estos elementos, es importante centrarse en lo que hace el elemento, no en como lo hace. Para modelar el comportamiento de un elemento: Hay que identificar los actores que interactan con el elemento. Hay que organizar los actores identificando tanto los roles ms generales como los ms especializados. Hay que considerar las formas ms importantes que tiene cada actor de interactuar con el elemento. Hay considerar tambin las formas excepcionales en las que cada actor puede interactuar con el elemento. Hay que organizar estos comportamientos como casos de uso.
Sugerencias y conceptos Un caso de uso bien estructurado: Pgina de 97
83
Nombra un comportamiento simple, identificable y razonablemente atmico del sistema o parte del sistema. Factoriza el comportamiento comn, incorporando ese comportamiento desde otros casos de uso que incluye. Factoriza las variantes, colocando ese comportamiento en otros casos de uso que lo extiende. Describe el flujo de eventos de forma suficientemente clara para que alguien externo al sistema no entienda fcilmente. Se describe por un conjunto mnimo de escenarios que especifica la semntica normal y de las variantes del caso de uso.
Cuando se dibuje un caso de uso en UML : Hay que mostrar slo aquellos casos de uso que sean importantes para comprender el comportamiento del sistema o parte del sistema en su contexto. Hay que mostrar slo aquellos factores relacionados con ese caso de uso.
Pgina de 97
84
Captulo 17 DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso son uno de los cinco tipos de diagramas en UML que se utilizan para el modelado de los aspectos dinmicos de un sistema (los otros cuatro tipos son los diagramas de actividades, de Estados, de secuencia y de colaboracin). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, un actor y sus relaciones.
Telfono mvi l
Realizar llamada telf onica Red telef nica
Realizar llamada de conf erencia
actor
Recibir llamada telf onica Recibir llamada adicional
casos de uso
Usuario Usar agenda
frontera del sistema
Figura 4 Un diagrama de casos de uso
Trminos y conceptos Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones. Usos comunes Se emplean para modelar la vista de casos de uso esttica de un sistema. Esta vista cubre principalmente el comportamiento del sistema. Pgina de 97 Ing. Juan Manuel Mrquez Vite 85
Tcnicas comunes de modelado MODELADO DEL CONTEXTO DE UN SISTEMA En UML se puede modelar el contexto de un sistema con un diagrama de casos de uso o, destacando los actores en torno al sistema. La decisin sobre que incluir como una todos es importante, porque al hacer esos especifica un tipo de cosas que entre actan con el sistema. Para modelar contexto del sistema: Hay que e identificar los actores en torno al sistema. Hay que organizar los actores similares en jerarquas de generalizacin/ especializacin. Hay que proporcionar un estereotipo para cada uno de esos actores, si as se ayuda a entender el sistema. Hay que Introducir esos actores en un diagrama de casos de uso y especificar las vas de comunicacin de cada toro con los casos de uso del sistema. MODELADO DE LOS REQUISITOS DE UN SISTEMA Un requisito es una caracterstica de diseo, una propiedad o un comportamiento de un sistema. Cuando se enuncia los requisitos de un sistema se estn estableciendo un contrato entre los elementos externos al sistema y el propio sistema, que establece lo que se espera que haga el sistema. Para modelar los requisitos de un sistema: Hay que establecer el contexto del sistema. Hay que considerar el comportamiento que cada actor espera del sistema por requiere que ste le proporcione. Hay que nombrar esos comportamientos comunes como casos de uso. Hay que factorizar el comportamiento comn en nuevos casos de uso que puedan ser utilizados por otros. Hay que modelar esos casos de uso, actores y relaciones en un diagrama de casos de uso. Hay que adornar esos casos de uso con notas que en un siendo requisitos no funcionales.
INGENIERA DIRECTA E INVERSA La mayora de los otros diagramas de UML, incluyendo los diagramas de clase, de componentes y Estados, son claros candidatos para la ingeniera directa e inversa, porque cada uno tiene un anlogo en un sistema ejecutable.
Pgina de 97
86
La ingeniera directa es el proceso de transformar un modelo en cdigo a travs de una correspondencia con un lenguaje de implementacin. Para ser ingeniera directa con un diagrama de casos de uso: Hay que identificar el flujo de eventos de cada caso de uso, y su flujo de eventos excepcional. Segn el grado en el que se desee profundizar con las pruebas. Si es necesario, hay que generar una estructura de prueba para representar cada actor que interacta con el caso de uso. Hay que usar herramientas que ejecuten estas pruebas a la vez que se genere una nueva versin del elemento al que se aplica el diagrama de casos de uso. La ingeniera inversa es el proceso de transformar cdigo en un modelo a travs de una correspondencia a partir de un lenguaje de implementacin especfico. Para ser un diagrama de casos de uso mediante ingeniera inversa: Hay que identificar a cada actor sin que acta con el sistema. Hay que considerar la forma indicada actor interaccin tuba con el sistema, cambio de estado del sistema o de su entorno, corresponde a algn evento. Hay que trazar el flujo de eventos del sistema ejecutable en relacin con cada actor. Hay que agrupar los flujos relacionados declarando el correspondiente caso de uso. Hay que representar esos actores y casos de uso en un diagrama de casos de uso, y establecer sus relaciones. Sugerencias y consejos Un diagrama de casos de uso bien estructurado: Se ocupa de modelar un aspecto de la vista de casos de uso de esttica de un sistema.
Pgina de 97
87
Contiene slo aquellos casos de uso y actores que esenciales para comprender ese aspecto. Proporciona detalles de forma consistente con su nivel de abstraccin. No es tan minimalista que no ofrezca informacin al lector sobre los aspectos importantes de la semntica. Cuando se dibuja un diagrama de casos de uso: Hay que darle un nombre que comunique su propsito. Hay que distribuir sus elementos para minimizar los cruces de lneas. Hay que organizar sus elementos espacialmente para que los comportamientos y roles semnticamente cercanos se encuentren cercanos fsicamente. Hay que utilizar las notas y los colores como seales visuales para llamar la atencin sobre las caractersticas importantes del diagrama. Hay que intentar no mostrar demasiados tipos de relaciones.
Pgina de 97
88
CAPITULO 18 DIAGRAMA DE ITERACION

Los diagramas de secuencia y los diagramas de colaboracin ambos llamados Diagramas de Interaccin, son dos de los cincos tipos de di agramas de UML aspectos dinmicos del sistema Qu es una Interaccin? Es el conjunto de mensajes intercambiados por los roles de clasificador a travs de los roles de asociacin. Un mensaje es una comunicacin unidireccional entre dos objetos, un flujo de objeto con la informacin de un remitente a un receptor. Un mensaje puede tener parmetros que transporten valores entre objetos. Un mensaje puede ser una seal (comunicacin explcita entre objetos, con nombre y asncrona) o una llamada (la invocacin sncrona de una operacin con un mecanismo para el control, que retorna posteriormente al remitente). Un patrn de intercambios de mensajes que se realizan para lograr un propsito especfico es lo que se denomina una interaccin. Lo diagramas dinmicos son: Diagrama de secuencia, Diagrama de colaboracin: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envan entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de informacin, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interaccin. Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son tiles en sistemas que reaccionen a eventos. Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. que se utilizan para modelar los
Pgina de 97
89
Existen dos tipos de diagramas de interaccin: El Diagrama de Colaboracin y el Diagrama de Secuencia. El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones, muestra la secuencia explcita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseo de procedimientos. El diagrama de Colaboracin puede obtenerse automticamente a partir del correspondiente diagrama de Secuencia (o viceversa). Normalmente los diagramas de interaccin contienen: Objetos Enlaces Mensajes Un diagrama de Interaccin es bsicamente una proyeccin de los elementos de una
Nota:
interaccin. La vista de interaccin describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripcin de un objeto, que desempea un determinado papel dentro de una interaccin, distinto de los otros objetos de la misma clase. Esta visin proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a travs de muchos objetos. La vista de interaccin se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes. Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones.
Pgina de 97
90
Diagrama de Secuencia concreto.
Muestra la secuencia de mensajes entre objetos durante un escenario
Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En particular muestra los objetos participantes en la interaccin y la secuencia de mensajes intercambiados. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso. Un diagrama de secuencia muestra secuencias en el tiempo como dimensin geomtrica, pero las relaciones son implcitas. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interaccin. En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si se desea). Con frecuencia slo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin horizontal de los objetos no tiene ningn significado. Ejemplo:
Pgina de 97
91
Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se sitan en la parte superior de la pantalla, normalmente en la izquierda se sita al que inicia la accin. De estos objetos sale una lnea que indica su vida en el sistema. Esta lnea simple se convierte en una lnea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando el esta activo. Diagramas de colaboracin Un diagrama de colaboracin no muestra el tiempo como una dimensin aparte, por lo que resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Un diagrama de colaboracin es tambin un diagrama de clases que contiene roles de clasificador y roles de asociacin en lugar de slo clasificadores y asociaciones. Los roles de clasificador y los de asociacin describen la configuracin de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la colaboracin. Cuando se instancia una colaboracin, los objetos estn ligados a los roles de clasificador y los enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces temporales. Un uso de un diagrama de colaboracin es mostrar la implementacin de una operacin. La colaboracin muestra los parmetros y las variables locales de la operacin, as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de seales del programa. Un diagrama de colaboracin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales estn menos claras. Es til marcar los objetos en cuatro grupos: los que existen con la interaccin entera; los creados durante la interaccin (restriccin {new}); los destruidos durante la interaccin (restriccin {destroyed}); y los que se crean y se destruyen durante la interaccin (restriccin {transient}). Pgina de 97 Ing. Juan Manuel Mrquez Vite 92
Aunque las colaboraciones muestran directamente la implementacin de una operacin, pueden tambin mostrar la realizacin de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles mltiples que los objetos pueden desempear en varias operaciones. Mensajes Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un nmero de secuencia, una lista opcional de mensajes precedentes, una condicin opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencial mente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explcita. Flujos Generalmente, un diagrama de colaboracin contiene un smbolo para un objeto durante una operacin completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explcitos.
Tcnicas comunes de Modelado MODELADO DE FLUJOS DE CONTROL POR ORDENACIN TEMPORAL Para modelar un flujo de control que discurre entre objetos y roles se utiliza un diagrama de interaccin: Para modelar un flujo de control por ordenacin temporal: Hay que establecer el contexto de la interaccin Hay que establecer el escenario de la interaccin, identificando que objetos juegan un rol de ellas. Hay que establecer la lnea de vida de cada objeto Pgina de 97 Ing. Juan Manuel Mrquez Vite 93
A partir del mensaje que inicia la interaccin hay que ir colocando los mensajes subsiguientes.
MODELADO DE FLUJOS DE CONTROL POR ORGANIZACIN Para modelar un flujo de control por organizacin: Hay que establecer el contexto de la interaccin Hay que establecer el escenario de la interaccin, identificando que objetos juegan un rol de ellas. Hay que establecer las propiedades iniciales de cada uno de los objetos. Hay que especificar los enlaces entres esos objetos, junto a los mensajes que pueden pasar.
Ingeniera directa o Inversa (Creacin de cdigo a partir de un modelo) es posible para los diagramas de secuencia como los de colaboracin.
Pgina de 97
94
CAPITULO 19 DIAGRAMA DE ACTIVIDADES

El Diagrama de Actividad es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: Un mtodo Un caso de uso Un proceso de negocio (Workflow) Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecucin de una operacin. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecucin de un sistema, sin profundizar en los detalles internos de los mensajes. Los parmetros de entrada y salida de una accin se pueden mostrar usando las relaciones de flujo que conectan la accin y un estado de flujo de objeto. Un grafo de actividades contiene estados de actividad que representa la ejecucin de una secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminacin de su cmputo. Cuando la actividad termina, entonces la ejecucin procede al siguiente estado de actividad dentro del diagrama. una transicin de terminacin es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explcitos, peor pueden ser abortados por transiciones en estados que los incluyen. Un grafo de actividades puede contener tambin estados de accin, que son similares a los de actividad pero son atmicos y no permiten transiciones mientras estn activos. Los estados de accin se deben utilizar para las operaciones cortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, as como divisiones de control en hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir de la agregacin, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultneamente o en Pgina de 97 Ing. Juan Manuel Mrquez Vite 95
cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia adems del control secuencial. Notacin Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripcin de actividad. Las transacciones simples de terminacin se muestran como flechas. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con mltiples flechas de salida etiquetadas. Una divisin o una unin de control se representan con mltiples flechas que entran o salen de la barra gruesa de sincronizacin. Cuando es necesario incluir eventos externos, la recepcin de un evento se puede mostrar como un disparador en una transicin, o como un smbolo especial que denota la espera de una seal. A menudo es til organizar las actividades en un modelo segn su responsabilidad. Esta clase de asignacin puede mostrarse organizando las actividades en regiones distintas separadas por lneas en el diagrama. Debido a su aspecto, esto es conocido como Calles. Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se dibuja una flecha con lnea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con lnea discontinua desde el objeto a una actividad.
Pgina de 97
96
Pgina de 97
97

Resumen Uml

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Resumen Uml

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO PLITECNICO NACIONAL ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA

SECCION DE ESTUDIOS DE POSGRADO

MAESTRIA EN CIENCIAS EN INGENIERIA DE SISTEMAS

SISTEMAS DE INFORMACION ORIENTADOS A OBJETOS

EL LENGUAJE UNIFICADO DE MODELADO

ING. JUAN MANUEL MRQUEZ Marzo, 2003

EL LENGUAJE UNIFICADO DE MODELADO

GRADY BOOCH JAMES RUMBAUGH IVAR JACOBSON

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

El LENGUAJE UNIFICADO DE MODELADO

Ing. Juan Manuel Mrquez Vite

CAPITULO 1 POR QU MODELAMOS

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

CAPITULO 2 PRESENTACIN DE UML

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

Origen Tamao Abrir() Cerrar() Mover() Dibujar()

Ing. Juan Manuel Mrquez Vite

GestorEventos Suspender() VaciarCola()

empaquetamiento fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones.

Elementos de agrupacin descomponerse un modelo. Pgina de 97

Reglas del negocio

Devuelve una copia del objeto receptor Nota

RELACIONES EN UML Primero Dependencia

elemento independiente puede afectar a la semntica del otro elemento dependiente

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

+ Ejecutar() + Rollback() # prioridad()

Nombre Direccin telfono

Mecanismos de Extensibilidad son: Estereotipos Valores etiquetados Restricciones

extiende las propiedades de un bloque de construccin de UML, permitiendo aadir

Ensamblado del sistema Gestin de configuraciones

Vista de Casos de uso Vista de procesos Vista de Despliegue

Funcionamiento Capacidad De crecimiento, rendimiento

Modelado de la arquitectura de un sistema

Topologa del sistema, Distribucion, Entrega instalacin

Ing. Juan Manuel Mrquez Vite

Captulo 3 Hola, Mundo

g.drawString (Hola, Mundo!, 10,10)

Ing. Juan Manuel Mrquez Vite

Applet HolaMundo Paint () Graphics

Ing. Juan Manuel Mrquez Vite

MODELADO ESTRUCTURAL BASICO

Ing. Juan Manuel Mrquez Vite

Figura Atributos origen Mover() Suspender() VaciarCola()

Ing. Juan Manuel Mrquez Vite

Cliente atributos nombre direccin telfono

Cliente Nombre: char Direccin: char Clave: int

Ing. Juan Manuel Mrquez Vite

Alta Bajas cambios

-Solicitar pedidos -Presentar documentacin

2.Identificar responsabilidades para cada una de las clases

4.Equilibrar las responsabilidades para que ninguna clase en colaboracin

Ing. Juan Manuel Mrquez Vite

Ing. Juan Manuel Mrquez Vite

Pelcula/Video Reproducir() Iniciar() Canal

Figura origen Mover cambiarTamao() dibujar()

cuadrado Clase hoja

Binaria Asociaciones N-arias

Ing. Juan Manuel Mrquez Vite

En UML se muestran normalmente en los diagramas de clases.