Introduccin a UML

Antologa elaborada por: ISC. Cesar Antonio Colocia Garca

Introduccin a UML

CONTENIDO.

Fundamentos Modelado de software Historia y evolucin de UML UML y el paradigma orientado a objetos Vistas de UML La vista esttica La vista de casos de uso La vista de la mquina de estados La vista de interaccin La vista fsica Bibliografa

2 2 4 12 18 21 34 40 45 50 54

-1-

Introduccin a UML

FUNDAMENTOS Ingeniera de Software Es el conjunto de mtodos, tcnicas y herramientas que controlan el proceso integral del desarrollo de software y suministra las bases para construir software de calidad de forma eficiente en los plazos adecuados. Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin. La concepcin define le alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. La construccin crea el producto y la transicin transfiere el producto a los usuarios. Modelado de software El modelado de software es una tcnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Adems, los modelos de un nivel de abstraccin mayor pueden utilizarse para la comunicacin con el cliente. Por ltimo, las herramientas de modelado y la Ingeniera de Software pueden ayudar a verificar la correccin del modelo. Modelado: es el diseo de un software antes de su codificacin, es la visualizacin de lo que se quiere construir. Diagrama: una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos.

-2-

Introduccin a UML

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos

-3-

Introduccin a UML

Historia y evolucin de UML Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de informacin. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnologa de informacin OO. El OMG tiene como objetivo central la promocin, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnologa OO. Una de las especificaciones ms importantes es la adopcin en 1998 del Lenguaje de Modelado Unificado o UML (del ingls Unified Modeling Language) como un estndar, que junto con el Proceso Unificado estn consolidando la tecnologa OO. El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa Rational", donde confluyen los tres grandes del paradigma OO: Grady Booch, James Rumbaugh e Ivar Jacobson [M&R 1998]. El Proceso Unificado gua a los equipos de proyecto en cmo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas. Proceso Unificado y MSF; complementos tecnolgicos Segn [M&R 1998], "ms que una metodologa, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guan a una organizacin sobre como ensamblar los recursos, el personal y las tcnicas necesaria para asegurar que su infraestructura tecnolgica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los objetivos de negocio y las implementaciones tecnolgicas". "MSF se puede utilizar por s mismo o con otras herramientas y tcnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida" [M&R 1998]. "El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es el UML" [M&R 1998]. MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la gua detallada para el desarrollo de software minimizando los riesgos.

-4-

Introduccin a UML

El Proceso Unificado ha adoptado un enfoque que se caracteriza por: Interaccin con el usuario continua desde un inicio Mitigacin de riesgos antes de que ocurran Liberaciones frecuentes Aseguramiento de la calidad Involucramiento del equipo en todas las decisiones del proyecto Anticiparse al cambio de requerimientos El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de rehus. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa [M&R 1998]:

Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organizacin y de cmo son apoyados por una infraestructura tecnolgica basada en servicios. Arquitectura de Aplicacin Adopta un modelo de aplicacin de toda la empresa para disear y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Informacin Define qu informacin es necesaria para apoyar el proceso de negocios y como poner esa informacin eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnolgica Define los estndares y guas para la adquisicin y despliegue de herramientas, bloques de construccin de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeo para crear soluciones ms rpido, mejor y ms baratas. El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace nfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona ms detalle y gua para algunos de los roles en el proyecto. Una vista arquitectnica es "una descripcin simplificada (una abstraccin) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch 1998]. Segn el mismo autor, las caractersticas primordiales del Proceso Unificado son: Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontacin de riesgos

El Proceso Unificado es un proceso porque "define quin est haciendo qu, cundo lo hacer y cmo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson 1998]. Segn [Booch 1998], los conceptos clave del Proceso Unificado son:

-5-

Introduccin a UML

Fase e iteraciones Flujos de trabajo de procesos (actividades y pasos) Artefactos (modelos, reportes, documentos) Trabajador: un arquitecto El ciclo de vida del software en el Proceso Unificado

Cundo se hace? Qu se est haciendo? Qu se produjo? Quin lo hace?)

Las fases del ciclo de vida del software son: concepcin, elaboracin, construccin y transicin. La concepcin es definir el alcance del proyecto y definir el caso de uso. La elaboracin es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin es crear el producto y la transicin es transferir el producto a sus usuarios [Booch 1998]. En la fase de concepcin se especifica la visin del proyecto y el caso de negocio. Las tareas fundamentales de esta fase son: visin del sistema y alcance del sistema, esbozar y clarificar la funcionalidad del sistema, viabilidad del proyecto y plan de proyecto. En la fase de elaboracin es donde se construye un prototipo arquitectnico y de interfaz de usuario. Las tareas bsicas a realizar en esta fase son las siguientes: plan de la iteracin, riesgos y objetivos; casos de uso que conducen la arquitectura, prototipo de interfaz de usuario, divisin inicial en subsistemas, casos de uso en detalle, decidir el diseo, definir interfaces formales, y planificar las pruebas de integracin y sistema. La fase de construccin es la de implementacin del sistema, donde se construye el producto, llevando al software desde una base arquitectnica ejecutable hasta su disponibilidad para los usuarios. Las tareas de esta fase son: planificar la implementacin / integracin y las pruebas del sistema, desarrollar cdigo y probar unidades, integrar y probar subsistemas, y probar la integracin y el sistema en conjunto. En la fase de transicin el software es puesto en manos de los usuarios, se les da formacin, etc. Una vez se completan las cuatro fases se produce una versin del producto preparada para su entrega. El contenido de cada entrega es el siguiente: requisitos, especificaciones no funcionales, casos de uso, modelo visual (UML), modelo de la arquitectura, casos de prueba, cdigo fuente, manuales y otros productos asociados.

Segn [Microsoft 1997], el diseo de software se realiza a tres niveles: conceptual, lgico y fsico.

Diseo Conceptual El diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo

-6-

Introduccin a UML

lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la informacin Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa Una forma de obtener estos requerimientos es construir una matriz usuariosactividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin. Diseo Lgico El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios. Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters. Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente: Ser seguro, lo que equivale a un uso correcto y con autorizacin Ser vlido, qu tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catlogo de servicios que constituye un repositorio de servicios. Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen: Una verificacin independiente: o Pre y post condiciones o Lgica y funcionalidad individual Una verificacin dependiente: o Verificacin de dependencias o Que operan como una unidad especfica de trabajo El diseo lgico comprende las siguientes tareas: Identificar y definir los objetos de negocio y sus servicios Definir las interfases Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interfase tiene las siguientes partes: Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final

-7-

Introduccin a UML

Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente: Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulacin de tiempo crtica Considerar algn problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a travs de la ubicacin Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocio La validacin del modelo lgico debe ser tal que ste sea: Completo debe representar todos los escenarios de uso, Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual, y Claro los objetos de negocio y servicios no deben ser ambiguos En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son: Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin. Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes: Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla) Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados)

-8-

Introduccin a UML

Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive). Bloqueo (permite al acceso concurrente a los datos) Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

Diseo fsico El diseo fsico traduce el diseo lgico en una solucin implementable y costoefectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son: Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo). El diseo fsico debe involucrar: El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red. El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso) El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud. El diseo con el manejo de errores y prueba de eventos: o Validando los parmetros- a la entrada antes de continuar con cualquier proceso. o Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria. o Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos. o Debugging crear una versin para limpiar errores. o Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.

-9-

Introduccin a UML

Figura 3. Arquitectura fsica de tres capas de la aplicacin cliente/servidor

El diseo fsico comprende las siguientes tareas: Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico De las tareas anteriores la ms importante es la distribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica.

-10-

Introduccin a UML

Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porcin de la base de datos maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar qu tan viejos son los datos. Una rplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio local. No se permiten actualizaciones en la base de datos rplica y en la base de datos maestra a la vez, por lo que debe de haber sincronizacin entre ambas. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas.

-11-

Introduccin a UML

UML y el Paradigma Orientado a Objeto. El Paradigma Orientado a Objetos Antes de analizar los pasos del proceso de desarrollo de software en UML se expondrn los conceptos fundamentales del paradigma que gua la tecnologa OO. Existen conceptos ligados en torno a la tecnologa orientada a objetos: el paradigma, los principios, el anlisis y el diseo, mismos que a continuacin se comentan. La Programacin Orientada a Objetos La Programacin Orientada a Objetos (OOP por sus siglas en ingls de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofa, de la cual surge una cultura nueva que incorpora tcnicas y metodologas diferentes. Pero estas tcnicas y metodologas, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontolgica: el universo computacional est poblado por objetos, cada uno responsabilizndose por s mismo, y comunicndose con los dems por medio de mensajes" [Greiff 1994]. Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodologa (coleccin de caractersticas para la ingeniera de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP ms a una metodologa, que al paradigma. De aqu que "el inters en la OOP radica ms en los mecanismos que aporta para la construccin de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994]. La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia" [Greiff 1994]. Fundamentos de lo Orientado a Objetos El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto. En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstraccin, encapsulacin, modularidad y jerarqua, fundamentalmente, y en menor grado tipificacin (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

-12-

Introduccin a UML

Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia . Es la propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

Segn [Booch 1986], los beneficios del enfoque OO son: Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente Java] . Segundo, el uso del modelo OO alienta el rehus no solo del software, sino de diseos completos. Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa. El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad. Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su nica funcin es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actan entre s mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, ste tomar las acciones para ejecutar o no el mensaje, de manera apropiada. [Greiff 1994] comenta que el Anlisis Orientado a Objetos (OOA por sus siglas en ingls de Object Oriented Analysis) "es un mtodo de anlisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Segn [Booch 1986], el Diseo Orientado a Objetos "es un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico tal como los modelos estticos y dinmicos del sistema bajo diseo". En cuanto a las metodologas OO, diremos que hay un gran nmero de mtodos orientado a objetos actualmente. Muchos de los mtodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientacin a objetos. Algunos de las metodologa ms conocidas y estudiadas hasta antes del UML segn [Jacobson 1992] son: Object-Oriented Design (OOD), Booch.

-13-

Introduccin a UML

Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

Actualmente las metodologas ms importantes de anlisis y diseo de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group. Que es UML? El lenguaje UML (en ingls, Unified Modeling Language) es un lenguaje para la especificacin, visualizacin, construccin y documentacin de las partes de un sistema de software. Consiste en una coleccin de las mejores prcticas de ingeniera que mostraron ser exitosas en el modelamiento de sistemas complejos, a tal punto que muchas empresas estn actualmente incorporando UML para el desarrollo de sus productos. Fu creado en 1996, por el Object Mangement Group1 con sucesivas modificaciones y agregados para permitir mayor funcionalidad, gracias al aporte y la participacin de empresas como IBM, Hewlett Packard, Microsoft, Unisys y Oracle, entre otras. UML es un lenguaje predominantemente visual, que consiste de varios diagramas, cada uno modelando un parte esencial del sistema a construir. La especificacin completa de UML incluye doce diagramas, divididos en tres categoras. Cuatro diagramas son utilizados para representar la estructura esttica de la aplicacin en desarrollo, cinco diagramas representan diferentes aspectos del comportamiento dinmico y tres representan la forma en que se organizan los mdulos de la aplicacin. Nos centraremos aqu nicamente en el Diagrama de Clases y Casos de Uso, el cual nos permite disear la estructura del programa en funcin de las clases que lo componen, as como la operacin y comportamiento de las clases. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Diagramas de Casos de Uso para modelar los procesos business. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema. Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementacin para modelar la distribucin del sistema. UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos.

-14-

Introduccin a UML

Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares. En 1996, el Object Management Group (OMG), un pilar estndar para la comunidad del diseo orientado a objetos, public una peticin con propsito de un metamodelo orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versin 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versin 1.1. El OMG est actualmente en proceso de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1 de abril de 1999. UML ofrece notacin y semntica estndar UML preescribe una notacin estndar y semnticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseo orientado a objetos podra haber sido modelado con cualquiera de la docena de metodologas populares, causando a los revisores tener que aprender las semnticas y notaciones de la metodologa empleada antes que intentar entender el diseo en s. Ahora con UML, diseadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseos de los otros. UML no es un Mtodo Aun as, UML no preescribe un proceso o mtodo estndar para desarrollar un sistema. Hay varias metodologas existentes; entre las ms populares se incluyen las siguientes: Catalysis: Un mtodo orientado a objetos que fusiona mucho del trabajo reciente en mtodos orientados a objetos, y adems ofrece tcnicas especficas para modelar componentes distribuidos. Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson. Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos, modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor countinan actualizando su mtodo continuamente (la actualizacin ms reciente es el OOA96 report), y recientemente publicaron una gua sobre cmo usar la notacin UML con Shlaer/Mellor. Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un mtodo de diseo orientado a objetos estndar. Combina OMT y Booch con tarjetas CRC y mtodos formales. OMT: La Tcnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseo y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un mtodo que propone anlisis y diseo iterative, ms centrado en el lado del anlisis. Booch: Parecido al OMT, y tambin muy popular, la primera y segunda edicin de "Diseo Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, UIT Applications), detallan un mtodo ofreciendo tambin diseo y anlisis iterative, centrndoso en el lado del diseo. Adems, muchas organizaciones han desarrollado sus propias metodologas internas, usando diferentes diagramas y tcnicas con orgenes varios. Ejemplos son el mtodo Catalyst por Computer Sciences.

-15-

Introduccin a UML

Corporation (CSC) o el Worlwide Solution Design and Delivery Method (WSDDM) por IBM. Estas metodologas difieren, pero generalmente combinan anlisis de flujo de trabajo, captura de los requisitos, y modelado de negocio con modelado de datos, con modelado de objetos usando varias notaciones (OMT, Booch, etc), y algunas veces incluyendo tcnicas adicionales de modelado de objetos como Casos de Uso y tarjetas CRC. La mayora de estas organizaciones estn adoptando e incorporando el UML como la notacin orientada a objetos de sus metodologas. Algunos modeladores usarn un subconjunto de UML para modelar what theyre after, por ejemplo simplemente el diagrama de clases, o solo los diagramas de clases y de secuencia con Casos de Uso. Otros usarn una suite ms completa, incluyendo los diagramas de estado y actividad para modelar sistemas de tiempo real, y el diagrama de implementacin para modelar sistemas distribuidos. Aun as, Objetivos del UML UML es un lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. UML no pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver requisitos dirigidos por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribucin, as como tambin los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito general. Imponer un estndar mundial. Arquitectura del UML Arquitectura de cuatro capas, definida a fin de cumplir con la especificacin Meta Object Facility del OMG: Meta-metamodelo: define el lenguaje para especificar metamodelos. Metamodelo: define el lenguaje para especificar modelos. Modelo: define el lenguaje para describir un dominio de informacin. Objetos de usuario: define un dominio de informacin especfico. reas conceptuales de UML Los conceptos y modelos de UML pueden agruparse en las siguientes reas conceptuales: Estructura esttica: Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicacin, sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de construcciones es la estructura esttica. Los conceptos de la aplicacin son modelados como clases, cada una de las cuales describe un conjunto de objetos que almacenan informacin y se comunican para implementar un comportamiento. La informacin que almacena es modelada como atributos; La estructura esttica se expresa con diagramas de clases y puede usarse para generar la mayora de las declaraciones de estructuras de datos en un programa.

-16-

Introduccin a UML

Comportamiento dinmico: Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la forma como interacta con el resto del mundo y la otra es por los patrones de comunicacin de un conjunto de objetos conectados, es decir la forma en que interactan entre s. La visin de un objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a los eventos en funcin de su estado actual. La visin de la interaccin de los objetos se representa con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto de vista unifica la estructura de los datos, el control de flujo y el flujo de datos. Construcciones de implementacin: Los modelos UML tienen significado para el anlisis lgico y para la implementacin fsica. Un componente es una parte fsica reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que define una localizacin durante la ejecucin de un sistema. Puede contener componentes y objetos. Organizacin del modelo: La informacin del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que se organice el contenido del modelo en paquetes de tamao modesto. Los paquetes son unidades organizativas, jerrquicas y de propsito general de los modelos de UML. Pueden usarse para almacenamiento, control de acceso, gestin de la configuracin y construccin de bibliotecas que contengan fragmentos de cdigo reutilizable. Mecanismos de extensin: UML tiene una limitada capacidad de extensin pero que es suficiente para la mayora de las extensiones que requiere el sistema sin la necesidad de un cambio en el lenguaje bsico. Un estereotipo es una nueva clase de elemento de modelado con la misma estructura que un elemento existente pero con restricciones adicionales Un Modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos. Un Diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vrtices (otros elementos del modelo). Un diagrama no es un elemento semntico, un diagrama muestra representaciones de elementos semnticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama est contenido dentro de un paquete.

-17-

Introduccin a UML

La mayora de los diagramas de UML y algunos smbolos complejos son grafos que contienen formas conectadas por rutas. La informacin est sobre todo en la topologa, no en el tamao o la colocacin de los smbolos (hay algunas excepciones como el diagrama de secuencia con un eje mtrico de tiempo). Hay tres clases importantes de relaciones visuales: conexin (generalmente de lneas a formas de dos dimensiones), contencin (de smbolos por formas cerradas de dos dimensiones), y adhesin visual (un smbolo que est "cerca" de otro en un diagrama). Estas relaciones geomtricas se reasignan a conexiones entre nodos en un grfico en la forma analizada de la notacin. La notacin de UML est pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todava se representan como conos en una superficie bidimensional. Hay cuatro clases de construcciones grficas que se usan en la notacin de UML: conos, smbolos bidimensionales, rutas y cadenas. Un cono es una figura grfica con un tamao y forma fijos. No se ampla para contener a su contenido. Los iconos pueden aparecer dentro de smbolos de rea, como terminadores en las rutas o como smbolos independientes que puedan o no conectar con las rutas. Los smbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros smbolos. Muchos de ellos estn divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los smbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas. Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topolgica, aunque sus segmentos se pueden manipular grficamente. un segmento no debera existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos. Las cadenas presentan varias clases de informacin en una forma "no analizada", UML asume que cada uso de una cadena en la notacin tiene una sintaxis por la cual pueda ser analizada la informacin del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los smbolos o a las rutas, o como elementos independientes en un diagrama. VISTAS DE UML Una vista es un subconjunto de construcciones de modelado que se enfocan en un aspecto en particular del sistema. Las vistas pueden dividirse en tres reas: clasificacin estructural, comportamiento dinmico, y gestin del modelo. La clasificacin estructural describe los elementos del sistema y sus relaciones con otros elementos. Los clasificadores incluyen clases, casos de uso, componentes, y nodos. Los clasificadores proveen la base sobre la que se construye el comportamiento dinmico.

-18-

Introduccin a UML

Las vistas de clasificacin estructural incluyen: Vista Esttica o Diagrama de Clases Vista de Casos de Uso o Diagrama de Casos de Uso Vista de Implementacin. o Diagrama de Componentes o Diagrama de Despliegue El comportamiento dinmico describe el comportamiento del sistema a travs del tiempo. El comportamiento puede ser descrito como una serie de cambios a fotos del sistema tomadas desde la vista esttica. Las vistas de comportamiento dinmico incluyen: Vista de la Mquina de Estados o Diagrama de Estados (ciclo de vida de objeto) Vista de Actividades o Diagrama de Actividades Vista de Interaccin o Diagrama de Secuencia o Diagrama de Colaboracin La gestin del modelo describe la organizacin de los modelos mismos en unidades jerarquicas. El paquete es la unidad de organizacin para los modelos. Tipos especiales de paquetes son los modelos y subsistemas. Vista de Gestin o Diagrama de Clases (paquetes, subsistemas, modelos)

-19-

Introduccin a UML

rea

Vista

Diagramas Diagrama de Clases

Conceptos Principales Clase, asociacin, generalizacin, dependencia, realizacin, interfaz. Caso de Uso, Actor, asociacin, extensin, generalizacin. Componente, interfaz, dependencia, realizacin. Nodo, componente, dependencia, localizacin. Estado, evento, transicin, accin. Estado, actividad, transicin, determinacin, divisin, unin. Interaccin, objeto, mensaje, activacin. Colaboracin, interaccin, rol de colaboracin, mensaje. Paquete, subsistema, modelo. Restriccin, estereotipo, valores, etiquetados.

Vista Esttica

Estructural

Vista de Casos de Uso Vista de Implementacin Vista de Despliegue Vista de Estados de mquina Vista de actividad

Diagramas de Casos de Uso Diagramas de Componentes Diagramas de Despliegue Diagramas de Estados Diagramas de Actividad Diagramas de Secuencia

Dinmica

Vista de interaccin Diagramas de Colaboracin Gestin de modelo Extensin de UML Vista de Gestin de modelo Todas Diagramas de Clases Todos

Tabla 1. Relacin entre reas, Vistas, y Diagramas de UML

-20-

Introduccin a UML

La Vista Esttica La vista esttica es la base de UML. Los elementos de la vista esttica de un modelo son los conceptos significativos en una aplicacin, incluyendo conceptos del mundo real, conceptos abstractos, conceptos de implementacin, conceptos de computacin y todo tipo de conceptos encontrados en el sistema. Propsitos de la Vista Esttica Captura la estructura de objetos. Es la base sobre la que se construyen las otras vistas. Es un modelo incremental.

Los elementos claves en la vista esttica son los clasificadores y sus relaciones. Clasificadores Clasificador: es un concepto discreto en el modelo que tiene identidad, estado, comportamiento, y relaciones. Un clasificador es un elemento de modelado que describe cosas. Hay varias clases de clasificadores, como las clases, interfaces, y tipos de datos. Los casos de uso son clasificadores que mapean los aspectos de comportamiento. Los propsitos de implementacin implican clasificadores como subsistemas, componentes, y nodos. Un paquete es una unidad de organizacin de uso general para poseer y manejar el contenido de un modelo. Todo elemento del modelo est contenido dentro de un paquete.

Tipos de Clasificadores Clasificadores de elementos del sistema: - Clase - Interfaz - Tipos de datos. Clasificadores de conceptos de comportamiento: - Caso de Uso - Clasificadores de cosas del entorno: - Actor Clasificadores de estructuras de implementacin: - Componente - Nodo - Subsistema

-21-

Introduccin a UML

Clasificador actor

Funcin Un usuario exterior de un sistema Un concepto del sistema modelado.

Smbolo

clase

Nombre

clase-en-estado

Una clase restringida a estar en un estado dado

Nombre[S]

rol clasificador

Un clasificador restringido a un uso particular en la colaboracin

role:Nombre

componente

Un pedazo fsico del sistema

tipo de dato

Un descriptor de un sistema de valor primitivo que carece de identidad Un nombre de las operaciones que caracterizan un comportamiento

nombre

interface

Inombre

nodo

Un recurso de cmputo

seal

Una comunicacin asincrnica entre objetos Un paquete que se trata como unidad con una especificacin, una puesta en prctica, y una identidad Una especificacin del comportamiento de una entidad en su interaccin con los agentes exteriores.

seal

subsistema

subsistema

caso de uso

Clase & Objeto

Objeto = estructura + operaciones + estado interno + identidad. Un objeto es una instancia de una clase.
-22-

Introduccin a UML

Clase: - Conjunto de objetos con estructura, comportamiento, relaciones, y semntica comn. - Representa algo del Dominio del Problema o de la Solucin. Ejemplos - algo fsico Avin - algo del negocio Pedido - un concepto lgico Horario - algo de la aplicacin Window, Botn, Men Tarea, Proceso - algo del comportamiento

Una clase representa un concepto discreto dentro de la aplicacin que se est modelando: una cosa fsica (avin), una cosa de negocios (pedido), una cosa lgica (horario), una cosa de una aplicacin (botn, ventana), una cosa del computador (tabla de hash), o una cosa del comportamiento (una tarea). Una clase es el descriptor de un conjunto de objetos con una estructura, comportamiento y relaciones similares. Un objeto es una entidad discreta con identidad, estado y un comportamiento invocable. El estado es descrito por atributos y asociaciones. Los atributos son valores puros de datos sin identidad. Las asociaciones son conexiones entre objetos con identidad. Las piezas individuales de comportamiento se describen mediante operaciones. Un mtodo es la implementacin de una operacin. Una clase tiene nombre nico dentro de su contenedor, que es generalmente un paquete, pero algunas veces es otra clase. La clase tiene visibilidad con respecto a su contenedor. La visibilidad especifica como puede ser utilizada por otras clases externas al contenedor. Las clases son dibujadas con un rectngulo, dividido en tres partes: el nombre de la clase, los atributos, y las operaciones correspondientes. Puede agregarse tambin una divisin en donde se especifican las responsabilidades de esa clase. Nombre: El nombre de la clase debe ser lo menos ambiguo posible, usualmente un sustantivo. Atributos: Los atributos describen las caractersticas de los objetos. Poseen un tipo, que nos indica qu clase de atributo es. Si bien existen ciertos tipos primitivos, como enteros, booleanos y reales, cualquier tipo puede ser usado, incluso otras clases. La restriccin ms importante es que los atributos son visibles nicamente por la clase que los contiene. La sintaxis de declaracin es la siguiente:

<nombre>:<tipo> < = valor_inicial >

El dato valor_inicial es opcional y permite inicializar los atributos directamente en la declaracin.

-23-

Introduccin a UML

Operaciones: Las operaciones son utilizadas para manipular los atributos o realizar consultas. La sintaxis para describir una operacin es la siguiente: <nombre_operacin> (<parmetros>) : <tipo_resultado>

A diferencia de los atributos, las operaciones pueden tener diferente visibilidad hacia otras clases, la cual se denota entre llaves a la izquierda de la declaracin. Todas las operaciones estn agrupadas de acuerdo a los estereotipos <<comando>>, <<consulta>> o <<constructor>> de acuerdo a su funcin en la clase. Responsabilidades: Las responsabilidades son las obligaciones de una clase y son definidas por el usuario. Si bien existe un compartimiento dentro de la clase para la especificacin de las responsabilidades, stas son de carcter opcional.

<Nombre> <Atributos> <Operaciones> Responsabilidades

cuenta - balance : entero +depositar(monto:int) : void +girar(monto:int):booleand +balance():int

Una clase tiene multiplicidad que especifica cuantas instancias de ella pueden existir. La mayora de las veces puede ser mucho, pero existen clases unitarias de las que solo existe una instancia. Un estereotipo es un mecanismo de extensibilidad para definir meta-clases. Los tres estereotipos ms comunes son objetos entidad, objetos de interface o de frontera, objetos de control.

Esterotipo = mecanismo de extensibilidad para definir meta-clases. - Entidad - Frontera - Control

Objetos entidad Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleado, alumno, etc. Se representan con el estereotipo <<entity>> o se puede utilizar el siguiente cono:

-24-

Introduccin a UML

Empleado

Objetos Interface Representan lo objetos tcnicos requeridos para vincular la aplicacin con el entorno. Representan el vnculo a travs del cual el sistema recibe o suministra datos e informacin al entorno. Tpicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan con el estereotipo <<boundary>> o se puede utilizar el siguiente cono:

UIEmplea

Objetos de control Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. Se representan con el estereotipo <<control>> o se puede utilizar el siguiente cono:

control

Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes caractersticas: Constituye un identificador nico y global para cada objeto dentro del sistema. Es determinado en el momento de la creacin del objeto. Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacin. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque el objeto deje de existir. No se tiene ningn control sobre los oids y su manipulacin resulta transparente. Sin embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos). Caractersticas alrededor de un objeto Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y

-25-

Introduccin a UML

reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto. Persistencia: La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya. Comunicacin: Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen. Categoras de objetos Activos o Pasivos Cliente -- Servidores, Agentes 1. Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad. 2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. 3. Cliente es el objeto que solicita un servicio. 4. Servidor es el objeto que provee el servicio solicitado. 5. Los agentes renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente. Mensajes: La unidad de comunicacin entre objetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin. Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico. Un estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una seal. Un mensaje es la especificacin de un estmulo. Tipos de flujo de control: 1. Llamada a procedimiento o flujo de control anidado 2. Flujo de control plano 3. Retorno de una llamada a procedimiento 4. Otras variaciones 5. Esperado (balking) 6. Cronometrado (time-out) Clases abstractas y concretas Una clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta. Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a travs de la herencia por mltiples clases concretas. En el diagrama una clase abstracta se representa con el esterotipo <<abstracta>>.

-26-

Introduccin a UML

Operaciones Operacin = servicio ofrecido por un objeto. Mtodo = implementacin de una operacin. Una operacin define un servicio ofrecido por un objeto junto con la informacin que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida). Tambin puede contener una especificacin de mtodo, el cual especifica una implementacin para la operacin. Notacin: Durante la etapa de Anlisis o Diseo lgico pueden utilizarse tpicamente texto libre o pseudocdigo. Durante el Diseo fsico dichas especificaciones son trasladadas en un lenguaje de programacin especfico como ser Smalltalk, C++, Java, Visual Basic, etc. Ejemplos: unProceso comenzar. unPedido agregar: unProducto. unaVentana abrir. unaCuenta extraer: unMonto. Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implcitas. Las operaciones implcitas ms importantes son Crear, Destruir, Leer, y Actualizar. Una operacin implcita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales. Un mtodo es la implementacin de una operacin. Se distinguen tres tipos de mtodos: - Mtodos concretos: tienen una implentacin. - Mtodos abstractos: deben ser redefinidos en subclases (mtodos virtuales). - Mtodos templates: son mtodos concretos que se implementan en base a mtodos abstractos. Ejemplo de mtodo template: Movil >> desplazarse x: valx y: valy self posicionX: valx. self posicionY: valy. Movil >> posicionX: x. abstracto Movil >> posicionY: y. abstracto El uso de mtodos abstractos y templates junto con clases abstractas permiten definir estructuras conceptuales, que luego deben especializarse en una estructura de herencia.

-27-

Introduccin a UML

Atributos Atributo = valor que describe un objeto. NO tienen identidad. Son valores de datos asociados a los objetos de una clase al cual describen. Estn fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. La decisin de cuando un tem debe considerarse como atributo o como clase vara de sistema en sistema, dependiendo de su semntica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase. Cada atributo identificado debe ser atmico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. direccin). Un atributo puede ser un tipo de dato o una referencia a otro objeto. En este ltimo caso es la implementacin de una relacin de conocimiento. Atributos identificadores: son atributos o grupos de atributos que identifican unvocamente un objeto de una clase. Se corresponde con el concepto de claves del modelo E-R. Atributos derivados: son atributos cuyo valor puede obtenerse a partir de los valores de otros atributos. Visibilidad Define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado. (+) Pblico : todos (#) Protegido : solo desde el objeto mismo y operaciones definidas en subclases (-) Privado : solo desde el objeto mismo

Dependiendo del nivel de detalle que se desee alcanzar en el modelo, se pueden obviar algunas de las divisiones del grfico de clases. Esto permite simplificar el diagrama completo, de acuerdo al nivel de abstraccin necesario. Puede utilizarse, por ejemplo: Slo el nombre Nombre y atributos
Punto Punto - x: entero; - y: entero; + Punto(x,y:entero) + mover(dist_x,dist_y:entero)

Nombre y operaciones
Punto

-28-

Introduccin a UML

Relaciones Las relaciones entre clasificadores son: Asociacin (conocimiento) Agregacin / Composicin Generalizacin Dependencia Realizacin Uso Flujo Relacin Asociacin Dependencia Flujo Funcin Una descripcin de una conexin entre casos de clases. Una relacin entre dos elementos modelo Una relacin entre dos versiones de un objeto en tiempos sucesivos. Una relacin entre una descripcin ms general y una variedad ms especfica de la cosa general, usadas para la herencia Relacin entre una especificacin y su puesta en prctica. Una situacin en la cual un elemento requiere otro para su funcionamiento correcto. Notacin

Generalizacin

Realizacin Uso

Asociacin Asociacin - conexin semntica entre instancias de clases. - proporciona una conexin entre los objetos para el envi de mensajes. Describe conexiones semnticas entre los objetos individuales de clases dadas. Las asociaciones proporcionan las conexiones, con las cuales los objetos de diversas clases pueden interactuar (relacin de conocimiento). Las restantes relaciones relacionan clasificadores, no instancias. Una asociacin relaciona una lista ordenada (tupla) de dos o ms clasificadores, con las repeticiones permitidas. El tipo mas comn de asociacin es la binaria entre un par de clasificadores. Enlace (link) - instancia de una asociacin. - es una lista ordenada de referencias a objetos. Una instancia de una asociacin es un enlace. Un enlace abarca una tupla (lista ordenada) de objetos. Un enlace binario abarca un par de objetos. Cada conexin de una asociacin a una clase se llama extremo de la asociacin, y alli reside la mayor parte de la informacin de una asociacin.

-29-

Introduccin a UML

Los extremos de la asociacin pueden tener nombres (nombre de rol) y visibilidad. La propiedad ms importante que tienen es cardinalidad. La multiplicidad es ms til para las asociaciones binarias porque para relaciones n-arias se torna muy compleja.

Cardinalidades: - 0 : opcional - 1 : uno - * : muchos - 0..* : cero a muchos - 1..* : uno a muchos Asociacin como clase: una asociacin puede tener atributos por si mismas, en cuyo caso es una asociacin y una clase a la vez. Ejemplo: Una Obra de teatro puede presentarse en distintos Teatros en diferentes fechas y horarios.

Asociacin calificada: Si un atributo de la asociacin es nico dentro de un conjunto de objetos relacionados, entonces es un calificador. Un calificador es un valor que selecciona un objeto nico del conjunto de objetos relacionados a travs de la asociacin. Las tablas de valores y los vectores se pueden modelar como asociaciones cualificadas. Ejemplo: En un directorio un nombre de archivo es un identificador nico ya que no pueden existir dos archivos con el mismo nombre en el mismo directorio (aunque pudiera haber archivos con el mismo nombre pero en distintos directorios. El atributo nombre de archivo de la clase Archivo es un calificador de la relacin.

Otro ejemplo: una presentacin tiene muchas entradas las que se pueden diferenciar por su nro.de butaca cuando la presentacin sea con entradas numeradas.

-30-

Introduccin a UML

Durante el anlisis las asociaciones representan relaciones lgicas entre objetos, no direccionales. Durante el diseo las asociaciones capturan las decisiones de diseo sobre la estructura de datos as como la separacin de responsabilidades entre clases. Asociacin Ordenada: En una asociacin puede requerirse que uno de los extremos presente algn ordenamiento particular. Ejemplo: una presentacin requiere que las diapositivas que la componen se presente en forma ordenada.

Restriccin: Entre dos clases puede existir ms de una asociacin. Una de ellas puede ser una restriccin de la otra.

Agregacin y Composicin: Una agregacin es una relacin todo-partes donde los objetos de una clase son compuestos por objetos de otra. Por ejemplo un automvil est compuesto por carrocera, motor, ruedas, etc. Una composicin es una forma de asociacin ms fuerte en la cual el compuesto es responsable de gestionar sus partes, por ejemplo asignacin y desasignacion. La composicin implica tres cosas Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto. Ejemplo: una coleccin de obras musicales puede contener diversas obras, pero la misma obra puede pertenecer a ms de una coleccin.

Ejemplo: una computadora es un ensamble (composicin) de partes.

-31-

Introduccin a UML

Los conceptos mas habituales que se pueden modelar como agregaciones son: - Ensamble de partes (ej. una bicicleta). Generalmente un ensamble es una composicin. - Colecciones (ej. un club es una coleccin de miembros. ) - Contenedor contenidos (ej. un aula contiene bancos, pizarron, etc) Generalizacin Propsitos de la generalizacin: 1. Principio de sustitucin de Liskov: Operaciones polimrficas. Una instancia de un descendiente se puede utilizar donde quiera que este declarado el antecesor. 2. Herencia: Permitir la descripcin incremental de un elemento que compartev descripciones con sus antecesores. Esto se llama Herencia. Herencia La herencia es el mecanismo a travs del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otras clases denominadas subclases. La herencia utiliza el principio es un tipo de.... Una subclase puede redefinir las operaciones heredadas. Adicionalmente, una subclase puede definir nuevos atributos, operaciones, y restricciones. Se distingue entre herencia simple y mltiple. La herencia simple se da cuando un subclase hereda de una nica superclase. En el caso de la herencia mltiple, una subclase puede heredar de varias superclases. La decisin de soportar herencia simple o mltiple ha dado lugar a largos debates conceptuales y metodolgicos. Herencia de atributos: no permite redefinicin De operaciones: puede ser redefinida en los descendientes. La representacin grfica en UML es la siguiente:

Realizacin La relacin de realizacin conecta un elemento del modelo, tal como una clase, con otro elemento, tal como una interfaz, que especifica su comportamiento pero no su estructura o implementacin.

-32-

Introduccin a UML

Dependencias Una dependencia indica una relacin semntica entre dos o ms elementos del modelo. Indica una situacin, en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia. Dependencia de traza: una traza es una conexin conceptual entre elementos de diversos modelos, a menudo modelados en diferentes etapas del desarrollo, que carece de semntica detallada. Se utiliza generalmente para seguir la pista de requisitos del sistema, a travs de los modelos.

Dependencia de refinamiento: un refinamiento es una relacin entre dos versiones de un concepto en diversas etapas del desarrollo o en diversos niveles de abstraccin.

Dependencia de derivacin: una dependencia de derivacin indica que un elemento se puede computar a partir de otro elemento. La derivacin, la realizacin, el refinamiento, y la traza, son dependencias de abstraccin; relacionan dos versiones de la misma cosa subyacente. Dependencia de Uso: una dependencia de uso es una declaracin de que el comportamiento o la implementacin de un elemento, afectan al comportamiento o a la implementacin de otro elemento. Dependencia de Acceso: Permiso para un paquete para acceder a los contenidos de otro paquete. Dependencia de Importacin: Permiso para un paquete para acceder a los contenidos de otro paquete y aadir alias de sus nombres en el espacio de nombres del importador. Dependencia de Amistad: es una dependencia de acceso, que permite que el cliente vea incluso el contenido privado del proveedor. Dependencia de Ligadura: una ligadura es una asignacin de valores a los parmetros de una plantilla. Restriccin Una restriccin es una expresin booleana representada como una cadena interpretable en un determinado lenguaje. Para expresar restricciones se puede utilizar el lenguaje natural, notacin de teora de conjuntos, lenguajes de restricciones o varios lenguajes de programacin. UML incluye OCL para expresar restricciones.

-33-

Introduccin a UML

Instancias Una instancia es una entidad de ejecucin con identidad, es decir, algo que puede ser distinguido de las otras entidades en ejecucin. Un objeto es una instancia de una clase. Un enlace es una instancia de una asociacin. La Vista de Casos de Uso Los modelos de objetos son apropiados para representar la estructura de los objetos, sus asociaciones, y como interactan dinmicamente. Sin embargo no son modelos apropiados para capturar y comunicar requerimientos funcionales de la aplicacin, ni para verificar si el modelo de objetos se corresponde con la realidad. El primer modelo del sistema que se debe construir debe ser comprensible tanto para los usuarios como para los desarrolladores. Los modelos de objetos son muy complejos para este propsito. Un sistema real, aunque pequeo, puede consistir de alrededor de 100 objetos. Sistemas ms grandes pueden implicar varios cientos o miles de objetos. Por lo tanto, el primer modelo del sistema no debe ser un modelo de objetos. Debe ser un modelo que describa el sistema, su entorno, y como se relaciona con el mismo. En otras palabras debe describir el sistema tal como se lo ve desde el exterior, con una vista de caja negra. Los casos de uso son una forma de especificar esta vista de caja negra. Un caso de uso es una forma de usar el sistema. El usuario interacta con el sistema interactuando con sus casos de uso. La vista de casos de uso captura el comportamiento del sistema, de un subsistema, o de una clase, tal como se muestra a un usuario desde el exterior. Particiona la funcionalidad del sistema en transacciones significativas para los actores usuarios del sistema. Un caso de uso describe una interaccin como secuencia de mensajes entre el sistema y uno o ms actores.

Actor Un actor es una idealizacin de una persona externa, de un proceso, o de una cosa que interacta con el sistema. Los actores son objetos que residen fuera del sistema, en tanto que los casos de uso son objetos que residen dentro del sistema. Un actor participa en uno o ms casos de uso.

-34-

Introduccin a UML

Un actor puede ser caracterizado por un conjunto de atributos que caracterizan su estado. Los actores pueden ser definidos en jerarquas de generalizacin. Un actor puede ser una persona, otro sistema informtico, o un proceso. Diferencia entre actor y usuario Un usuario es una persona (humana) que usa el sistema de algn modo, en tanto que un actor representa un rol especfico que un usuario puede ejercer. Un usuario puede actuar como instancias de diferentes actores. Los actores son instancias de una clase. Los usuarios son un tipo de recurso que implementan dichas instancias. Ejemplos de actores En un sistema ATM (Cajero automtico) podemos identificar tres tipos de actores: Cliente del banco (actor humano) Operador del CA (actor humano) Sistema del banco (sistema externo) Una misma persona (usuario) puede desempearse como instancia de actor Cliente y como instancia de actor Operador. Caso de uso Un caso de uso es una secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor en particular. Un caso de uso es una unidad coherente de funcionalidad, externamente visible, proporcionada por una unidad del sistema y expresada por secuencias de mensajes intercambiados por el sistema y uno o ms actores. El propsito del caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna del sistema. Los casos de uso cumplen dos funciones importantes: 1) Capturan requerimientos funcionales del sistema: El modelo de casos de uso define el comportamiento del sistema a travs de un conjunto de casos de uso. El entorno del sistema es descrito por un conjunto de actores que usan el sistema a travs de los casos de uso. El modelo de casos de uso es una vista externa del sistema, en tanto que los modelos de objetos son vistas internas del mismo. 2) Estructuran los modelos de objetos en vistas manejables: En orden de manejar la complejidad de un sistema real, es prctico construir modelos de objetos para cada caso de uso con los objetos que participan en dicho caso de uso. Un objeto puede participar en varios casos de uso. Esto significa que el modelo de objetos completo se obtiene a partir de un conjunto de vistas de modelos de objetos, uno por cada caso de uso.

-35-

Introduccin a UML

Pueden definirse todas las responsabilidades de un objeto viendo los roles en que participa en todos los casos de uso. Un caso de uso es especificado por interacciones de UML, y representadas en diagramas de secuencia, diagramas de colaboracin, descripciones de texto informales. Cuando se implementan, los casos de uso son realizados mediante colaboraciones entre clases del sistema. Una clase puede participar en mltiples colaboraciones y por ende en mltiples casos de uso. Una colaboracin es una realizacin de un caso de uso. Los casos de uso tambin se pueden aplicar internamente a unidades ms pequeas de un sistema, tales como subsistemas y clases individuales. Un caso interno de uso representa el comportamiento que una parte del sistema presenta al resto del sistema.

Modelado de casos de uso El modelado de casos de uso es una actividad que se realiza en conjunto con el diseo de la interfaz de usuario, donde participa activamente el usuario quien es el centro de inters. Los usuarios son entrevistados para describir diferentes escenarios de uso (instancias de casos de uso). A medida que se tiene una mejor comprensin de las necesidades del usuario, los bocetos de la interfaz avanzan. Una tcnica til para esto es la realizacin de prototipos. Como identificar y definir secuencias de transacciones? 1) Identificacin a travs de actores 1.1 Identificar los actores que se comunicarn con el sistema. 1.2 Para cada actor considerar: 1.2.1 Cuales son las principales tareas del actor 1.2.2 Qu accesos (lectura o escritura) requiere el actor del sistema 1.2.3 Cuando el actor informar al sistema acerca de cambios fuera del sistema 1.2.4 Cuando el actor ser informado de cambios a travs del sistema 2) Identificacin a travs de eventos: Consiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema:

-36-

Introduccin a UML

2.1 Confeccionar la lista de eventos. 2.2 Asociar una secuencia de transacciones para cada evento identificada. Herramientas de modelado de casos de uso 1) Diagrama de casos de uso 2) Descripcin textual - Camino estndar: es una descripcin secuencial de todas las actividades que deben realizarse en forma normal. No se describe el proceso de excepciones. - Caminos alternativos: Describen casos inusuales de procesamiento y manejos de excepciones o errores. Ejemplo: ATM

Caso de Uso: Extraccin Camino Estndar - Un mensaje de bienvenida est en espera en la pantalla del CA. - El cliente inserta su tarjeta en el CA. - El CA lee el cdigo de la banda magntica y verifica que sea aceptable. - Si la tarjeta es aceptable, el CA solicita al cliente su cdigo PIN. Esperando cdigo PIN: - El cliente ingresa su cdigo PIN. - Si el cdigo PIN es correcto, el CA solicita al cliente el tipo de transaccin a realizar. Esperando tipo de transaccin: - El cliente selecciona <extraccin> y el CA enva el cdigo PIN al Sistema bancario solicitando los datos de la cuenta del cliente. - Los datos de la cuenta recibidos se despliegan en la pantalla. Esperando decisin del cliente: - El cliente selecciona una cuenta y el monto a extraer. - El CA enva al sistema bancario el requerimiento de extraccin. - El CA preparan los billetes a ser dispensados. - El CA imprime el comprobante del movimiento. - Los billetes son dispensados al cliente. Caminos Alternativos La tarjeta no es aceptable: - Si la tarjeta no es aceptable debido a un error en la banda magntica, la tarjeta es expulsada con un bip.

-37-

Introduccin a UML

Cdigo PIN incorrecto: - Si el cdigo PIN es incorrecto, un mensaje de error se desplegar al cliente, dando la opcin de corregir. Extraccin no permitida: - Si el sistema bancario no acepta la extraccin, un mensaje es desplegado al cliente y la tarjeta es expulsada. Cancelacin: - El cliente puede cancelar la transaccin en cualquier momento presionando el botn cancel. Si esto ocurre el CA expulsa la tarjeta y termina la transaccin. Relaciones entre casos de uso Inclusin Un caso de uso incluir en su comportamiento el comportamiento de otro caso de uso base a travs de una relacin de inclusin. Cuando varios casos de uso comparten descripciones similares en orden de evitar redundancia y maximizar reutilizacin se puede extraer dichas secuencias comunes. La secuencia comn es un caso de uso abstracto y no puede instanciarse por si mismo. Los casos de uso que incluyen la secuencia comn son casos de uso concretos y pueden crearse instancias de ellos. La relacin de inclusin es una relacin de dependencia entre casos de uso. La relacin de inclusin reemplaz a la relacin de uso que se usaba originalmente en estos casos.

Extensin Un caso de uso se puede definir como una extensin incremental de un caso de uso base. Un caso de uso se puede definir como una extensin incremental de un caso de uso base. Siempre se instancia un caso de uso base, en tanto las extensiones solo son instanciados bajo determinadas condiciones. No se genera una instancia de una extensin. Su usa la relacin de extensin para: - Partes opcionales de un caso de uso. - Cursos complejos y alternativos. - Subsecuencias que se ejecutan solo bajo ciertas condiciones.

-38-

Introduccin a UML

La relacin de extensin permite un desarrollo incremental, comenzando el desarrollo con casos de uso ms simples e ir agregando comportamientos especficos (extensiones a los caso de uso base).

Inclusin vs. Extensin En lneas generales debe aplicarse la siguiente regla: Secuencias comunes <<inclusin>> Nuevos cursos/opcionales <<extensin>> Generalizacin Un caso de uso se puede especializar en uno o ms casos de uso hijos, utilizando una relacin de generalizacin.

Otro ejemplo:

-39-

Introduccin a UML

La Vista de la Mquina de Estados

La vista de la mquina de estados describe el comportamiento dinmico de los objetos, en un cierto plazo, modelando los ciclos de vida de los objetos de cada clase. Cada objeto se trata como una entidad aislada que se comunica con el resto del mundo detectando eventos y respondiendo a ellos. Mquina de estados Una mquina de estados se representa por un diagrama de estados y de transiciones. Una mquina de estados se une a una clase y describe la respuesta de una instancia de la clase a los eventos que recibe. Una mquina de estados es una vista localizada de un objeto, una vista que lo separa del resto del mundo. Es una buena manera de especificar un comportamiento exacto de los objetos de una clase, pero no es una buena manera de entender el funcionamiento total de un sistema. Para una idea ms amplia de los efectos del comportamiento de un sistema, son ms tiles las vista de interaccin. Evento Un evento es una ocurrencia significativa que tiene una localizacin en tiempo y espacio. Ocurre en un punto del tiempo y no tiene duracin. Cuando utilizamos la palabra evento por s mismo, queremos decir generalmente que es una descripcin de todas las ocurrencias individuales del evento que tienen la misma forma general, del mismo modo que la palabra clase expresa todos los objetos individuales, que tienen la misma estructura. Una ocurrencia especfica de un evento se llama instancia del evento. Los eventos pueden tener parmetros que caracterizan cada instancia del evento. Los eventos se pueden organizar en jerarquas de generalizacin para compartir la estructura comn. Los eventos se clasifican en varios tipos explcitos e implcitos: - eventos de seal - eventos de llamada - eventos de cambio - eventos de tiempo Evento de seal Una seal es una entidad con nombre, que se piensa explcitamente como vehculo de comunicacin entre dos objetos. La recepcin de una seal es un evento para el objeto receptor. Las seales incorporan la comunicacin unidireccional asncrona. Las seales se pueden modelar en diagramas de clases como clasificadores utilizando el estereotipo <<seal/signal>>. Los parmetros de la seal se declaran como atributos.

-40-

Introduccin a UML

Evento de llamada
Un evento de llamada es la recepcin de una llamada por un objeto que elige poner una operacin en ejecucin, como transicin de la mquina de estados. Para el objeto llamador, un evento de llamada es indistinta de una llamada a mtodo ordinaria. El objeto receptor, elige si la operacin ser implementa como un mtodo o como un disparador de un evento de llamada en la mquina de estados. Los parmetros de la operacin son los parmetros del evento.

Evento de cambio
Un evento de cambio es la satisfaccin de una expresin booleana que dependa de ciertos valores de un atributo. Es una manera declarativa de esperar a que una condicin est satisfecha. La diferencia entre una condicin de guarda y un evento de cambio es que una condicin de guarda se evala una vez cuando ocurre el evento disparador de la transicin. Si es falsa la transicin no se activa. Un evento de cambio se evala continuamente hasta que llega a ser verdad, en cuyo caso se dispara la transicin.

Evento de tiempo
Los eventos de tiempo representan el paso del tiempo. Un evento de tiempo se puede especificar de modo absoluto (hora) o de modo relativo (tiempo transcurrido desde). Estado Un estado describe un perodo de tiempo durante la vida de un objeto de una clase. Puede ser caracterizado de tres formas: - conjunto de valores de objeto cualitativamente similares (atributos, relaciones) - perodo de tiempo durante el cual el objeto espera que ocurra un evento - perodo de tiempo durante el cual el objeto realiza alguna actividad

-41-

Introduccin a UML

Transicin Cambio de un estado a otro. Toda transicin tiene un evento disparador, una condicin de guarda, una accin, y un estado destino. Existen dos tipos de transiciones: transicin externa, y transicin interna. Transicin externa Una transicin externa es una transicin que cambia el estado activo. Evento disparador El disparador es un evento cuya ocurrencia permite la transicin. El evento puede tener parmetros que estarn disponibles para una accin en la transicin. Si una seal tiene descendientes, cualquier descendiente de la seal permite la transicin. Los eventos se manejan uno solo a la vez. Condicin de guarda Es una condicin booleana referida a los atributos del objeto o a los parmetros del evento disparador, que se evalua cuando ocurre el evento disparador. Si la expresin se evalua como cierta entonces se dispara la transicin. Transicin de finalizacin Es una transicin que carece de evento disparador explcito. Es accionada por la terminacin de la actividad del estado del que sale. Puede tener una condicin de guarda que se evalua en el momento en que termina la actividad. Accin Cuando se dispara una transicin, su accin (si la hay) es ejecutada. Una accin es un cmputo atmico y breve. A menudo es: - una sentencia de asignacin - una operacin aritmtica - el envo de una seal a otro objeto - la invocacin de una operacin propia - asignacin de valores de retorno - creacin o destruccin de objetos - una secuencia de acciones simples Cambio de estado Cuando se completa la ejecucin de la accin, el estado destino de la transicin pasa a ser el estado activo. Estados anidados Los estados se pueden anidar dentro de otros estados compuestos. Una transicin que deja el estado ms externo es aplicable a todos los estados internos. Acciones de entrada y salida Un estado puede tener acciones que se realicen siempre que se entre o se salga del estado. Si la transicin sale del estado original, entonces su accin de salida se ejecuta antes de la accin de la transicin y de la accin de entrada en el estado nuevo. Transicin interna Una transicin interna tiene un estado origen pero ningn estado destino.

-42-

Introduccin a UML

Si una transicin interna tiene accin, se ejecuta pero no existe cambio de estado. Ejemplo: Pila

Estados Compuestos Un estado compuesto es un estado que se ha descompuesto en subestados secuenciales o concurrentes.

La Vista de Actividades Un grafo de actividades es una forma especial de mquina de estados, prevista para modelar cmputos y flujo de trabajos. Los estados del grafo de actividades representan los estados de ejecucin del cmputo, no los estados de un objeto. Diagrama de actividades Estado de actividad: Se representa como una caja con los extremos redondeados y que contiene una descripcin de la actividad. Transiciones simples: De cada estado de actividad se sale con una transicin simple de terminacin, representada como una flecha. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con mltiples flechas de salida etiquetadas. Divisin/Unin del control: se representan con barras gruesas a donde llegan o salen flechas. Eventos externos: se pueden incluir eventos externos que disparen transiciones. Sin embargo si hay muchas trancisiones dirigidas por eventos externos puede ser preferible utilizar una mquina de estados convencional.

-43-

Introduccin a UML

Calles: se pueden agrupar todas las actividades manejadas por una organizacin del negocio en una pista o calle del grafo. Flujo de objetos: un diagrama de actividades puede mostrar el flujo de objetos como entrada o salida de una actividad. En tal caso se dibuja el objeto, pudindose indicar el estado para representar su evolucin. Para un valor de salida se dibuja una flecha con lnea discontnua desde la actividad al objeto. Para un valor de entrada se dibuja una flecha contnua desde el objeto a la actividad. Actividades y otras vistas Un grafo de actividades no es completo. Muestra una vista parcial de un cmputo o proceso. Debe ser ampliado en una colaboracin donde se muestren todas las operaciones atmicas y las clases que las implementan.

-44-

Introduccin a UML

La Vista de Interaccin Los objetos interactan para implementar el comportamiento del sistema. Esta interaccin puede ser descripta en dos formas complementarias, una centrada en objetos individuales (mquina de estados) y otra en una coleccin de objetos cooperantes. La mquina de estados es una visin estrecha y profunda que se enfoca en cada objeto individualmente. Colaboracin Una colaboracin es una descripcin de una coleccin de objetos que interactan para implementar un comportamiento en un contexto dado. Describe una sociedad de objetos cooperantes ensamblados para llevar adelante algn propsito. Cada colaboracin contiene ranuras que son ocupadas por objetos y links en tiempo de ejecucin. Cada objeto y/o link cumple un rol dentro de una colaboracin. Un objeto puede participar en ms de una colaboracin. Una colaboracin implementa la funcionalidad de un caso de uso dado a travs de una dependencia de realizacin.
Caso de uso Colaboracin

El flujo de mensajes dentro de una colaboracin puede opcionalmente se especificado por una mquina de estados, la cual especifica las secuencias de eventos legales. Los eventos en la mquina de estados representan los mensajes intercambiados entre los roles dentro de la colaboracin. Una colaboracin tiene un aspecto esttico y un aspecto dinmico. El aspecto esttico es similar a la vista esttica, contiene un conjunto de roles y sus relaciones que definen el contexto para el aspecto dinmico. El aspecto dinmico es el conjunto de mensajes intercambiados entre los objetos que ocupan los roles. Tal intercambio de mensajes en una colaboracin es llamada una interaccin. Una colaboracin puede incluir una o ms interacciones. Las interacciones son representadas por diagramas de secuencia o diagramas de colaboracin. Interaccin Una interaccin es un conjunto de mensajes que se intercambian dentro del contexto de una colaboracin por roles de clasificadores (objetos) a travs de enlaces (instancias de asociacin). Cuando una colaboracin existe en tiempo de ejecucin, objetos ocupan los roles de clasificadores e intercambian instancias de mensajes a travs de enlaces (links). Un mensaje es una comunicacin unidireccional entre objetos, un flujo de control con informacin desde un emisor a un receptor. Un mensaje puede tener parmetros. Puede ser una seal (asncrono) o una llamada (sncrono). Los mensajes pueden agruparse en hilos de control secuenciales. Hilos separados representan conjuntos de mensajes concurrentes. La sincronizacin entre hilos es modelada por restricciones entre mensajes en diferentes hilos. Una construccin de sincronizacin puede modelar una bifurcacin (fork) del control, una reunin (join) del control, una ramificacin del control. La secuencia de mensajes puede representarse en dos tipos de diagramas: diagramas de secuencia (se enfocan en la relacin de tiempo) y diagramas de colaboracin (se enfocan en las relaciones entre objetos).

-45-

Introduccin a UML

Diagrama de secuencia Es un grfico bidimensional. La dimensin vertical es el eje de tiempo. La dimensin horizontal muestra los roles de clasificadores que representan objetos individuales en la colaboracin. Cada rol de clasificador es representada por una linea vertical que representa su lnea de vida. Una lnea punteada representa el perodo de existencia del objeto. Una lnea doble representa una activacin del objeto. Un mensaje es representado por una flecha desde la lnea de vida de un objeto hacia la lnea de vida de otro objeto. La secuencia de mensajes est ordenada en forma descendente en el diagrama. Activacin: una activacin es la ejecucin de una operacin. Es representada por una lnea de doble trazo sobre la lnea de vida del objeto que recibe el mensaje. Un objeto activo es un objeto que mantiene la pila de activaciones. Cada objeto activo tiene su propio hilo de control que se ejecuta en paralelo con otros objetos. Los objetos que son llamados por los objetos activos se denominan objetos pasivos. Estos reciben el control solo cuando reciben un mensaje solicitando una operacin.

-46-

Introduccin a UML

Ejemplo para diagrama de secuencia para el caso de uso Extraccin del Cajero Automtico:

Diagrama de colaboracin Un diagrama de colaboracin es un diagrama de clases que contiene roles de clasificador y roles de asociacin (instancias de clases). Los roles de clasificacin y los roles de asociacin describen la configuracin de objetos y links que ocurren cuando una instancia de colaboracin es ejecutada. Cuando una colaboracin es instanciada, los objetos son ligados a roles de clasificador y los links son ligados a roles de asociacin.

-47-

Introduccin a UML

Ejemplo de diagrama de colaboracin para el caso de uso extraccin

Es til agrupar los objetos en una de cuatro categorias: - objetos que existe durante toda la interaccin - objetos creados durante la interaccin (constrain{new}) - objetos destruidos durante la interaccin (constrain{destroyed}) - objetos creados y destruidos durante la interaccin (constrain{transient}) Durante el diseo esto ayuda a determinar como debe fluir el flujo de control dentro de la interaccin. Mensaje Los mensajes son representados con flechas etiquetadas vinculadas a los links. Cada mensaje tiene: - un nro.de secuencia - un nombre y una lista de argumentos - una lista de mensajes predecesores (opcional) - una condicin de guarda (opcional) - un nombre de valor de retorno (opcional) El nro.de secuencia tiene opcionalmente el nro. de hilo de ejecucin. Todos los mensajes dentro del mismo hilo de ejecucin estn numerados secuencialmente. Pueden agregarse detalles como ser tipo de mensajes (sincrnicos o asincrnicos).

-48-

Introduccin a UML

Flujos Generalmente en un diagrama de colaboracin un objeto se representa una sola vez. Sin embargo, si un objeto tiene distintos estados que se deban hacer explicitos (cambio de localizacin, o cambio de asociaciones) el objeto se puede representar mas de una vez vinculando los diferentes smbolos con un flujo etiquetado <<become>> o <<conversin>>. Un flujo <<become>> es una transicin de un estado a otro de un objeto. Se dibuja como una flecha con linea discontinua con el estereotipo <<become>>. Tambien se puede utilizar el estereotipo <<copy>> o <<copia>> que representa una copia de un objeto que a partir de dicho momento es independiente.

Diagramas de Secuencia Vs. Diagramas de Colaboracin Los diagramas de secuencia y de colaboracin muestran las mismas interacciones pero enfatizan distintos aspectos. Los diagramas de secuencia enfatizan la secuencia en el tiempo de los mensajes intercabiados pero no ponen de relieve las relaciones entre los objetos. Los diagramas de colaboracin muestran claramente las relaciones , pero la secuencia de tiempo debe tomarse de los diagramas de secuencia. Patrones Un patrn es una colaboracin parametrizada junto con las pautas sobre cundo utilizarlo. Un parmetro se puede sustituir por diversos valores para producir distintas colaboraciones. El uso de un patrn se representa como una elipse de lnea discontinua conectada con cada una de sus clases por una lnea discontnua, que se etiqueta con el nombre de rol.

-49-

Introduccin a UML

Las Vistas Fsicas Descripcin Importancia -> propsitos de reutilizacin y de rendimiento UML incluye dos tipos de vistas para representar unidades de implementacin: - la vista de implementacin - la vista de despliegue La vista de implementacin muestra el empaquetado fsico de las partes reutilizables del sistema en unidades substituibles llamadas componentes. La vista de despliegue muestra la disposicin fsica de los recursos de ejecucin computacional, tales como computadores y sus interconexiones. Se llaman nodos. Durante la ejecucin los nodos pueden contener componentes y objetos. Componente Def.: Un componente es una unidad fsica de implementacin con interfaces bien definidas pensada para ser utilizada como parte reemplazable de un sistema. Cada componente incorpora la implementacin de ciertas clases del diseo del sistema. Los componentes bien diseados no dependen directamente de otros componentes sino de sus interfaces (bajo acoplamiento). El uso de interfaces permite evitar la dependencia directa entre componentes. La vista de componentes muestra la red de dependencias entre componentes.

Nodo Un nodo es un objeto fsico de ejecucin que representa un recurso computacional (computador). Los nodos pueden tener estereotipos como UCP, dispositivos, y memorias.

-50-

Introduccin a UML

Las asociaciones entre nodos representan lineas de comunicacin. Las asociaciones pueden tener estereotipos para distinguir distintos tipos de enlaces.

La vista de Gestin del Modelo La gestin de modelo consiste en paquetes y relaciones de dependencias entre paquetes. Paquete Un paquete es una parte del modelo. Cada parte del modelo debe pertenecer a un paquete. Los paquetes tienen elementos del modelo tales como clases, maquinas de estado, diagramas de casos de uso, interacciones y colaboraciones, etc. Los paquetes tambien pueden contener otros paquetes. Hay varias maneras posibles de organizar los paquetes en un sistema: por la vista, por funcionalidad, o por cualquier otra base que elija el modelador. Los paquetes son unidades de organizacin jerrquica. Si se eligen bien, los paquetes reflejan la arquitectura de alto nivel de un sistema: su descomposicin en subsistemas y sus dependencias. Dependencias en los paquetes Las dependencias entre los paquetes resumen dependencias entre elementos internos de ellos. Los paquetes se dibujan como carpetas. Las dependencias como trazos discontinuos

-51-

Introduccin a UML

Dependencias de acceso e importacin En general, un paquete no puede tener acceso al contenido de otro paquete. Los paquetes son opacos, a menos que sean abiertos por una dependencia de acceso o de importacin. Dependencia de acceso => el contenido del paquete proveedor puede aparecer en referencias efectuadas por elementos del paquete cliente o paquetes incluidos dentro del paquete cliente. Visibilidad entre paquetes Pblica: un elemento definido con visibilidad pblica dentro de su paquete, puede ser visto desde cualquier otro paquete. Protegida: un elemento definido con visibilidad protegida dentro de su paquete, puede ser visto solamente por los paquetes que son descendientes del paquete que contiene los elementos.. Privada: un elemento definido con visibilidad privada dentro de su paquete, puede ser visto solamente por el paquete que los contiene, y por cualquier paquete anidado en el interior de es paquete. El permiso de acceso y visibilidad apropiada son necesarios para referenciar a un elemento. As para que un elemento en un paquete pueda ver un elemento de otro paquete, el primer paquete debe tener acceso o importar al segundo paquete, y el elemento destino debe tener visibilidad pblica dentro del segundo paquete. Un paquete anidado dentro de otro es parte de su contenedor y tiene acceso completo a su contenido, sin necesidad de accesos. El contenedor sin embargo puede no ver el interior de sus paquetes anidados si no tiene acceso. La dependencia de acceso no modifica el espacio de nombres del cliente ni crea referencias. Solo concede permiso para establecer referencias. La dependencia de importacin se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinnimos de los caminos completos.

-52-

Introduccin a UML

Modelo y Subsistema Un modelo es un paquete que abarca una descripcin completa de una vista particular de un sistema. Proporciona una descripcin cerrada de un sistema a partir de un punto de vista. La relacin de traza es una forma dbil de dependencia entre elementos en distintos modelos, que observan la presencia de una cierta conexin sin implicacin semnticas especficas. Generalmente un modelo se estructura con forma de rbol. El paquete raz contiene anidados en s mismo paquetes que constituyen el detalle completo del sistema desde el punto de vista dado. Un subsistema es un paquete que tiene piezas separadas de especificacin y de realizacin. Representa generalmente la particin del sistema en un lmite funcional o de implementacin. Los modelos y subsistemas se dibujan como paquetes con las palabras clave de estereotipo.

-53-

Introduccin a UML

Bibliografa y referencias

Jude UML

herramienta de modelado. http://www.esm.jp/jude-web/index.html

Manual en lnea de modelado de sistemas con UML

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/ consultado: 27-Sept-2005

Manual de referencia de UML

http://www.lania.mx/biblioteca/manuales/umlrefman.pdf consultado: 27-Sept-2005

UML 2 and the Unified Process : Practical Object-Oriented Analysis and Design by Jim Arlow, Ila Neustadt 2nd Edition Addison-Wesley Object-Oriented Software Engineering: Using UML, Patterns and Java Second Edition (Hardcover) by Bernd Bruegge, Allen H. Dutoit Anlisis y Diseo Orientado a Objetos con UML y el Proceso Unificado Schach, Stephen r. 2 Edicion Mc Graw Hill 2003

-54-