Universidad Catlica de Honduras

Dios Espritu Santo

Ensayo sobre UML

Descripcin General
Herramientas Tecnolgicas Ing. Carlos Vargas
Geovanny Rocha 06/10/2012

Introduccin

A lo largo de los aos, el desarrollo de los proyectos de software causan bastantes confusiones y malas interpretaciones en los requerimientos de los clientes y usuarios, en parte debido a la abundancia de notaciones, metodologas y conceptos que hace que los desarrolladores de sistemas no se pongan de acuerdo en que es lo que realmente estn elaborando. En un esfuerzo para estandarizar las notaciones y procesos a utilizar, se conform un consorcio liderado por la empresa Rational y por las principales empresas del mundo de la industria de la informtica, entre ellas, Microsoft, Oracle, Sun Microsystems, Intellicorp, IBM, AMD y otras, quienes desarrollaron una notacin llamada UML.

Conceptualizacin de UML

UML
(Unifed Modeling Languaje) El lenguaje para modelamiento unificado (UML), es un lenguaje para la especificacin, visualizacin, construccin y documentacin de los artefactos de un proceso de sistema intensivo. Fue originalmente concebido por la Corporacin Rational Software y tres de los ms prominentes mtodologistas en la industria de la tecnologa y sistemas de informacin: Grady Booch, James Rumbaugh, y Ivar Jacobson (The Three Amigos). El lenguaje ha ganado un significante soporte de la industria de varias organizaciones va el consorcio de socios de UML y ha sido presentado al Object Management Group (OMG) y aprobado por ste como un estndar (noviembre 17 de 1997).

Estereotipo UML
Los estereotipos son el mecanismo de extensibilidad incorporado ms utilizado dentro de UML. Un estereotipo representa una distincin de uso. Puede ser aplicado a cualquier elemento de modelado, incluyendo clases, paquetes, relaciones de herencia, etc. Por ejemplo, una clase con estereotipo actor es una clase usada como un agente externo en el modelado de negocio. Una clase patrn es modelada como una clase con estereotipo parame trizado, lo que significa que puede contener parmetros.

Marco Terico
UML es la herramienta grafica que se utiliza para especificar mtodos o procesos realizados por el sistema, por medio de una serie de smbolos. Nos proporciona una serie de herramientas que permiten mostrar el programa en sus diferentes etapas o procesos, delimitarlos y organizarlos de tal forma que sean entendibles por la persona que va a desarrollar el sistema. Cabe destacar que UML no es un lenguaje de programacin, sino el sistema que permite modelar la estructura del programa. Estructura de UML Artefactos para el Desarrollo de Proyectos Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripcin o un software. Los artefactos de UML se especifican en forma de diagramas, stos, junto con la documentacin sobre el sistema constituyen los artefactos principales que el modelador puede observar. Se necesita ms de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas grficos para obtener estos distintos puntos de vista de un sistema: Diagramas de Implementacin. Diagramas de Comportamiento o Interaccin. Diagramas de Casos de uso. Diagramas de Clases. Ejemplo de algunos de los diagramas que utiliza UML. Diagramas de Implementacin Se derivan de los diagramas de proceso y mdulos de la metodologa de Booch, aunque presentan algunas modificaciones. Los diagramas de implementacin muestran los aspectos fsicos del sistema. Incluyen la estructura del cdigo fuente y la implementacin, en tiempo de implementacin. Existen dos tipos: Diagramas de componentes Diagrama de plataformas despliegue

 Diagramas de componentes Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de cdigo fuente, binario y ejecutable. Un componente es un fragmento de cdigo software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilacin. Diagrama de plataformas o despliegue: Muestra la configuracin de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecucin y los objetos que existen en tiempo de ejecucin. En este tipo de diagramas intervienen nodos, asociaciones de comunicacin, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto fsico en tiempo de ejecucin, es decir una mquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formada por otros componentes. Diagramas de Interaccin o Comportamiento: Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos: Diagrama de secuencia. Diagrama de colaboracin. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el perodo durante el que un objeto est desarrollando una accin directamente o a travs de un procedimiento.

En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino. Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples, sncronos, y asncronos. Los diagramas de secuencia permiten indicar cul es el momento en el que se enva o se completa un mensaje mediante el tiempo de transicin, que se especifica en el diagrama. Diagrama de colaboracin Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin similar, pero en una forma diferente. Formando parte de los diagramas de colaboracin nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad. Un enlace es una instancia de una asociacin que conecta dos objetos de un diagrama de colaboracin. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados. Los diagramas de interaccin indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envo de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envan entre objetos pueden ser de distintos tipos, tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos, balking, timeout y asncronos. Durante la ejecucin de un diagrama de colaboracin se crean y destruyen objetos y enlaces. Diagramas de actividad Son similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son

estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema. Diagramas de estado Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisfacen una condicin, desarrolla alguna accin o se encuentra esperando un evento. Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transicin, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el estado del que parte el objeto o interaccin es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transicin. Como en todas las metodologas OO se envan mensajes, en este caso es la accin de la que puede enviar mensajes a uno o varios objetos destino Diagramas de Casos de Uso Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios u otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los elementos del modelo, por ejemplo la relacin y la generalizacin son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser

un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes: Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso Diagramas de Clases Los diagramas de clases representan un conjunto de elementos del modelo que son estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos. Algunos de los elementos que se pueden clasificar como estticos son los siguientes: Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado. En UML una clase es una implementacin de un tipo. Los componentes de una clase son: -Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. -Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza. Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrn definidos segn sus parmetros formales. Las plantillas pueden tener especificados los valores reales para los parmetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podra aparecer su plantilla. Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con una agrupacin de variables y procedimientos globales en forma de declaracin de clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una

declaracin de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programacin. Meta clase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos). Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementacin. Un tipo establece una especificacin de comportamiento para las clases. Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo. Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes: Asociacin: Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o narias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar el nmero de instancias de una clase que participan en una relacin mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociacin que determina los valores que indican cuales son los valores que se asociarn. Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociacin. Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las clases donde el llamado "agregado" indica l todo y el "componente" es una parte del mismo. Composicin:

Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos. Generalizacin: Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber ms de una clase que se comporte como subclase. Dependencia: Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente.

Nuevas caractersticas del UML

Adems de los conceptos extrados de mtodos anteriores, se han aadido otros nuevos que vienen a suplir carencias antiguas de la metodologa de modelado. Estos nuevos conceptos son los siguientes: Definicin de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el meta modelo y constituye un mecanismo de extensin del modelo. Responsabilidades. Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribucin y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniera de proceso de negocios) Clara separacin de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstraccin). Interfaces y componentes.

Lo necesario para usarlo:

El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseo de sistemas, el artefacto especfico para el manejo de requerimientos es el Use Case y los Actores. Qu es un "Use Case"? Jacobson define a los use cases y a los actores como: Los Actores representan lo que interacta con el sistema. Ellos representan a todo lo que necesita intercambiar informacin con el sistema. Las instancias de los actores son los usuarios del sistema, ellos llevan a cabo un nmero de operaciones con el sistema y desarrollan una secuencia de transacciones en comunicacin con el sistema. A esta secuencia de acciones se llama Use case. Los use cases se usan para especificar el comportamiento del sistema sin definir su estructura, la forma de que un modelo de Use cases es realizado en trminos de objetos que son definidos por clases dentro del sistema se puede describir con diagramas de colaboracin. Semntica del Use case Un use case es un tipo de clasificador que representa una unidad coherente de funcionalidad dentro de un sistema, un subsistema, o una clase manifestada por una secuencia de mensajes intercambiados entre el sistema y uno o ms objetos externos (llamados actores) y por acciones que el sistema lleva a cabo. Un Punto de extensin es una referencia a un punto dentro del use case en el que las secuencias de acciones de otros use cases pueden ser insertadas. Cada punto de insercin tiene un nombre nico dentro del use case y adems cuenta con una descripcin del punto de insercin dentro del comportamiento del use case.

Notacin del Use Case Un use case es mostrado como una elipse conteniendo el nombre del use case. Opcionalmente, un estereotipo puede ser colocado arriba del nombre y una lista de propiedades tambin puede ser incluida abajo del nombre. Como es un clasificador, un use case tambin puede tener compartimentos mostrando atributos y operaciones. Los puntos de extensin pueden ser listados en un compartimento del use case con el encabezado puntos de extensin. La descripcin de la localizacin del punto de extensin se da de la manera ms adecuada, usualmente es en forma de texto, pero tambin puede ser dado de otras formas, como el nombre de un estado en una mquina de estados, o una precondicin o postcondicin

El comportamiento de un use case puede ser descrito de maneras muy diferentes, dependiendo de qu es lo ms conveniente: texto libre es comnmente usado, pero mquinas de estados adems de es y mtodos son ejemplos de otras formas de describir el comportamiento del use case. Semntica del Actor Un Actor define un conjunto coherente de roles los cuales pueden ser usados por los usuarios de una entidad cuando interactan con esta entidad. Una actor se considera que juega un rol diferente con relacin a cada use case con el cual acta. Notacin del Actor El icono estndar de un estereotipo de actor es la figura del Mono de palo, con el nombre del actor debajo de la figura. Un actor tambin puede ser representado como una clase con el estereotipo de actor con todos los compartimentos de esta.

Diagramas de Use case

Semntica Los diagramas de Use Case representan a los actores y a los use cases junto con sus relaciones. Los Use Cases representan la funcionalidad de un sistema o subsistema o clase, como es percibido por el exterior del sistema, es decir por sus actores. Notacin Un diagrama de use case es una grfica de actores, un conjunto de use cases, posiblemente algunas interfaces y las relaciones entre estos elementos. Las relaciones son asociaciones entre los actores y los use cases generalizaciones entre los actores y generalizaciones, extensiones e inclusiones entre los use cases.

Ejemplo de Diagrama de use case

Relaciones de los Use cases Hay varias relaciones estndar entre los use cases o entre los actores y los use cases. Asociacin La participacin de un actor en el Use Case. instancias del actor e instancias del use case se comunican entre s. Esta es la nica relacin entre los actores y los Use cases. Extensin una relacin de extensin entre el use case A y el use Case B indica que una instancia del use case B puede ser aumentada (Dependiendo de ciertas condiciones especificadas en la extensin) por el comportamiento de especificado en el Use Case B. El comportamiento es insertado el punto definido como punto de extensin del Use Case B, el cual es referenciado por la relacin externa. Generalizacin Una generalizacin de un use case A hacia el use case B indica que A es una especializacin de B Inclusin una relacin de inclusin del use Case A hacia el Use case B indica que una instancia del use case A tambin contendr el comportamiento especificado por B. El comportamiento es incluido en el punto definido en A

Ejemplo de diagrama de Use case y algunas de sus relaciones

Limitantes de los Use Cases Los use cases, como ya vimos explican el comportamiento requerido de un sistema en la perspectiva del actor. Si analizamos las caractersticas de los requerimientos propuestas en los captulos anteriores. Podemos ver que los use cases pueden definir los requerimientos de: Entorno Al definir quines son los actores se est definiendo el entorno Funcionales Lo que ejecuta el use Case son bsicamente la funcionalidad requerida por el sistema. Interfaces La relacin entre el actor y el use case puede ser refinada para especificar la interface usada por el use case y el actor. Restricciones de diseo Una norma oficial o el uso de cierto tipo de estructura de sistema puede ser especificado en el use case o en los diagramas de colaboracin que realizan dicho use case. Materiales El material que debe de ser usado puede ser definido como un atributo del use case. Pero no de desempeo, ni no funcionales, ni de entrenamiento.

Ejemplo de una limitante de los Use Cases. Las limitantes de los use cases generalmente son tan menores que la mayora de los sistemas no se ven afectados por estas limitantes. Sin embargo, existe un tipo especial de sistema en el cual los use cases aun necesitan evolucionar para conseguir cubrir y especificar plenamente sus requerimientos: Estos son los sistemas de tiempo real. Los sistemas de tiempo real tienen requerimientos particulares que no se encuentran en otros sistemas, un ejemplo de estos requerimientos es:

El Tiempo fuera de servicio (Ejemplo: "No ms de 6 minutos por ao por mquina") La Independencia ("Las fallas de software y hardware sern restablecidas sin intervencin humana")

Conclusiones
En resumen, el modelo UML naci por la necesidad de encontrar formas ms agiles de resolver problemas de desarrollo de software tanto a pequea como a gran escala, por lo tanto la forma de entender este procedimiento grafico nos ayuda en todo el proceso de desarrollo de software tanto el anlisis como en el desarrollo. Mi punto de vista podra decirse segn lo documentado es una forma interesante de desarrollo gil de software aunque se necesitara algo de prctica para poder llevarlo a cabo al pie de la letra.