UMLUML

Un «lenguaje» de Modelado¡No un proceso!¡No un método!

Un «lenguaje» de Modelado¡No un proceso!¡No un método!

Fecha: 20/09/2011Por Byron Quisquinay

Si vamos en búsqueda de un concepto que nos brinde una idea que aclare nuestra mente, con respecto del UML y su papel en el «Proceso de Desarrollo de Software», necesitamos examinar las definiciones de los textos sobre UML:

«Cuando comenzamos a elaborar el Lenguaje unificado de modelado(UML), esperábamos poder producir un medio estándar para expresarel diseño, que no sólo reflejara las mejores prácticas de la industria, sinoque también le restara oscuridad al proceso de modelado de software.Creemos que la disponibilidad de un lenguaje de modelado estándaralentará a más desarrolladores para que modelen sus sistemas de softwareantes de construirlos. Los beneficios de hacerlo son perfectamenteconocidos por la comunidad de desarrolladores»

Fuente: UML gota a gota, Martin Fowler, TRADUCCIÓN, Jaime González V. con Kendall Seott.

¿Qué es?

Fuente: Aprendiendo UML en 24 Horas.

«The OMG Specification states:"The Unified Modeling Language (UML) is a graphical language forvisualizing, specifying, constructing, and documenting the artifacts of asoftware-intensive system.«

Modeling is an essential part of large software projects, which also helps in thedevelopment of medium and small projects. UML can be used to model a variety ofsystems: software systems, business systems, or any other system. With its changes andextensions, UML 2.0 now supports the modeling of business processes much better.»

Fuente: UML 2.0 in Action.

…¿Qué es?

Unified Modeling Language (UML) makes it possible to describe systems with wordsand pictures. It can be used to model a variety of systems: software systems, businesssystems, or any other system. Especially notable are the various graphical charts—usecase diagrams with their stick figures or the widely used class diagrams. While thesediagrams aren't fundamentally new, the worldwide unification of modeling languages isnew with UML, which was standardized by the Object Management Group (OMG), aninternational association that promotes open standards for object-oriented applications(http://www.omg.org). Fuente: UML 2.0 in Action.

¿Entonces?

Lenguaje

• Formas de expresión o comunicación.

Modelado

•Del verbo que expresa la: creación,

formación, organización o

composición.

Diseño

• Del verbo que expresa el: trazo, delineado, esbozo, bosquejo o dibujo.

¿Cuál sería el proceso?Pasemos pues a una revisión tímida del proceso que sigue un Desarrollo de Software…

¿En qué parte del proceso?Un desarrollo es una solución. ¿De qué o solución a qué? Pues a una necesidad del negocio, o bien a un error detectado. Y si esa solución lo permite, se debe Modelar dicha solución y eso en la parte del Diseño.

¿Qué debo entender de todo esto?Que dentro del proceso de «Desarrollo de Software» cuando se esté diseñando la solución, la expresión para la comunicación del modelo de la solución informática, tendrá una parte visual basada en UML.

Entrando pues al UML como herramienta para el Modelado

Con UML se pueden segmentar los modelos gráficos en diagramas, dentro del área por lo regular se emplean los siguientes:

Secuencias

Actividades

Casos de Uso

In any case, UML fulfills at least one of the requirements of business-system modeling: it reflects various views of a business system, in order to capture its different aspects. The various standardized diagram types of UML meet this requirement, because every diagram gives a different view of the modeled business system.

Fuente: UML 2.0 in Action.

Secuencias

Cuando nos embarquemos en el diseño a través de un diagrama de Secuencias, debemos de pensar en los casos de uso que tenemos, con ellos indicaremos la forma en que ellos INTERACTUAN para generar esa solución basada en software.

Entonces, veremos como se pueden interconectar en el tiempo, las funcionalidades, actividades y acciones de una solución informática.

Diagramas de interacción

Los diagramas de interacción son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Habitualmente, un diagrama de interacción capta el comportamiento de un solo caso de uso. El diagrama muestra cierto número de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso. ilustraré este enfoque mediante un caso de uso simple que exhibe el comportamiento siguiente:

• La ventana Entrada de pedido envía un mensaje "prepara" a Pedido.• El Pedido envía entonces un mensaje "prepara" a cada Línea de pedido dentro del

Pedido.• Cada Línea de pedido revisa el Artículo de inventario correspondiente.

o Si esta revisión devuelve "verdadero", la Línea de pedido descuenta la cantidad apropiada de Artículo de inventario del almacén.

o Si no sucede así, quiere decir que la cantidad del Artículo de inventario ha caído más abajo del nivel de re-orden y entonces dicho Artículo de inventario solicita una nueva entrega.

Hay dos tipos de d iagramas de interacción: diagramas de secuencia y diagramas de colaboración.

Fuente: UML gota a gota.

Fuente: Aprendiendo UML en 24 horas.

3.3.7 Sequence Diagrams

UML provides two types of diagrams for the representation of interactions: the sequence diagram and the communication diagram. Both diagrams visualize the exchange of information. However, the emphasis is different: communication diagrams emphasize the relationships of individual objects and their topology; sequence diagrams emphasize the chronological course of exchanged information. In the external view, we opt for the representation through sequence diagrams and do without communication diagrams for two reasons:

• Sequence diagrams are easier to understand for developers and readers. In our practical work in projects we have observed a much higher acceptance of sequence diagrams because of their simplicity.

• We avoid using unnecessarily many diagram types for the same facts. Less is often more!

Like the activity diagrams, sequence diagrams can be modeled spanning several use cases, as well as being used to refine business use cases. A sequence diagram illustrates the various scenarios of a business use case.

Fuente: UML 2.0 in action.

Simbología

Objeto Mensaje

Ejemplos

You begin reading a sequence diagram at the top (1). The starting point on the top left (1) is located on the vertical line that represents the passenger (2) as sender and receiver of messages. The flow begins when the passenger hands over his or her ticket (3) to passenger services for verification (4). The call verify (4) is the message; the ticket (3) that is handed over is the business object. The direction of the arrow indicates that the passenger is the sender of the message and passenger services the receiver (6).

The receipt of the message at passenger services initiates activities, which is indicated by the gray vertical bar (7). The diagram does not show how passenger services handle the process, meaning that it does not show which activities are conducted

Only the comment (5) can include a clue. Comments can be inserted at the left margin of the sequence diagram. An exact description of the processing can be found in the activity diagram 'passenger checks in' (see Figure 3.21 above). In a final step, passenger services issues (8) a boarding pass (9) to the passenger. With that, the interaction that is illustrated in this sequence diagram is completed for both parties. This is indicated by the end of the wide gray vertical bar (10). In the business model we do not utilize all the options of the sequence diagram. UML provides many more possibilities for this diagram type, but our experience showed that this is sufficient to communicate the essential aspects.

…Ejemplos…

…Ejemplos…

…Ejemplos…

Bien, con lo anterior creo que los ejemplos nos permiten tener el panorama del diagrama de secuencias y que será la forma de diseñar la forma en que interactúan los casos de uso las actividades y las acciones para lograr una solución. Si se desea un modo más extendido pero confuso, a continuación diapositivas con esa forma de expresión.

Simbología

Esta línea vertical se llama línea de vida del objeto. La línea de vidarepresenta la vida del objeto durante la interacción. Esta forma fuepopularizada inicialmente por jacobson. Cada mensaje se representa mediante una flecha entre las líneas de vida de dos objetos. El orden en el que se dan estos mensajes transcurre de arriba hacia abajo. Cada mensaje es etiquetado por 10 menos con el nombre del mensaje; pueden incluirse también los argumentos y alguna información de conirol. y se puede mostrar la autodelegación, que es un mensaje que un objeto se envía a sí mismo, regresando la flecha de mensaje de vuelta a la misma línea de vida. Dos partes de la información de control son valiosas. Primero, hay una condición, que indica cuándo se envía un mensaje (por ejemplo, [llecesitaReordellJ). El mensaje se envía sólo si la condición es verdadera. El segundo marcador de control útil es el marcador de iteración, que muestra que un mensaje se envía muchas veces a varios objetos receptores, corno sucedería cuando se itera sobre una colección. La base de la iteración se puede mostrar entre corchetes (como en *[para cada línea de pedido]). Corno se puede apreciar, la figura 6-1 es muy simple y tiene un atractivo visual inmediato; en ello radica su gran fuerza .

Este diagrama induye un regreso, el cual indica el regreso de un mensaje, no un nuevo mensaje. Los regresos difieren de los mensajes normales en que la línea es punteada.

Fuente: UML gota a gota.

La figura 6-2 introduce varios elementos nuevos en los diagramas de secuencia. En primer lugar, se ven las activaciones, que aparecen explícitamente cuando está activo un método, ya sea porque está efectuando operaciones O porque se encuentra esperando la devolución de una subrutina. muchos diseñadores utilizan las activaciones todo el tiempo. A mi juicio, éstas no aportan mucho a la ejecución de procedimientos. Por tanto, s610 las uso en situaciones concurrentes.

Las medias cabezas de flecha indican mensajes asíncronos. Un mensajeasíncrono no bloquea al invocador, por lo cual puede continuarcon su proceso. Un mensaje asíncrono puede hacer alguna de estastres cosas:

1. Crear un nuevo proceso, en cuyo caso se vincula con el principio deuna activación.2. Crear un nuevo objeto.3. Comunicarse con un proceso que ya está operando.

El borrado (deletion) de un objeto se muestra con una X grande. Losobjetos pueden autodestruirse (como se muestra en la figura 6-2).

Ejemplos

Actividades

Si cuando se crea un Diagrama o varios de Casos de Uso, lo que se logra es la representación de las funcionalidades a cubrir con el desarrollo. Entonces el Diagrama de Actividades es el siguiente paso de detalle en el modelado gráfico y será la forma de describir las actividades que esas funcionalidades deben de realizar.

« Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate activities. In the external view, we use activity diagrams for the description of those business processes that describe the functionality of the business system. Contrary to use case diagrams, in activity diagrams it is obvious whether actors can perform business use cases together or independently from one another. »

Fuente: UML 2.0 in Action.

«Este diagrama le muestra los pasos en una operación o proceso.»

«… el UML es en cierta medida un diagrama de flujo con esteroides.»Fuente: Aprendiendo UML en 24

horas.

Los diagramas de actividades son útiles para describir métodos complicados. También pueden servir para otras cosas; por ejemplo, para describir un caso de uso.

Fuente: UML gota a gota.

Simbología …

Acción

Actividad

Acción derivada de una actividad

Acción que espera un evento

Acción que inicia en un «tiempo» determinado

Acción que genera un evento

Límite, flujo o conector de una actividad

Barra de SincronizaciónNodo Inicial

De la actividad

Nodo de finalización de la actividad

Nodo de finalización de un flujo

…Simbología

Límite, flujo o conector de una actividad

Barra de SincronizaciónNodo Inicial

De la actividad

Nodo de finalización de la actividad

Nodo de finalización de un flujo

Nodo de decisión

Actividad

Símbolo que encerrará todas las acciones que definen esa actividad, para parafrasearlo más coloquial, diríamos que es el «cuadro» que permite encerrar las demás figuras que forman parte de una misma actividad. Se pueden poner líneas que lo dividan hacia abajo (vertical) y poner el nombre de la unidad que realiza las acciones, eso restringirá las acciones por unidad de negocio (gerencia, etc.).

• Acción derivada de una actividad: es una acción que viene de una actividad o desde otra acción. Llamándose a sí misma es una actividad, una llamada de fuera es otra actividad.

• Acción que espera un evento: Son aquellas acciones que esperan a que un evento ocurra. Por ejemplo una reversa, entonces se aumenta al saldo.

• Acción que genera un evento: Esta es la acción que envía el evento que la anterior espera.

• Acción que inicia en un tiempo determinado: Son aquellas que a determinada hora inician.

Acción: Es el paso individual de una actividad. Si la actividad es Debitar de una cuenta, una de las acciones a realizar podría ser: restar del

saldo disponible el monto retirado.

Nodo Inicial de actividad

Es el punto inicial de la actividad.

Nodo Final de

actividad

Indica que la actividad está completa. Puede haber más de uno de ellos, puesto que es aceptable que hayan varias formas de finalización o salida.

Nodo final de decisión Que tiene la función del rombo que conocemos de los

diagramas de flujo para poder bifurcar un flujo basado en toma de decisiones.

Límite, flujo o conector

Como en un diagrama de flujo, señala hacia donde se debe dirigir al realizar una acción o componente del diagrama.

Barra de Sincronización

Permite que el flujo de actividades a través de conectores lleguen a otra u otras acciones o componentes del diagrama.

Nodo final de un flujo Permite indicar que un flujo está terminado.

Fuente: aprendiendo UML en 24 horas.

Casos De Uso

Cuando hablamos de un Caso de Uso, nuestra mente debe de fijar esta idea: «Se trata de especificar los aspectos que cubre la solución a diseñar.» Es decir: ¿Qué será capaz de hacer el desarrollo como solución de una necesidad del negocio? Y eso es, un conjunto de Acciones.

«A use case is the specification of a set of actions performed by a system, which yields an observable result that is typically of value for one or more actors or other stakeholders of the system (OMG: Unified Modeling Language: Superstructure, Version 2.0, Revised Final Adopted Specification, October 2004).» Fuente: UML 2.0 in Action.

« Use case diagrams show actors, business use cases, and their relationships.Use case diagrams do not describe procedures. Alternative scenarios alsoremain hidden. These diagrams give a good overview of the functionality ofa business system.» Fuente: UML 2.0 in Action.

Asociación

Caso de Uso

«Include»

Sujeto o Sistema

Simbología

Actor

Actor

Un actor es una persona que interactúa con los Sistemas. Representado con un nombre que asocia a un rol.

Asociación

Es el símbolo que permite relacionar a un actor con un caso de uso. Indicando que el actor puede utilizar cierta funcionalidad o tener parte en una actividad.

Caso de Uso

Básicamente representa una funcionalidad con la que se puede interactuar.

Relación de

Inclusión

Permite expresar la relación entre dos casos de uso. E indica que el caso de uso al que apunta la flecha, está necesariamente incluido cuando se interactúa con un caso de uso.

Sistema o Sujeto

Este símbolo es empleado para representar un sistema al cual se le adjunta un caso de uso.

En los ejemplos anteriores de diagramas de Caso de Uso, se ha querido ejemplificar lo que en el manual indican como la evolución de un diagrama, cuando por primera vez se piensa en lo que debería ser «la solución» y luego cómo madura.

En cuanto a la construcción de un Modelado basado en una vista o visión, empleando un diagrama de Caso de Uso. Lo que hay que respetar es la simbología. Más allá de ello, lo que hay que tener en mente es que Modelar con esta herramienta UML, a través de un diagrama de Casos de Uso es lo que se puede emplear para «comunicar» el diseño de la solución, entonces allí será tu «ingenio» el que te permita poner límites a ese medio de expresión.

«Los casos de uso son la base para la comunicación entre los patrocinadores y los desarrolladores durante la planificación del proyecto. Una de las cosas más importantes en la etapa de elaboración es el descubrimiento de los casos de uso potenciales del sistema en construcción. Por supuesto, en la práctica no va a descubrirlos todos. Sin embargo, querrá encontrar la mayor cantidad posible, en especial los más importantes. Es por esta razón que, durante la etapa de elaboración, deberá programar entrevistas con los usuarios, con el fin de recopilar los casos de uso.»

Fuente: UML gota a gota.

¿Porqué hay herencias, polimorfismos, etc. En el UML y porqué un diagrama de Clases?

• Puesto que es una herramienta que se apega mucho a la programación orientada a objetos. Más sin embargo no es un impedimento para emplearse como medio de expresión gráfica del modelo de la solución.

Hay un «Extends» expresado en los diagramas. ¿Cuándo se usa?• Se usa la relación exlends cuando se tiene un caso de uso que es similar a otro, pero que hace un

poco más. Ejemplo, el caso de uso es Captura negociación. Éste es un caso en que todo sucede sin contratiempos. Sin embargo, hay situaciones que pueden estropear la captura de una negociación. Una de ellas surge cuando se excede algún límite, por ejemplo, la cantidad máxima que la organización de comercio ha establecido para un cliente en particular. En este ejemplo, dado que no efectuamos el comportamiento habitual asociado con dicho caso de uso, efectuamos una variación.

Algunas preguntas y sus respuestas

EXTRAS AL TEMA

DE UML

Clases

Cuando nos encontramos modelando con diagramas de clases, para los desarrollos en Developer y Base de Datos, tenemos que abandonar la idea de la programación orientada a objetos.

Entonces, cuando hablamos de Clases, para los desarrollos Seriales – Modulares – Estructurados – Basados en Base de Datos y PL/SQL, tenemos que «swhitcharnos» al diagrama de Entidad – Relación y no debemos olvidar las reglas de Normalización (si es que aplican).

Entonces aquí es necesario recordar que una Base de Datos es una «Colección de Datos (o información)». Pensemos en nuestra billetera o Cartera – es una base de datos «billetera.world» y qué Entidades o Clases hay, Cuenta_corriente (dinero y tarjetas de crédito – debito), Identificaciones_personales (carnés, cédula, DNI, etc.) imágenes_afectivas (fotos, dibujos, cartas con figuras)… y así sucesivamente.

Una Base de Datos o un Sistema es una abstracción de un conjunto de «objetos o elementos» del Mundo Real, físico y tangible.

Cuando pensemos en Clases o Entidades, pensemos pues en esas categorías en que podemos dividir esos objetos del mundo real y lo que está relacionado estrictamente con esos objetos. Por ejemplo, de un depósito, podemos pensar en Cuentas_efectivo, movimto_diario, movimto_mensual, etc.

Fuente: Aprendiendo UML en 24 horas.

La táctica del diagrama de clase se ha vuelto medular en los métodos orientados a objetos. Virtualmente, todos los métodos han incluido alguna variación de esta técnica. El diagrama de clase, además de ser de uso extendido, también está sujeto a la más amplia gama de conceptos de modelado. Aunque los elementos básicos son necesarios para todos, los conceptos avanzados se usan con mucha menor frecuencia. Por eso, he dividido mi estudio de los diagramas de clase en dos partes; los fundamentos (en el presente capítulo) y los conceptos avanzados (véase el capítulo 5). El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estáticas que existen entre ellos. Hay dos tipos principales de relaciones estáticas:asociaciones (por ejemplo, un diente puede rentar diversas videocintas). subtipos (una enfermera es un tipo de persona). Los diagramas de clase también muestran los atributos y operaciones de una clase y las restricciones a que se ven sujetos, según la forma en que se conecten los objetos.

Fuente: UML gota a gota.

Perspectivas Antes de empezar a describir los diagramas de clase, quisiera señalar una importante sutileza sobre el modo en que se usan. Tal sutileza generalmente no está documentada, pero tiene sus repercusiones en el modo en que debe interpretarse un diagrama, ya que se refiere a lo que se va a describir con un modelo.

• Conceptual. Si se adopta la perspectiva conceptual, se dibuja un diagrama que represente los conceptos del dominio que se está estudiando. Estos conceptos se relacionan de manera natural con las clases que los implementan, pero con frecuencia no hay una correlación directa. De hecho, los modelos conceptuales se deben dibujar sin importar to casi) el software con que se implementarán, por lo cual se pueden considerar como independientes del lenguaje. (Cook y Daniels llaman perspectiva esencial a esto; por mi parte, empleo el término "conceptual", pues se ha usado durante mucho tiempo.)

• Especificación. Ahora estamos viendo el software, pero lo que observamos son las interfaces del software, no su implementación. Por tanto, en realidad vemos los tipos, no las clases. El desarrollo orientado a objetos pone un gran énfasis en la diferencia entre interfaz e implementación, pero esto con frecuencia se pasa por alto en la práctica, ya que el concepto de clase en un lenguaje 00 combina tanto la interfaz como la implementación. Así, a menudo se hace referencia a las interfaces como tipos y a la implementación de esas interfaces como clases. Influidos por este manejo del lenguaje, la mayor parte de los métodos han seguido este camino. Esto está cambiando Gava y CORBA tendrán aquí cierta influencia), pero no con suficiente rapidez. Un tipo representa una interfaz que puede tener muchas implementaciones distintas debido, por ejemplo, al ambiente de implementación, características de desempeño y proveedor. La distinción puede ser muy importante en diversas técnicas de diseño basadas en la delegación; véase el estudio de este tema en Gamma et al. (1994).

• Implementación. Dentro de esta concepción, realmente tenemos clases y exponemos por completo la implementación. esta es, probablemente, la perspectiva más empleada, pero en muchos sentidos es mejor adoptar la perspectiva de especificación.

Cuando usted dibuje un diagrama, hágalo desde el punto de vista de una sola perspectiva clara. Cuando lea un diagrama, asegúrese de saber desde qué perspectiva se dibujó. Dicho conocimiento es esencial si se quiere interpretar correctamente el diagrama.

Fuente: UML gota a gota.

Terminología …

Simbología …

…Simbología …

…Simbología …

Bantrab será la mejor fuerza comercial del sector financiero guatemalteco. Para ello brinda una gama de productos que conforman esa oferta comercial a los consumidores de instrumentos proveídos en el mercado financiero local.

IT pues tiene que proveer las soluciones necesarias para garantizar la prestación de los servicios que hacen posible la existencia de esos Productos Financieros.

Esas soluciones de IT tienen una parte de Los Sistemas de Información, dentro de esos Sistemas tenemos los que en la siguiente diapositiva se presentan.

¿Qué se debe de Comprender por la solución de IT de Bantrab?

Banca

RH

Tarjeta de Crédito

AccionistasAseguradora

DWH

Contabilidad