UML para diseño de software

1. Un «lenguaje» de Modelado
¡No un proceso!
¡No un método!
Fecha: 20/09/2011
Por Byron Quisquinay

2. ¿Qué es?
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 expresar
el diseño, que no sólo reflejara las mejores prácticas de la industria, sino
que también le restara oscuridad al proceso de modelado de software.
Creemos que la disponibilidad de un lenguaje de modelado estándar
alentará a más desarrolladores para que modelen sus sistemas de software
antes de construirlos. Los beneficios de hacerlo son perfectamente
conocidos por la comunidad de desarrolladores»
Fuente: UML gota a gota, Martin Fowler, TRADUCCIÓN, Jaime González V. con Kendall Seott.
Fuente: Aprendiendo UML en 24 Horas.

3. …¿Qué es?
Unified Modeling Language (UML) makes it possible to describe systems with words
and pictures. It can be used to model a variety of systems: software systems, business
systems, or any other system. Especially notable are the various graphical charts—use
case diagrams with their stick figures or the widely used class diagrams. While these
diagrams aren't fundamentally new, the worldwide unification of modeling languages is
new with UML, which was standardized by the Object Management Group (OMG), an
international association that promotes open standards for object-oriented applications
(http://www.omg.org).
Fuente: UML 2.0 in Action.
«The OMG Specification states:
"The Unified Modeling Language (UML) is a graphical language for
visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system.«
Modeling is an essential part of large software projects, which also helps in the
development of medium and small projects. UML can be used to model a variety of
systems: software systems, business systems, or any other system. With its changes and
extensions, UML 2.0 now supports the modeling of business processes much better.»
Fuente: UML 2.0 in Action.

4. ¿Entonces?
Diseño
Lenguaje
•
•
Formas de expresión o comunicación.
Del verbo que expresa el: trazo,
delineado, esbozo, bosquejo o
dibujo.

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

6. ¿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.

7. 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:
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.

9. 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.

10. 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.

11. 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.

12. Simbología
Objeto
Mensaje

13. 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.

14. …Ejemplos…

15. …Ejemplos…

16. …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.

17. Simbología
Esta línea vertical se llama línea de vida del objeto. La línea de vida
representa la vida del objeto durante la interacción. Esta forma fue
popularizada 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.

18. 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 mensaje
asíncrono no bloquea al invocador, por lo cual puede continuar
con su proceso. Un mensaje asíncrono puede hacer alguna de estas
tres cosas:
1. Crear un nuevo proceso, en cuyo caso se vincula con el principio de
una 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. Los
objetos pueden autodestruirse (como se muestra en la figura 6-2).

19. Ejemplos

21. 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.

22. Simbología …
Acción derivada de una actividad
Acción que espera un evento
Acción
Acción que genera un evento
Acción que inicia en un «tiempo» determinado
Actividad
Límite, flujo o conector de una actividad
Nodo Inicial
De la actividad
Nodo de finalización
de la actividad
Nodo de finalización
de un flujo
Barra de Sincronización

23. …Simbología
Límite, flujo o conector de una actividad
Nodo Inicial
De la actividad
Nodo de finalización
de la actividad
Nodo de finalización
de un flujo
Nodo de decisión
Barra de Sincronización

24. 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.).

25.  Es el punto inicial de la actividad.
Nodo
Inicial de
actividad
Nodo Final
de
actividad
Nodo
final de
decisión
 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.
 Que tiene la función del rombo que conocemos de los
diagramas de flujo para poder bifurcar un flujo basado en toma
de decisiones.

26. 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
Nodo
final de
un flujo
 Permite que el flujo de actividades a través de
conectores lleguen a otra u otras acciones o
componentes del diagrama.
 Permite indicar que un flujo está terminado.

33. Fuente: aprendiendo UML en 24 horas.

35. 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 also
remain hidden. These diagrams give a good overview of the functionality of
a business system.» Fuente: UML 2.0 in Action.

36. Simbología
Actor
Asociación
Caso de Uso
Sujeto o Sistema
«Include»

37.  Un actor es una persona que interactúa con los Sistemas.
Representado con un nombre que asocia a un rol.
Actor
Asociación
Caso
de Uso
 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.
 Básicamente representa una funcionalidad con la que se
puede interactuar.

38. 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.

40. 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.

43. Algunas preguntas y sus respuestas
 ¿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.

46. 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.

47. 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.

48. 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.

49. Terminología …

50. Simbología …

51. …Simbología …

52. …Simbología …

53. ¿Qué se debe de Comprender por la solución de
IT de Bantrab?
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.