Manual UML

Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Introducción
Sin duda alguna los lenguajes simbólicos han servido a través del tiempo
para apoyar al Desarrollo del Software; que decir del denominado Diagrama de
Flujo o Diagrama bajo el enfoque de Warnier-Or, utilizado en su momento
para diagramar los procesos que el software a desarrollar hará, o los procesos
previos, en un sistema manual o semimanual, que el software a desarrollar
automatizará.
Y que decir del Diagrama bajo el enfoque de Yourdon, o simplemente
llamado Diagrama de Contexto, usado comúnmente para diagramar los
procesos que se realizarán con una base de datos que apoyará al sistema a
desarrollar. Existen otros más pero los mencionados eran los más frecuentes.
El compendio de prácticas aquí demostradas es un enfoque inteligente
para el apoyo de cómo usar los diferentes diagramas que tiene el UML dentro de
un posible proyecto Informático apoyados en un enfoque de uso dentro de la
Metodología RUP. Este compendio se realiza con el propósito de ahorrar
esfuerzo al lector en la utilización de los diferentes diagramas del UML y así
poder brindar las experiencias y vivencias con este lenguaje, ya que en la
actualidad es uno de los estándares de facto para las fases de Análisis y Diseño
de programas dentro de la Ingeniería Software.
Y ahora, en la actualidad, es el Lenguaje de Modelado Unificado (UML),
el cual es el tema de este documento. Esta obra esta dividida en dos partes, la
primera es un enfoque teórico, para sustentar la información que se mostrará en
la segunda parte, que es el enfoque práctico de este libro.
El capítulo I trata acerca de los Antecedentes e Importancia del UML,
describiendo su concepto, la evolución que ha tenido desde que se creó y la
importancia que ha acaparado dentro de la Ingeniería del Software.
El capítulo II es una visión general del lenguaje, Tratando acerca del
modelo orientado a objetos y del modelo conceptual del UML.
El capítulo III trata acerca de las metodologías Clásicas y contemporáneas
utilizadas dentro de la Ingeniería del Software, y un plan de trabajo basado en la
Página 1
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Metodología RUP (Rational Unified Process). Dentro de este capítulo se utilizará
a la herramienta Visual Paradigm 6.5, debido a su eficacia realizando los
diagramas UML, por su entorno completo, fácil y organizado de manipular
símbolos y diagramas, mejor que otros entornos de diagramación OOCASE.
El capítulo IV es un enfoque práctico del uso de los diagramas del UML y
cómo se utilizan dentro de la Metodología RUP, y el último capítulo es una visión
a futuro que se tendrá de este lenguaje.
En el apartado Anexos se visualizan todos los problemas prácticos que se
le pide al lector de este documento, para su mejor entendimiento del contexto de
esta obra.
Página 2
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Página 3
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
CAPITULO I. ANTECEDENTES E IMPORTANCIA DEL UML
Este capítulo trata acerca de los Antecedentes e Importancia del UML,
describiendo su concepto, la evolución que ha tenido desde que se creó y la
importancia que ha acaparado dentro de la Ingeniería del Software.
1.1.
¿Qué es el Lenguaje de Modelado Unificado?
1.1.1. Concepto
Para poder responder a esta interesante pregunta a continuación les
presento 3 definiciones de diferentes autores acerca de la temática:
“El Lenguaje de Modelado Unificado (UML) es un lenguaje de modelado
visual que se usa para especificar, visualizar, construir y documentar artefactos
de un sistema software. Captura decisiones y conocimiento sobre los sistemas
que se deben construir. Se usa para entender, diseñar, hojear, configurar,
mantener y controlar la información sobre tales sistemas. Está pensado para
usarse con todos los métodos de desarrollo de software, etapas del ciclo de vida,
dominios de aplicación y medios.” 1
“El UML (Unified Modeling Language) es el lenguaje de modelado de
sistemas de software más conocido y utilizado en la actualidad; está respaldado
por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio y funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programación, esquemas de bases de datos
y componentes reutilizables.” 2
“Es un lenguaje para especificar, visualizar, construir y documentar
ingenios software, cuyo alcance pretende cubrir los conceptos de Booch, OMT y
OOSE, resultando un lenguaje simple, común y ampliamente utilizable por
usuarios de métodos.” 3
1
James Rumbaugh, et al. El Lenguaje Unificado de Modelado, manual de referencia, 117 p.
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
3 http://pisuerga.inf.ubu.es/lsi/Docencia/TFC/ITIG/icruzadn/Memoria/24.htm
2
Página 4
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Ahora sí, haciendo un análisis de las tres definiciones anteriores puedo
decir que el UML es un lenguaje que permite la planificación, análisis,
diseño y documentación de sistemas, componentes o procesos software
orientados a objetos, así como también sistemas de hardware y
organizaciones del mundo real.
Debido a que el UML es un lenguaje, cuenta con reglas para combinar
a diversos elementos gráficos que a su vez se combinan para conformar
diagramas, y éstos, a su vez, modelos.
1.1.2. Analogía
Este enfoque es similar a aprender un idioma extranjero,
aprendiendo sus reglas gramaticales y la conjugación de sus verbos.
Después de un tiempo de ponerlo en práctica (al idioma extranjero) se le facilitará
comprender la conjugación de estos verbos así como sus reglas gramaticales
hasta el grado de poder hablar bien este nuevo idioma. Lo mismo pasará con
el desarrollo de sistemas, componentes o procesos software adquiriendo
experiencia con el UML.
 Sintácticas
Lenguaje de
= Notación + Reglas
Modelado
 Semánticas
 Pragmáticas
El UML, el Lenguaje Unificado de Modelado es una especificación de
notación orientada a objetos, también prescribe un conjunto diagramas
estándar para modelar sistemas orientados a objetos, y describe la semántica
esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido
muchas notaciones y métodos usados para el diseño orientado a objetos, ahora
los modeladores sólo tienen que aprender una única notación.
1.1.2.1. División de los proyectos con el Lenguaje de Modelado
Unificado
Página 5
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
El UML Divide cada proyecto en un número de diagramas que
representan las diferentes vistas del proyecto. Estos diagramas juntos son los
que representan la arquitectura del proyecto. Los nueve diagramas en los cuales
modelar sistemas son:
 Diagramas de Casos de Uso En ellos se captura los requisitos del
sistema, es decir, qué funciones va a realizar el sistema, desde el punto
de vista de la interacción con el usuario.
 Diagramas de Secuencia capturan la interacción entre los objetos y los
mensajes que intercambian entre sí atendiendo al orden temporal de los
mismos.
 Diagramas de Colaboración igualmente, muestra la interacción entre los
objetos resaltando la organización estructural de los objetos en lugar del
orden de los mensajes intercambiados.
 Diagramas de Estado Se utilizan para analizar los cambios de estado de
los objetos. Muestran los estados, eventos, transiciones y actividades de
los diferentes objetos. Estos diagramas son útiles en sistemas orientados
a eventos.
 Diagramas de Actividad son un caso especial del diagrama de estados,
simplifica el diagrama de estados modelando el comportamiento mediante
flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para
modelar el funcionamiento del sistema y el flujo de control entre objetos.
 Diagramas de Clases Muestran un conjunto de clases, interfaces y sus
relaciones. Es el diagrama principal de UML y al que dedicaremos más
tiempo. Éste es el diagrama más común a la hora de describir el diseño
de los sistemas orientados a objetos.
 Diagramas de Objetos Muestran una serie de objetos (instancias de las
clases) y sus relaciones. Es un diagrama de instancias de las clases
mostradas en el diagrama de clases. Su representación gráfica sería
equivalente a la del diagrama de clases pero más detallado.
 Diagramas
de
Componentes
muestra
la
organización
y
las
dependencias entre un conjunto de componentes. Se usan para agrupar
clases en componentes o módulos.
Página 6
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Diagramas de Implementación muestra los dispositivos que se
encuentran en un sistema y su distribución en el mismo. Se utiliza para
identificar Sistemas de Cooperación: Durante el proceso de desarrollo el
equipo averiguará de qué sistemas dependerá el nuevo sistema y qué
otros sistemas dependerán de él. 4
Como anteriormente se dijo, el UML se puede usar para modelar
distintos tipos de sistemas: sistemas de software, sistemas de hardware, y
organizaciones del mundo real. Mediante el fomento del uso de este lenguaje, la
OMG pretende alcanzar los siguientes objetivos:
 Proporcionar a los usuarios un lenguaje de modelado visual expresivo y
utilizable para el desarrollo e intercambio de modelos significativos.
 Proporcionar mecanismos de extensión y especialización.
 Ser independiente del proceso de desarrollo y de los lenguajes de
programación.
 Proporcionar una base formal para entender el lenguaje de modelado.
 Fomentar el crecimiento del mercado de las herramientas OO.
 Soportar conceptos de desarrollo de alto nivel como pueden ser
colaboraciones, frameworks, patterns, y componentes.
 Integrar las mejores prácticas utilizadas hasta el momento. 5
El UML se quiere convertir en un lenguaje estándar con el que sea posible
modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin
embargo, hay que tener en cuenta un aspecto importante del modelo: no
pretende definir un modelo estándar de desarrollo, sino únicamente un
lenguaje de modelado (se consideran fuera del ámbito de UML tanto los
lenguajes de programación, como las herramientas y el proceso software).
4
5
http://techfico.blogspot.com/2010/06/uml-orientacion-de-objetos.html.
http://alvearjofre.galeon.com/
Página 7
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
1.2. Génesis y evolución
Desde que Simula 67 introdujera el concepto de clase y herencia los
Lenguajes Orientados a Objetos han experimentado una rápida e intensa
evolución para acercarse a la realidad que las empresas les reclama. Pero no es
hasta los inicios de la década de los 90 cuando realmente existe un intento serio
de normalizar a la Metodología Orientada a Objetos.
El Dr. James Rumbaugh (ver figura 1.1.) en 1991 con Michael Blaha,
William Premerlani, Frederick Eddy y William Lorensen desarrollan "Object
Oriented Modeling and Design"
introduciendo OMT (Object Modeling
Technique) que él mismo define como "una metodología orientada a objetos
para el desarrollo de software".
Figura 1.1. Fotografía de James Roumbaugh. Tomado de
http://www.ctv.es/USERS/belmont/historia.htm.
El Dr. Ivar Jacobson en 1992 desarrolla el método OOSE (Object
Oriented Software Engineer), donde introduce el concepto "use case".
Figura 1.2. Fotografía de Ivar Jacobson. Tomado de
http://www.ctv.es/USERS/belmont/historia.htm.
Grady Booch (ver figura 1.3.) en 1993 crea la metodología "Booch '93".
Página 8
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.3. Fotografía de Grady Booch. Tomado de
http://www.ctv.es/USERS/belmont/historia.htm
J. Rumbaugh y G. Booch en el año 1994 se unen en una empresa
común (de objetivos y de negocio) Rational Software Corporation donde
unifican sus dos métodos (los lenguajes de modelado Booch y OMT).
Es entonces cuando fueron reconocidos mundialmente a la cabeza del
desarrollo de metodologías orientadas a objetos. Fue entonces cuando
terminaron su trabajo de unificación obteniendo el borrador de la versión 0.8 del
denominado “Unified Method” en octubre de 1995. A finales de ese mismo año
se une al grupo I. Jacobson, dueño de la compañía “Objetory Corporation”,
aportando su método. Y los tres autores publican un documento titulado Unified
Method versión 0.8 (la que se considera la primera versión del UML). Después
el método unificado se reorienta hacia la definición de un lenguaje universal
para el modelado de objetos, transformándose en el UML (Unified Modeling
Language, for Object-Oriented Development), para obtener después, y
finalmente, la versión UML 0.9 y 0.91 en junio y octubre de 1996.
Como objetivos principales de la concepción de un nuevo método que
unificara los mejores aspectos de sus predecesores, sus protagonistas se
propusieron lo siguiente:
 El método debía ser capaz de modelar no sólo sistemas de software sino
otro tipo de sistemas reales de la empresa, siempre utilizando los
conceptos de la orientación a objetos (OO).
 Crear un lenguaje para modelado utilizable a la vez por máquinas y por
personas.
Página 9
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Establecer un acoplamiento explícito de los conceptos y los artefactos
ejecutables.
 Manejar los problemas típicos de los sistemas complejos de misión crítica.
Durante el desarrollo del UML sus autores tuvieron en cuenta los
siguientes objetivos:
 Proporcionar una notación y semánticas suficientes para poder alcanzar
una gran cantidad de aspectos del modelado contemporáneo de una
forma directa y económica.
 Proporcionar las semánticas suficientes para alcanzar aspectos del
modelado que son de esperar en un futuro, como por ejemplo aspectos
relacionados con la tecnología de componentes, el cómputo distribuido,
etc.
 Proporcionar mecanismos de extensión de forma que proyectos concretos
puedan extender el meta-modelo a un coste bajo.
 Proporcionar mecanismos de extensión de forma que aproximaciones de
modelado futuras podrían desarrollarse encima del UML.
 Permitir el intercambio de modelos entre una gran variedad de
herramientas.
 Proporcionar semánticas suficientes para especificar las interfaces a
bibliotecas para la compartición y el almacenamiento de componentes del
modelo.
Lo que se intenta es lograr con ésto es que los lenguajes que se aplican
siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por
separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas
(no sólo software, sino también en el ámbito de los negocios), al aclarar las fases
de desarrollo, los requerimientos de análisis, el diseño, la implementación y los
conceptos internos de la orientación a objetos. 6
6
http://www.ctv.es/USERS/belmont/historia.htm
Página 10
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Tras esto muchas organizaciones como Microsoft, Hewlett-Packard,
Oracle, Sterling Software MCI Systemhouse, Unisys, ICON Computing,
IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology, Ptech, Taskon,
Reich Technologies y Softeam, se asociaron junto con Rational Software
Corporation para dar como resultado al UML 1.0. A finales de 1996, el Object
Management Group (OMG), un pilar estándar para la comunidad del diseño
orientado a objetos, publicó una petición con el propósito de un metamodelo
orientado a objetos de semántica y notación estándares. El UML, en su versión
1.0, fue propuesto como una respuesta a esta petición 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 del UML, llamado UML versión 1.1. Este documento fue
aprobado por el OMG en Noviembre de 1997, convirtiéndose así en la notación
estándar factible para el análisis y diseño orientado a objetos. El OMG llama a
este documento OMG UML versión 1.1. En julio de 1998 aparece una revisión
interna del UML que recoge diversos cambios editoriales, pero no técnicos. Esta
versión es la que se conoce como UML 1.2. Casi un año más tarde, en junio de
1999 aparece OMG UML 1.3 con algunos cambios significativos, especialmente
en lo tocante a la semántica. El OMG mejoró una edición técnica de esta
especificación en el Septiembre del 2000, llamándose OMG UML 1.4. La última
versión del UML es OMG UML 2.0 (Marzo 2003). 7
La notación del UML se deriva y unifica las tres metodologías de análisis
y diseño orientado a objetos más extendidas:
 La metodología de Grady Booch para la descripción de conjuntos de
objetos y sus relaciones.
 La técnica de modelado orientada a objetos de James Rumbaugh (OMT:
Object-Modeling Technique).
 La aproximación de Ivar Jacobson (OOSE: Object- Oriented Software
Engineering) mediante la metodología de casos de uso (use case).
7
http://repositorio.bib.upct.es/dspace/bitstream/10317/190/1/pfc1128.pdf
Página 11
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
De las tres metodologías de partida, las de Booch y Rumbaugh pueden
ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan
hacia el modelado de los objetos que componen el sistema, su relación y
colaboración. Por otro lado, la metodología de Jacobson es más centrada a
usuario, ya que todo en su método se deriva de los escenarios de uso.
El UML es el primer método en publicar un meta-modelo en su propia
notación, incluyendo la notación para la mayoría de la información de requisitos,
análisis y diseño orientado a objetos. Se trata pues de un meta-modelo autoreferencial (cualquier lenguaje de modelado de propósito general debería ser
capaz de modelarse a sí mismo).
Figura 1.4. Historia y evolución del UML. Tomado de
http://wikimej.wikispaces.com/trabajo_uml.
1.3. Importancia del lenguaje dentro de la Ingeniería del software
Página 12
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Conforme aumenta la complejidad del mundo, los sistemas informáticos
también crecen en complejidad. En ellos se encuentran diversas piezas de
software y hardware que se comunican a grandes distancias mediante una red
o de Internet, misma que esta vinculada a bases de datos que a su vez, contienen
enormes cantidades de información. Si se desea crear sistemas que se
involucren con este milenio ¿Cómo manejar tanta complejidad?
La clave esta en organizar el proceso de diseño de tal forma que los
analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo
de sistemas lo comprendan y convengan con él. El UML proporciona tal
organización. 8
Un arquitecto no podría crear una compleja estructura como lo es un
edificio de oficinas sin crear primero un anteproyecto detallado; asimismo el
lector tampoco podría generar un complejo sistema en el edificio de oficinas sin
un plan detallado. La idea es que así como un arquitecto le muestra su
anteproyecto a la persona que lo contrató, el lector deberá mostrarle su plan de
diseño al cliente. Tal plan de diseño debe ser el resultado de un cuidadoso
análisis de las necesidades del cliente.
La necesidad de diseños sólidos o concretos ha traído consigo la creación
de una notación de diseño que los analistas, desarrolladores y clientes acepten
como pauta (tal como los diagramas esquemáticos sirven como pauta para los
trabajadores especializados en Electrónica). El UML es esa misma notación.
1.3.1. Necesidad de atacar a la complejidad del desarrollo del software
con metodologías y herramientas actuales
El UML es un lenguaje que permite la planificación, análisis, diseño y
documentación de sistemas, componentes o procesos software orientados a
objetos, así como también de sistemas hardware y organizaciones del mundo
real. El UML es un lenguaje de modelado de objetos independiente del método
8
www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r69318.DOCX
Página 13
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
que se implemente (el UML no es una notación propietaria). El objetivo del UML
es la unificación de los métodos de modelado de objetos:
 Identificación y definición de la semántica de los conceptos fundamentales
 Elección de una representación gráfica cuya sintaxis sea simple,
expresiva e intuitiva
Las ventajas o beneficios (ver figura 1.5.) que proporciona esta
metodología son;
 Manejar la complejidad.
 Modelar un sistema independientemente del lenguaje de implementación.
 Promover la reutilización.
Figura 1.5. Ventajas o beneficios del UML. Tomado de http://
delta.cs.cinvestav.mx/~pmalvarez/softeng/curso.../modelado-uml-1.ppt.
1.4. Actividades de capítulo por realizar
1. Con la información del tema 1.2. Realiza una línea de tiempo en orden
ascendente.
Página 14
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
2. Buscar información más actualizada de cómo va evolucionando el UML.
De preferencia busque páginas en inglés y tradúzcalas con Google
Translate.
3. Desarrollar mapas conceptuales con los temas vistos en este capítulo.
Página 15
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
CAPITULO II. TECNOLOGÍA DE OBJETOS (VISIÓN GENERAL DEL UML)
Este capítulo es una visión general del lenguaje, Tratando acerca del
modelo orientado a objetos y del modelo conceptual del UML.
2.1. El modelo orientado a objetos
Un modelo captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del sistema que son relevantes
al propósito del modelo, y a un apropiado nivel de detalle.
El modelo UML de un sistema es similar a un modelo a escala de un
edificio (por ejemplo) junto con la interpretación de su arquitecto. El modelo
describe lo que supuestamente hará el sistema, pero no dice como
implementarlo9.
2.1.1. Concepto de clase
En la programación orientada a objetos, una clase es una construcción
que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El
modelo describe el estado (atributos) y el comportamiento (operaciones) que
todos los objetos de la clase comparten.
Una clase por lo general representa un sustantivo, como una persona,
lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto
dentro de un programa de computadora. 10
2.1.2. Concepto de Atributo
También
llamados atributos o características,
son
valores que
corresponden a un objeto, como color, material, cantidad, ubicación.
Generalmente se conoce como la información detallada del objeto. Suponiendo
que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y
peso. 11.
9
http://www.monografias.com/trabajos34/ingenieria-software/ingenieria-software.shtml
http://es.wikipedia.org/wiki/Clase_(inform%C3%A1tica)
11 http://es.wikipedia.org/wiki/Diagrama_de_clases
10
Página 16
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
2.1.3. Concepto de operación
Comúnmente llamados métodos, son aquellas actividades o verbos que
se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar,
cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el
nombre de una operación se escribe con minúsculas si consta de una sola
palabra. Si el nombre contiene más de una palabra, cada palabra será unida a
la anterior y comenzará con una letra mayúscula, a excepción de la primera
palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta,
buscarPuerta, etc12.
2.1.4. Concepto de Objeto
Los objetos son entidades que tienen un determinado estado,
comportamiento (método) e identidad:

El estado está compuesto de datos, será uno o varios atributos a los que
se habrán asignado unos valores concretos (datos).

El comportamiento está definido por los métodos o mensajes a los que
sabe responder dicho objeto, es decir, qué operaciones se pueden
realizar con él.

La identidad es una propiedad de un objeto que lo diferencia del resto,
dicho con otras palabras, es su identificador (concepto análogo al de
identificador de una variable o una constante).
Un objeto contiene toda la información que permite definirlo e identificarlo
frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de
una misma clase, al poder tener valores bien diferenciados en sus atributos. A
su vez, los objetos disponen de mecanismos de interacción llamados métodos,
que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez
el cambio de estado en los propios objetos. Esta característica lleva a tratarlos
12
Ídem.
Página 17
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
como unidades indivisibles, en las que no se separa el estado y el
comportamiento13.
2.2. Modelos de representación del UML
 Modelo de clases: Representa de una manera estática la estructura de
información del sistema y la visibilidad que tiene cada una de las clases,
dada por sus relaciones con las demás en el modelo. Los modelos de
clases se muestran mediante los diagramas de clases y de objetos.
 Modelo de estados: Éste representa el conjunto de estados por los
cuales pasa un objeto durante su vida en una aplicación, junto con los
cambios que permiten pasar de un estado a otro. Los modelos de estados
se muestran en los diagramas de estados y de actividades.
 Modelo de casos de uso: Representa la funcionalidad de un sistema u
otro clasificador tal como lo perciben quienes interactúan con el sistema
desde el exterior (actores). Los modelos de casos de uso se muestran en
los diagramas de casos de uso.
 Modelo de interacción: Éste representa la interacción de un conjunto de
objetos en una aplicación a través del tiempo. Los modelos de interacción
se muestran en los diagramas de secuencia y de colaboración.
 Modelo de despliegue o implementación: Éste permite modelar la
configuración de los elementos de procesado en tiempo de ejecución
(run-time processing elements) y de los componentes, procesos y objetos
de software que viven dentro de él. Los modelos de implementación o
despliegue se muestran en los diagramas de componentes y de
implementación14.
Los modelos son manipulados por medio de vistas que se clasifican en tres
áreas:
 Vista Estructural
13
14
http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos
http://www.dcc.uchile.cl/~psalinas/uml/modelo.html
Página 18
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Vista Dinámica
 Vista De gestión de modelos15
2.3. Qué es un diagrama
Un diagrama es una representación gráfica de una colección de
elementos de modelado. La finalidad de los diagramas es presentar diversas
perspectivas de un sistema, a las cuales se les conoce como modelo. El
UML define nueve tipos de diagramas:
 Diagrama de clases: Muestra las clases (descripciones de objetos que
comparten características comunes, ver figura 1.6.) que componen el
sistema y cómo se relacionan entre sí.
Figura 1.6. Ejemplo de un Diagrama de Clases. Tomado de
http://commons.wikimedia.org/wiki/File:Diagrama_de_clases.svg.
 Diagrama de secuencia: Enfatiza la interacción entre los objetos y los
mensajes que intercambian entre sí (ver figura 1.7.) junto con el orden
temporal de los mismos.
15
http://ocw.usal.es/ensenanzas-tecnicas/.../Tema2-Modeloobjeto-1pp.pdf
Página 19
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.7. Ejemplo de un Diagrama de Secuencia. Tomado de
http://commons.wikimedia.org/wiki/File:CrearPais.png.
 Diagrama de colaboración: Igualmente, muestra la interacción entre los
objetos (ver figura 1.8.) resaltando la organización estructural de los
objetos en lugar del orden de los mensajes intercambiados.
Figura 1.8. Ejemplo de un Diagrama de Colaboración. Tomado de
http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/colaboracion01.html
Página 20
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Diagrama de objetos: Muestra una serie de objetos (instancias o
solicitudes de las clases, ver figura 1.9.) y sus relaciones. A diferencia de
los diagramas anteriores, estos diagramas se enfocan en la perspectiva
de casos reales o prototipos. Es un diagrama de instancias de las clases
mostradas en el diagrama de clases.
Figura 1.9. Ejemplo de un Diagrama de Objetos. Tomado de
http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html.
 Diagrama de estados: Se utiliza para analizar los cambios de estado de
los objetos. Muestra los estados, eventos, transiciones y actividades de
los diferentes objetos (ver figura 1.19.). Son útiles en sistemas que
reaccionen a eventos.
Figura 1.10. Ejemplo de un Diagrama de Estados. Tomado de
http://es.wikipedia.org/wiki/Archivo:Diagrama_de_Estados_State.jpg.
 Diagrama de actividades: Es un caso especial del diagrama de estados,
simplifica el diagrama de estados modelando el comportamiento mediante
flujos de actividades. Muestra el flujo entre los objetos (ver figura 1.11.).
Se utilizan para modelar el funcionamiento del sistema y el flujo de control
entre objetos.
Página 21
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.11. Ejemplo de un Diagrama de Actividades. Tomado de
http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html.
 Diagrama de casos de uso: Modela la funcionalidad del sistema
agrupándola en descripciones de acciones ejecutadas por un sistema
para obtener un resultado (ver figura 1.12.). Se utiliza para entender el
uso del sistema.
Figura 1.12. Ejemplo de un Diagrama de casos de Uso. Tomado de
http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html.
 Diagrama de componentes: Muestra la organización y las dependencias
entre un conjunto de componentes (ver figura 1.13.). Se usan para
agrupar clases en componentes o módulos.
Página 22
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.13. Ejemplo de un Diagrama de Componentes. Tomado de
http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/implementacion01.html.
 Diagrama de despliegue o implementación: Muestra los dispositivos
que se encuentran en un sistema y su distribución en el mismo (ver figura
1.14.). Se utiliza para identificar Sistemas de Cooperación: Durante el
proceso de desarrollo el equipo averiguará de qué sistemas dependerá el
nuevo sistema y que otros sistemas dependerán de él16.
Figura 1.14. Ejemplo de un Diagrama de Implementación o Despliegue. Tomado de
http://sistemas3jam.blogspot.mx/2011/05/diagrama-de-estructuras-5-diagrama-de.html
2.4. Modelado de Objetos
16
http://www.monografias.com/trabajos5/insof/insof.shtml
Página 23
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Un modelo es una simplificación de la realidad. Un modelo
proporciona los planos de un sistema. Los modelos pueden involucrar planos
detallados, así como planos más generales que ofrecen una visión global del
sistema en consideración. Un buen modelo incluye aquellos elementos que
tienen una gran influencia y omite aquellos elementos menores que no son
relevantes para el nivel de abstracción dado. Todo sistema puede ser descrito
desde diferentes perspectivas utilizando diferentes modelos, y cada modelo es
por tanto una abstracción semánticamente cerrada del sistema.
Un modelo puede ser estructural, destacando la organización del sistema,
o puede ser de comportamiento, resaltando su dinámica. ¿Por qué modelamos?
Hay una razón fundamental: “Construimos modelos para comprender mejor el
sistema que estamos desarrollando”17
A través del modelado, conseguimos 4 objetivos:
 Los modelos nos ayudan a visualizar cómo es o queremos que sea un
sistema.
 Los modelos nos permiten especificar la estructura o el comportamiento
de un sistema.
 Los modelos nos proporcionan plantillas que nos guían en la construcción
de un sistema.
 Los modelos documentan las decisiones que hemos adoptado.
El modelado no es sólo para los grandes sistemas. Sin embargo, es
absolutamente cierto que, cuanto más grande y complejo es el sistema, el
modelado se hace más importante, por una simple razón: “Construimos
modelos de sistemas complejos por que no podemos comprender el
sistema en su totalidad.”
Hay límites a la capacidad humana de comprender la complejidad. A
través del modelado, se reduce el problema que se esta estudiando, centrándose
sólo en un aspecto a la vez. Éste es, esencialmente, el enfoque “divide y
17
http://www.monografias.com/trabajos82/lenguaje-uml-importancia-modelar/lenguaje-umlimportancia-modelar.shtml
Página 24
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
vencerás” que planteó Edsger Dijkstra años atrás: acometer un problema difícil
dividiéndolo en una serie de subproblemas más pequeños que se pueden
resolver. Además, a través del modelado, se incrementa la mente humana. Un
modelo escogido adecuadamente puede permitir al modelador trabajar a
mayores niveles de abstracción.
Entonces pues, el término modelado expresa la descomposición en
elementos simples más fáciles de comprender. Las partes en que se puede
clasificar al modelado son:
 Descripción del problema (análisis).
 Descripción de la solución (diseño).
 Descripción del desarrollo de la solución (implementación).
El modelado de objetos consiste en la descripción de los objetos en
términos de sus propiedades y de sus relaciones.
El modelado de objetos es una técnica utilizada en todas las ingenierías.
Como tal, la ingeniería del software debe basarse en el modelado de objetos
como una parte central de todas las actividades que conducen a la producción
de software de calidad18.
2.5. Jerarquía de modelos
La arquitectura del UML esta basada en cuatro capas, definida a fin de
cumplir con la especificación Meta Object Facility del OMG, estas capas son:
 Meta-metamodelo: define el lenguaje para especificar metamodelos.
 Metamodelo: define el lenguaje para especificar modelos.
 Modelo: define el lenguaje para describir un dominio de información.
 Objetos de usuario: define un dominio de información específico.
18
http://www.oocities.org/es/avrrinf/tabd/Foro/Foro_UML.htm
Página 25
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Lo anterior, de una manera más simplificada, quedaría de la siguiente
manera: Los modelos de objetos del usuario sirven como fundamento a otros
modelos y como base para los metamodelos que describen las formas que los
modelos pueden tomar (estandarización).
La misma idea puede aplicarse de nuevo en el nivel de los Metamodelos
para construir meta metamodelos que describan a los metamodelos. El
resultado es una jerarquía de modelos descrita por las capas anteriormente
citadas que se muestra en la sig. figura19:
Figura 1.15. Arquitectura del UML (jerarquía de capas). Tomado de
http://www.itlalaguna.edu.mx/Acad/Carreras/sistemas/Analisis%20y%20dise%C3%B1o%20ori
entado%20a%20objetos/semant.pdf.
2.6. El modelo conceptual del UML
19
http://www.itlalaguna.edu.mx/Acad/Carreras/sistemas/Analisis%20y%20dise%C3%B1o%20orie
ntado%20a%20objetos/semant.pdf
Página 26
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Para comprender a la metodología del UML, se necesita adquirir un
modelo conceptual del lenguaje, esto requiere aprender tres elementos
principales: Los Bloques Básicos de Construcción del UML, las Reglas que
indican cómo combinar a estos bloques y algunos mecanismos comunes
que se aplican a través del lenguaje20.
2.6.1. Bloques Básicos de Construcción del lenguaje
El vocabulario del UML incluye tres clases de Bloques de Construcción:
1) Elementos, 1) Relaciones y 3) Diagramas (que se estudiarán más a fondo
en el capítulo II).
Los elementos son abstracciones, las relaciones ligan estos elementos
entre sí y los diagramas agrupan colecciones interesantes de elementos.
2.6.1.1. Elementos del lenguaje
Hay cuatro tipos de elementos: 1) Elementos Estructurales, 2)
Elementos de Comportamiento, 3) Elementos de Agrupación y 4)
Elementos de Anotación.
 Elementos Estructurales: son los nombres de los modelos UML. En su
mayoría son las partes estáticas de un modelo, y representan cosas que
son conceptuales o materiales.
 Elementos de Comportamiento: Son las partes dinámicas de los
modelos UML. Éstos son los verbos de un modelo, y representan
comportamiento en el tiempo y el espacio.
 Elementos de Agrupación: Son las partes organizativas de los modelos
UML. Éstos son las cajas en las que puede descomponerse un modelo.
 Elementos de Anotación: son las partes explicativas de los modelos
UML. Son comentarios que se pueden aplicar para describir, clarificar y
hacer observaciones sobre cualquier elemento de un modelo.
20
http://es.scribd.com/doc/57494332/12/Modelo-conceptual-de-UML
Página 27
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Estos elementos son los bloques de construcción orientados a objetos del UML.
Se utilizan para describir modelos bien formados21.
2.6.1.1.1. Elementos estructurales
En total, hay siete tipos de elementos estructurales:
1. Clase: una clase es una descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y semántica.
Una clase implementa una o más interfaces. Gráficamente, una clase se
representa como un rectángulo, que normalmente incluye su nombre,
atributos y operaciones. Ver figura 1.16:
Figura 1.16. Clase. Tomado del libro El lenguaje de modelado unificado, 15p.
2. Interfaz: una interfaz es una colección de operaciones que especifican un
servicio de una clase o componente. Por ende, una interfaz describe el
comportamiento visible externamente de ese elemento. Una interfaz
puede representar el comportamiento de una clase o componente o sólo
una parte de ese comportamiento. Una interfaz define un conjunto de
especificaciones
de
operaciones,
pero
nunca
un
conjunto
de
implementaciones de operaciones. Gráficamente, una interfaz se
representa como un círculo junto con su nombre. Ver figura 1.17:
21
Idem.
Página 28
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.17. Interfaz. Tomado del libro El lenguaje de modelado unificado, 16p.
3. Colaboración: define una interacción y es una sociedad de roles y otros
elementos que colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los comportamientos de sus
elementos. Por lo tanto, las colaboraciones tienen dimensión tanto
estructural como de comportamiento. Una clase dada puede participar en
varias colaboraciones. Estas colaboraciones representan, pues, la
implementación de patrones que forman un sistema. Gráficamente, una
colaboración se representa como una elipse de borde discontinuo,
incluyendo normalmente su nombre. Ver figura 1.18:
Figura 1.18. Colaboración. Tomado del libro El lenguaje de modelado unificado, 16p.
4. Caso de uso: Un caso de uso es una descripción de un conjunto de
secuencias de acciones que un sistema ejecuta y que produce un
resultado observable de interés para un actor particular. Se utiliza para
estructurar los aspectos de comportamiento en un modelo. Un caso de
uso es realizado por una colaboración. Gráficamente se representa como
Página 29
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
una elipse de borde continuo, incluyendo normalmente sólo su nombre 22.
Ver figura 1.19:
Figura 1.19. Caso de uso. Tomado del libro El lenguaje de modelado unificado, 16p.
5. Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o
hilos de ejecución, y por lo tanto pueden dar origen a actividades de
control. Es igual que una clase, excepto en que sus objetos representan
elementos cuyo comportamiento es concurrente con otros elementos.
Gráficamente se representa como una clase, pero con líneas más
gruesas, incluyendo normalmente su nombre, atributos y operaciones.
Ver figura 1.20:
Figura 1.20. Clase activa. Tomado del libro El lenguaje de modelado unificado, 17p.
6. Componente: Un componente es una parte física y reemplazable de un
sistema que conforma a un conjunto de interfaces y proporciona la
implementación de dicho conjunto. Éste representa típicamente el
empaquetamiento físico de diferentes elementos lógicos, como clases,
interfaces y colaboraciones. Gráficamente se representa como un
22
Idem 21.
Página 30
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
rectángulo con pestañas, incluyendo normalmente su nombre. Ver
siguiente figura:
Figura 1.21. Componente. Tomado del libro El lenguaje de modelado unificado, 17p.
7. Nodo: Es un elemento físico que existe en tiempo de ejecución y
representa un recurso computacional, que por lo general dispone de algo
de memoria y, con frecuencia, capacidad de procesamiento. Un conjunto
de componentes puede residir en un nodo y puede también migrar de un
nodo a otro. Gráficamente un nodo se representa como un cubo,
incluyendo normalmente su nombre23. Ver figura:
Figura 1.22. Nodo. Tomado del libro El lenguaje de modelado unificado, 18p.
2.6.1.1.2. Elementos de comportamiento
Hay dos tipos principales de elementos de comportamiento:
23
Idem 21.
Página 31
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
1. Interacción: Es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto
particular,
para
alcanzar
un
propósito
específico.
El
comportamiento de una sociedad de objetos o de una operación individual
puede especificarse con una interacción. Una interacción involucra
muchos otros elementos, incluyendo mensajes, secuencias de acción (el
comportamiento invocado por un mensaje) y enlaces (conexiones entre
objetos). Gráficamente un mensaje se muestra con una línea dirigida,
incluyendo casi siempre el nombre de su operación24. Ver figura 1.23:
Figura 1.23. Mensaje. Tomado del libro El lenguaje de modelado unificado, 18p.
2. Máquina de estados: Es un comportamiento que especifica la secuencia
de estados por las que pasa un objeto o una interacción durante su vida
en respuesta a eventos, junto con sus reacciones a estos eventos. El
comportamiento de una clase individual o una colaboración de clases
puede especificarse con una máquina de estados. Una máquina de
estados involucra a otros elementos, incluyendo a estados, transiciones
(el flujo de un estado a otro), eventos (que disparan una transición) y
actividades (la respuesta a una transición). Gráficamente un estado se
representa como un rectángulo de esquinas redondeadas, incluyendo
normalmente su nombre y sus subastados (si los tiene). Ver figura 1.24:
24
Idem 21.
Página 32
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.24. Estado. Tomado del libro El lenguaje de modelado unificado, 18p.
2.6.1.1.3. Elementos de agrupación
Hay un solo elemento de agrupación principal, estos son los paquetes.
Un paquete es un mecanismo de propósito general para organizar elementos en
grupos. Los elementos estructurales, los elementos de comportamiento, e
incluso otros elementos pueden incluirse en un paquete. Al contrario de los
componentes (que existen en tiempo de ejecución) el paquete es puramente
conceptual (sólo existe en tiempo de desarrollo). Gráficamente se visualiza como
una carpeta, incluyendo normalmente su nombre y, a veces, su contenido25. Ver
figura 1.25:
Figura 1.25. Paquete. Tomado del libro El lenguaje de modelado unificado, 19p.
2.6.1.1.4. Elementos de anotación
Hay un tipo de elemento de anotación principal llamado Nota. Una nota
es simplemente un símbolo para mostrar restricciones y comentarios junto a un
25
Idem 21.
Página 33
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
elemento o una colección de elementos. Gráficamente se representa como un
rectángulo con una esquina doblada, junto con un comentario textual o gráfico.
Ver figura 1.26:
Figura 1.26. Nota. Tomado del libro El lenguaje de modelado unificado, 19p.
2.6.1.2. Relaciones en el UML
Hay cuatro tipos de relaciones en el lenguaje:
1. Dependencia: Es una relación semántica entre dos elementos, en la cual
un cambio a un elemento (el elemento independiente) puede afectar a la
semántica del otro elemento (el elemento dependiente). Gráficamente se
representa como una línea discontinua, posiblemente dirigida, que incluye
a veces una etiqueta. Ver figura 1.27:
Figura 1.27. Dependencia. Tomado del libro El lenguaje de modelado unificado, 20p.
2. Asociación: Es una relación estructural que describe un conjunto de
enlaces. Los cuales son conexiones entre objetos. La agregación es un
tipo especial de asociación, que representa una relación estructural entre
un todo y sus partes. Gráficamente, una asociación se representa con una
línea continua, posiblemente dirigida, que a veces incluye una etiqueta, y
a menudo incluye otros adornos, como la multiplicidad y los nombre de
rol. En el capítulo II se explicará con más detalle este concepto. Ver figura
1.28:
Página 34
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.28. Asociación. Tomado del libro El lenguaje de modelado unificado, 20p.
3. Generalización: Es una relación de especialización/generalización en la
cual los objetos del elemento especializado (el hijo) pueden sustituir a los
objetos del elemento general (el padre). De esta forma, el hijo comparte
la estructura y el comportamiento del padre. Gráficamente este tipo de
relación se representa como una línea continua con una punta de flecha
vacía apuntando al padre26. Ver figura 1.29:
Figura 1.29. Generalización. Tomado del libro El lenguaje de modelado unificado, 20p.
4. Realización: Es una relación semántica entre clasificadores, en donde un
clasificador especifica un contrato que otro clasificador garantiza que
cumplirá. Se pueden encontrar relaciones de realización en dos sitios:
entre interfaces y las clases y los componentes que las realizan, y entre
los casos de uso y las colaboraciones que los realizan. Gráficamente se
representa como una mezcla entre una generalización y una relación de
dependencia. Ver figura 1.30:
Figura 1.30. Realización. Tomado del libro El lenguaje de modelado unificado, 20p.
2.6.2. Reglas del UML
26
Idem 21.
Página 35
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Los bloques de construcción no pueden simplemente combinarse de
cualquier manera. Como cualquier lenguaje, el UML tiene un número de reglas
que especifican a qué debe parecerse un modelo bien formado.
Un
modelo
bien
formado
es
aquél
que
es
semánticamente
autoconsistente y está en armonía con todos sus modelos relacionados.
El UML tiene reglas semánticas para:
 Nombres: Cómo llamar a los elementos, relaciones y diagramas.
 Alcance: el contexto que da un significado específico a un nombre.
 Visibilidad: Cómo se pueden ver y utilizar esos nombres por otros.
 Integridad: Cómo se relacionan apropiada y consistentemente unos
elementos con otros.
 Ejecución: Qué significa ejecutar y simular un modelo dinámico.
Las reglas del lenguaje estimulan (pero no obligan) a considerar las
cuestiones más importantes de análisis, diseño e implementación que llevan a
sistemas a convertirse en bien formados con el paso del tiempo.
2.6.3. Mecanismos comunes en el lenguaje
Un edificio se hace más simple y más armonioso al ajustarse a un patrón
de características comunes. Una casa puede construirse de estilo victoriano o
francés utilizando ciertos patrones arquitectónicos que definen esos estilos. Lo
mismo es cierto en el UML. Éste se simplifica mediante la presencia de cuatro
mecanismos comunes que se aplican de forma
consistente a través del
lenguaje:
 Especificaciones: el UML es algo más que un lenguaje gráfico. Detrás
de cada elemento de su notación gráfica hay una especificación que
proporciona una explicación textual de la sintaxis y la semántica de ese
bloque de construcción. La notación gráfica se utiliza para visualizar un
sistema, mientras que la especificación del UML se utiliza para enunciar
los detalles del sistema. Entonces, pues, las especificaciones del UML
Página 36
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
proporcionan una base semántica que incluye a todos los elementos de
todos los modelos de un sistema, y cada elemento esta relacionado con
otros de manera consistente. Los diagramas del UML son así, entonces,
simples proyecciones visuales de esa base, y cada diagrama revela un
aspecto específico interesante del sistema.
 Adornos: La especificación de una clase puede incluir otros detalles,
tales como si es abstracta o la visibilidad de sus atributos y operaciones.
Muchos de estos detalles se pueden incluir como adornos gráficos o
textuales en la notación rectangular básica de la clase. Por ejemplo, la
siguiente figura muestra una clase con adornos que indican que es una
clase abstracta con dos operaciones públicas (símbolo +), una operación
protegida (símbolo #) y la otra privada (símbolo -). Ver figura 1.31:
Figura 1.31. Adornos. Tomado del libro El lenguaje de modelado unificado, 24p.
+
public visibility (visibilidad pública)
#
protected visibility (visibilidad protegida)
-
private visibility (visibilidad privada)
Todos los elementos en la notación del UML comienzan con un símbolo
básico, al cual pueden añadirse una variedad de adornos específicos de
ese símbolo.
Página 37
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Divisiones comunes: Al modelar sistemas orientados a objetos, el
mundo puede dividirse en un par de formas. Primero esta la división entre
clase y objeto. Una clase es una abstracción y un objeto es una
manifestación concreta de sea abstracción. En el UML se pueden modelar
tanto clases como objetos. Ver figura 1.32:
Figura 1.32. Clase y objetos. Tomado del libro El lenguaje de modelado unificado, 24p.
En la figura 1.32 hay una clase llamada Cliente, junto con tres objetos: Juan
(del que se indica explícitamente que es un objeto Cliente), :cliente (un
objeto cliente anónimo) y Elisa ( el cual se ha etiquetado en su especificación
como un objeto de la clase Cliente, aunque no se muestra de forma explícita.
En segundo lugar tenemos la separación entre interfaz e implementación. Una
interfaz declara un contrato y una implementación representa la realización
concreta de ese contrato, responsable de hacer efectiva, de forma fidedigna,
la semántica completa de la interfaz. En el UML se pueden modelar las
interfaces y sus implementaciones. En la siguiente figura (fig. 1.33) hay un
componente llamado AsistenteOrtografico.dll que implementa dos interfaces:
InterfDesconocida e InterfOrtografia.
Página 38
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.33. Interfaces y componentes. Tomado del libro El lenguaje de modelado
unificado, 25p.
 Mecanismos de extensibilidad: el UML proporciona un lenguaje
estándar para escribir planos software, pero no es posible que un lenguaje
cerrado sea siempre suficiente para expresar todos los matices posibles
de todos los modelos en todos los dominios y en todos los momentos. Por
esta razón el UML es abierto-cerrado, siendo posible extender el lenguaje
de manera controlada. Los mecanismos de extensión del UML incluyen:
 Estereotipos: Éstos extienden el vocabulario del lenguaje,
permitiendo crear nuevos tipos de bloques de construcción que
deriven de los existentes, pero que sean específicos a un
problema. Como en la siguiente figura (fig. 1.34), donde la clase
Overflow tiene un estereotipo apropiado (<<exception>>).
Figura 1.34. Mecanismos comunes. Tomado del libro El lenguaje de modelado unificado, 25p.
 Valores etiquetados: Extienden las propiedades de un bloque
de construcción del UML, permitiendo añadir nueva información
en la especificación de ese elemento. Por ejemplo: Un producto
que atraviesa por muchas versiones a lo largo del tiempo a
menudo se querrá registrar la versión y el autor de ciertas
abstracciones críticas. La versión y el autor pueden ser añadidos
a
cualquier
bloque
de
construcción,
como
una
clase,
introduciendo nuevos valores etiquetados en el bloque de
construcción. En la figura anterior la clase ColaEventos se
extiende indicando explícitamente su versión y su autor.
Página 39
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Restricciones: Extiende la semántica de un bloque de
construcción del UML, permitiendo añadir nuevas reglas o
modificar las existentes. Por ejemplo: Se desea restringir la clase
ColaEventos para que todas las adiciones se hiciesen en orden.
Se puede añadir una restricción ({ordenado}) que indique
explícitamente esto para la operación Añadir().
En conjunto estos tres mecanismos de extensibilidad permiten configurar y
extender al UML para las necesidades de un proyecto. Estos mecanismos
también permiten al lenguaje adaptarse a nuevas tecnologías de software,
como la probable aparición de lenguajes de programación distribuida más
potentes27.
2.7. Ejercicios de repaso
1. Realizar un resumen con la información anterior.
2. Efectuar una síntesis con el contenido de los apartados anteriores y la
información del resumen anterior.
3. Crear mapas conceptuales de los diferentes temas vistos en este capítulo.
4. Crear un cuestionario con respuestas contestadas.
27
Idem 21.
Página 40
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
CAPITULO III. METODOLOGÍAS CLÁSICAS Y CONTEMPORÁNEAS, Y EL
PLAN DE TRABAJO CON BASE EN RUP
Este
capítulo
trata
acerca
de
las
metodologías
Clásicas
y
contemporáneas utilizadas dentro de la Ingeniería del Software, y un plan de
trabajo basado en la Metodología RUP (Rational Unified Process).
3.1. La metodología de desarrollo tradicional
En Ingeniería del software la metodología en cascada, también llamado
modelo en cascada o clásico, es el enfoque metodológico que ordena
rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio
de cada etapa debe esperar a la finalización de la inmediatamente anterior. Un
ejemplo de una metodología de desarrollo en cascada es:
1. Análisis de requisitos
2. Diseño del Sistema
3. Diseño del Programa
4. Codificación
5. Pruebas
6. Implantación
7. Mantenimiento
De esta forma, cualquier error de diseño detectado en la etapa de prueba
conduce necesariamente al rediseño y nueva programación del código afectado,
aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la
metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases más avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el ámbito académico y la
industria, sigue siendo el paradigma más seguido al día de hoy.
Sin embargo, esta idea demasiado simplificada del proceso de desarrollo
podrá darle una idea de que las etapas deberán sucederse en lapsos claramente
definidos (una después de la otra).
Esta forma de metodología tiene algunos puntos inquietantes: por un lado,
tiende a la realización de tareas individuales; si un analista no tiene contacto con
Página 41
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
un diseñador, y éste no tiene contacto con un desarrollador, existe la posibilidad
de que los tres miembros rara vez trabajen juntos para compartir puntos de vista
importantes.
Otro problema con esta metodología es que reduce en impacto de la
comprensión obtenida en el proyecto; si el proyecto no puede retroceder y volver
a los primeros estados, es posible que las ideas desarrolladas no sean utilizadas
(intentar introducir con calzador nuevos puntos de vista durante el desarrollo es,
cuando menos, bastante difícil).
Esta metodología antigua también fomenta otro problema: es común el
caso de que los partidarios a la metodología en cascada reparten el tiempo del
proyecto en la codificación. El verdadero efecto es que se quita un tiempo valioso
al análisis y diseño28.
3.2. Nuevas metodologías actuales.
3.2.1. Metodología RAD
Rapid application development (RAD), es un proceso de desarrollo de
software (Software Development Process) desarrollado inicialmente por James
Martin en 1980. El método comprende el desarrollo interactivo, Guías para la
Ingeniería de Aplicaciones Rápidas (GRAPPLE [Guide for Rapid Aplications
Production Process to Level Enginering]), la construcción de prototipos y el uso
de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente,
el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad,
utilidad y la rapidez de ejecución.
Hoy en día se suele utilizar para referirnos al desarrollo rápido de GUIs tal
como Glade, o IDEs de desarrollo completas como Delphi, Foxpro o Anjuta29.
28
29
http://es.wikipedia.org/wiki/Desarrollo_en_cascada
Schmuller, Joseph, Aprendiendo Lenguaje de Modelado Unificado en 24 horas, 211 p.
Página 42
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
3.2.1.1. Fases de la metodología RAD
 Recopilación necesidades
 Análisis
 Diseño
 Desarrollo
 Distribución
3.2.1.1.1. Fase 1. Recopilación de necesidades
 Descubrir los procesos de los negocios
–
Entrevista al cliente y a personas con el conocimiento de los
procesos (sesiones JAD)
–
Obtener un vocabulario de trabajo con terminología de la empresa
–
Observar los procesos directamente
–
Estudiar los resultados que arroja el sistema manual o anterior
–
Obtener como producto(s) diagrama(s) de casos de uso y
diagrama(s) de actividades de los procesos de negocios
Realizar un análisis de dominio

–
Comprender el dominio del cliente
•
Entrevistar nuevamente al cliente para comprender las
entidades del dominio (sesiones JAD. Se define en el tema
3.2.1.2.)
–
Obtener como producto un diagrama de clases de alto nivel
 Identificar sistemas cooperativos
Página 43
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
– Descubrir de qué sistemas depende el anterior y cuáles dependerán del
nuevo,
– Obtener como productos un diagrama de colaboración y un diagrama de
distribución.
 Descubrir las necesidades del sistema
– Realizar una sesión JAD reuniendo al cliente y a los usuarios potenciales
del nuevo sistema, junto con el equipo de trabajo, para saber que esperan que
haga el sistema
– Refinar el diagrama de clases anterior
– Obtener como producto un diagrama de paquetes
 Presentar resultados al cliente
3.2.1.1.2. Fase 2. Análisis
 Comprender el uso del sistema
– Analizar los casos de uso de alto nivel e inferiores para descubrir actores
(del diagrama de paquetes anterior),
– Obtener como producto un conjunto de diagramas de casos de uso que
muestren los actores y dependencias estereotipadas entre los casos de
uso (DCU de sistema).
 Depurar el diagrama de clases
 Definir la comunicación entre objetos
– Definir la forma en que los objetos se comunican
– Desarrollar un conjunto de diagramas de secuencias y de colaboraciones
para delinear la comunicación
 Analizar la integración con diagramas de colaboración
Página 44
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
– Descubrir detalles de la integración con los sistemas cooperativos
– Determinar la arquitectura (física y lógica) de bases de datos
– Obtener como productos diagramas de componentes y diagramas de
distribución detallados.
3.2.1.1.3. Fase 3. Diseño
 Desarrollo y depuración de los diagramas de clases y de objetos
 Desarrollo de diagramas de componentes depurados
 Planeación para la distribución
– Depurar el diagrama de distribución de la etapa anterior
 Diseño y prototipos de la(s) interfaz (ces) de usuario
3.2.1.2. ¿Qué es una sesión JAD?
La técnica denominada JAD (Joint Application Development, Desarrollo
Conjunto de Aplicaciones), desarrollada por IBM en 1977, es una alternativa a
las entrevistas individuales que se desarrolla a lo largo de un conjunto de
reuniones en grupo durante un periodo de 2 a 4 días. En estas reuniones se
ayuda a los clientes y usuarios a formular problemas y explorar posibles
soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo. Esta
técnica se base en cuatro principios: dinámica de grupo, el uso de ayudas
visuales para mejorar la comunicación (diagramas, transparencias, multimedia,
herramientas CASE, etc.), mantener un proceso organizado y racional y una
filosofía de documentación WYSIWYG (What You See Is What You Get, lo que
se ve es lo que se obtiene), por la que durante las reuniones se trabaja
directamente sobre los documentos a generar.
Página 45
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
El JAD tiene dos grandes pasos, el JAD/Plan cuyo objetivo es elicitar y
especificar requisitos, y el JAD/Design, en el que se aborda el diseño del
software. En este documento sólo se verá con detalle el primero de ellos.
En comparación con las entrevistas individuales, presenta las siguientes
ventajas:
• Ahorra tiempo al evitar que las opiniones de los clientes se contrasten por
separado.
• Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la
documentación generada, no sólo los ingenieros de requisitos.
• Implica más a los clientes y usuarios en el desarrollo30.
3.2.2. Modelos de desarrollo evolutivos
El software evoluciona con el tiempo. Los requisitos del usuario y del
producto suelen cambiar conforme se desarrolla el mismo. Las fechas de
mercado y la competencia hacen que no sea posible esperar a poner en el
mercado un producto absolutamente completo, por lo que se debe introducir una
versión funcional limitada de alguna forma para aliviar las presiones
competitivas.
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada
vez más completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar más allá, durante la fase de operación.
Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de
los más conocidos y utilizados del tipo evolutivo 31.
3.2.2.1. Modelo iterativo incremental
30
31
http://www.infor.uva.es/~mlaguna/is1/materiales/metodologia_elicitacion.pdf
http://es.wikipedia.org/wiki/Software
Página 46
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
En términos generales, podemos distinguir, los pasos generales que sigue
el proceso de desarrollo de un producto software. En el modelo de ciclo de vida
seleccionado, se identifican claramente dichos pasos. La Descripción del
Sistema es esencial para especificar y confeccionar los distintos incrementos
hasta llegar al Producto global y final. Las actividades concurrentes
(Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado
de los incrementos, que se hará posteriormente. Ver figura 1.35:
Figura 1.35. Modelo iterativo incremental 1. Tomado de
http://es.wikipedia.org/wiki/Software.
El incremental es un modelo de tipo evolutivo que está basado en varios
ciclos Cascada realimentados aplicados repetidamente, con una filosofía
iterativa. En la siguiente figura (fig. 1.36) se muestra un refino del diagrama
previo, bajo un esquema temporal, para obtener finalmente el esquema del
Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas
asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para
la obtención de un incremento; estos últimos se van integrando para obtener el
producto final completo. Cada incremento es un ciclo Cascada Realimentado,
aunque, por simplicidad.
Página 47
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.36. Modelo iterativo incremental 2. Tomado de http://es.wikipedia.org/wiki/Software.
La figura es sólo esquemática, un incremento no necesariamente se
iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes),
en cualquier tiempo de la etapa previa.
Bajo este modelo se entrega software «por partes funcionales más
pequeñas», pero reutilizables, llamadas incrementos. En general cada
incremento se construye sobre aquel que ya fue entregado.
Se aplican secuencias Cascada en forma escalonada, mientras progresa
el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y
a menudo el primer incremento es un sistema básico, con muchas funciones
suplementarias (conocidas o no) sin entregar32.
El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de
su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes
incrementos (o versiones). Además también aportan a ese plan otros factores,
como lo es la priorización (mayor o menor urgencia en la necesidad de cada
incremento) y la dependencia entre incrementos (o independencia).
32
Idem.
Página 48
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Luego de cada integración se entrega un producto con mayor
funcionalidad que el previo. El proceso se repite hasta alcanzar el software final
completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial
pero completamente operacional en cada incremento, y no una parte que sea
usada para reajustar los requerimientos (como si ocurre en el modelo de
construcción de prototipos).
El enfoque incremental resulta muy útil con baja dotación de personal para
el desarrollo; también si no hay disponible fecha límite del proyecto por lo que se
entregan versiones incompletas pero que proporcionan al usuario funcionalidad
básica (y cada vez mayor). También es un modelo útil a los fines de evaluación.
El Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se
permiten y esperan probables cambios en los requisitos en tiempo de desarrollo;
se admite cierto margen para que el software pueda evolucionar. Aplicable
cuando los requisitos son medianamente bien conocidos pero no son
completamente estáticos y definidos, cuestión esa que si es indispensable para
poder utilizar un modelo Cascada.
El modelo es aconsejable para el desarrollo de software en el cual se
observe, en su etapa inicial de análisis, que posee áreas bastante bien definidas
a cubrir, con suficiente independencia como para ser desarrolladas en etapas
sucesivas. Tales áreas a cubrir suelen tener distintos grados de apremio por lo
cual las mismas se deben priorizar en un análisis previo, es decir, definir cual
será la primera, la segunda, y así sucesivamente; esto se conoce como
«definición de los incrementos» con base en priorización. Pueden no existir
prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas
de todos modos y con algún criterio, ya que basándose en ellas se desarrollarán
y entregarán los distintos incrementos.
El hecho de que existan incrementos funcionales del software lleva
inmediatamente a pensar en un esquema de desarrollo modular, por tanto este
modelo facilita tal paradigma de diseño.
Página 49
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
En resumen, un modelo incremental lleva a pensar en un desarrollo
modular,
con
entregas
parciales
del producto
software
denominados
«incrementos» del sistema, que son escogidos según prioridades predefinidas
de algún modo. El modelo permite una implementación con refinamientos
sucesivos (ampliación o mejora). Con cada incremento se agrega nueva
funcionalidad o se cubren nuevos requisitos o bien se mejora la versión
previamente implementada del producto software 33.
3.2.2.2. Modelo en espiral
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un
modelo evolutivo que conjuga la naturaleza iterativa del Modelo de Prototipos
o Modelo MCP con los aspectos controlados y sistemáticos del Modelo
Cascada.
Proporciona
potencial
para
desarrollo
rápido
de
versiones
incrementales. En el modelo Espiral el software se construye en una serie de
versiones incrementales. En las primeras iteraciones la versión incremental
podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se
producen versiones cada vez más completas del sistema diseñado. Ver figura
1.37:
Figura 1.37. Modelo en espiral. Tomado de http://es.wikipedia.org/wiki/Software.
33
Idem 31.
Página 50
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
El modelo se divide en un número de Actividades de marco de trabajo,
llamadas «regiones de tareas». En general existen entre tres y seis regiones de
tareas (hay variantes del modelo)34.
Las regiones definidas en el modelo de la figura son:
 Región 1. Tareas requeridas para establecer la comunicación entre el
cliente y el desarrollador.
 Región 2. Tareas inherentes a la definición de los recursos, tiempo y otra
información relacionada con el proyecto.
 Región 3. Tareas necesarias para evaluar los riesgos técnicos y de
gestión del proyecto.
 Región 4. Tareas para construir una o más representaciones de la
aplicación software.
 Región 5. Tareas para construir la aplicación, instalarla, probarla y
proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
 Región 6. Tareas para obtener la reacción del cliente, según la evaluación
de lo creado e instalado en los ciclos anteriores.
Desventajas importantes:
 Requiere mucha experiencia y habilidad para la evaluación de los riesgos,
lo cual es requisito para el éxito del proyecto.
 Es difícil convencer a los grandes clientes que se podrá controlar este
enfoque evolutivo.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por
lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo
y difícil de implementar y controlar.
34
http://es.wikipedia.org/wiki/Desarrollo_en_espiral
Página 51
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
3.2.3. Rational Unified Process
Rational Unified Process (RUP) es un modelo de proceso iterativo de
desarrollo de software, originalmente desarrollado por Rational Software, y ahora
disponible desde IBM. RUP tiene un ciclo de vida que consiste de cuatro fases:
Concepción, Elaboración, Construcción y Transición.
Estás fases permiten que el proceso sea presentado a un alto nivel en una
forma similar a como se presentaría un proyecto en cascada, aunque en esencia
la clave para el proceso yace en las iteraciones de desarrollo que se encuentran
dentro de cada fase. Además, cada fase tiene un objetivo clave y un hito al final
que denota el objetivo a ser alcanzado.
Dentro de cada iteración las tareas son categorizadas en nueve
disciplinas, de las cuales seis son disciplinas de ingeniería y tres son disciplinas
de soporte. Las disciplinas de ingeniería son: Modelado de Negocio,
Requerimientos, Análisis y Diseño, Implementación, Pruebas y Deployment. Las
disciplinas de soporte son: Gestión de cambios y configuraciones, Gestión de
proyecto y Entorno35.
RUP maneja 6 principios claves:
1. Adaptación del proceso. El proceso debe adaptarse a las necesidades
propias del proyecto: regulaciones, alcance, etc.
2. Balancear prioridades. Debe encontrarse un balance que satisfaga las
expectativas de los diferentes inversores.
3. Colaboración entre equipos. Debe haber una comunicación fluida entre
los equipos de desarrollo para coordinar requerimientos, planes,
resultados, etc.
4. Demostrar valor iterativamente. Los proyectos se analizan en etapas
iteradas, en cada iteración se decide sobre la estabilidad y calidad del
producto, también se asumen riegos involucrados.
35
http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
Página 52
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
5. Elevar el nivel de abstracción. Este principio dominante motiva el uso de
conceptos reutilizables tales como patrón del software, lenguajes 4GL o
esquemas (frameworks) por nombrar algunos. Éstos se pueden
acompañar por las representaciones visuales de la arquitectura, por
ejemplo con UML.
6. Enfocarse en la calidad. El control de calidad se analiza durante cada
proceso de la producción.
3.2.3.1. Ciclo de vida del RUP
RUP divide el proceso en 4 fases (ver figura 1.38.), dentro de las cuales
se realizan varias iteraciones en número variable según el proyecto y en las que
se hace un mayor o menor hincapié en los distintas actividades. En un tema más
adelante se explicará de mayor manera a la metodología RUP.
Figura 1.38. Ciclo de vida del RUP. Tomado de http://mdjesus.wordpress.com/2010/05/19/84/.
3.2.4. Extreme Programming
Página 53
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
La programación extrema o eXtreme Programming (XP) es un enfoque de
la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el más
destacado de los procesos ágiles de desarrollo de software. Al igual que éstos,
la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad. Los defensores de XP consideran que los cambios de requisitos
sobre la marcha son un aspecto natural, inevitable e incluso deseable del
desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximación mejor
y más realista que intentar definir todos los requisitos al comienzo del proyecto
e invertir esfuerzos después en controlar los cambios en los requisitos.
Se puede considerar la programación extrema como la adopción de las
mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a
cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del
software36.
3.3. Fases e iteraciones (en RUP)
3.3.1. Fases
Estas conforman la organización dinámica del proceso a lo largo del
tiempo. El ciclo de vida del software está dividido en ciclos, cada ciclo trabaja en
una nueva generación del producto. El Proceso Unificado divide un ciclo de
desarrollo en cuatro fases consecutivas:
1. Fase de Inicio (Inception Phase).
2. Fase de Elaboración (Elaboration Phase).
3. Fase de Construcción (Construction Phase).
4. Fase de Transición (Transition Phase).
36
Idem.
Página 54
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Cada fase es construida con hitos (un punto en el tiempo en el cual ciertas
decisiones críticas deben ser tomadas) bien definidos, y por lo tanto metas claves
han sido alcanzadas. Cada fase tiene un propósito específico:
1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el plan
de las fases y el de iteraciones posteriores.
2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de
uso que permiten definir la arquitectura base del sistema y se desarrollaran en
esta fase, se realiza la especificación de los casos de uso seleccionados y el
primer análisis del dominio del problema, se diseña la solución preliminar.
3. Fase de Construcción: El propósito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes,
administrar los cambios de acuerdo a las evaluaciones realizados por los
usuarios y se realizan las mejoras para el proyecto.
4. Fase de Transición: El propósito de esta fase es asegurar que el software
esté disponible para los usuarios finales, ajustar los errores y defectos
encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el
soporte técnico necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el proyecto.
3.3.2. Iteraciones
Cada fase en el Proceso Unificado puede ser dividida aún más en
iteraciones. Una iteración es un ciclo completo de desarrollo que resulta en una
versión (interna o externa) de un producto ejecutable, un subconjunto del
producto final bajo desarrollo, el cual crece incrementalmente de iteración en
iteración para convertirse en el sistema final.
Cada iteración pasa por todos los aspectos del desarrollo de software. Ej.
Todos los componentes de proceso, aunque con un énfasis diferente en cada
componente del proceso dependiendo de la fase.
Página 55
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
La consecuencia principal de esta aproximación iterativa es que los
artificios que describimos anteriormente crezcan y maduren a medida que el
tiempo fluye37.
En el contexto de un proyecto se refieren a la técnica de desarrollar y
entregar componentes incrementales de funcionalidades de un negocio. Esto
está comúnmente asociado al desarrollo ágil de software, pero podría referirse a
cualquier material.
Una iteración resulta en uno o más paquetes atómicos y completos del
trabajo del proyecto que pueda realizar alguna función tangible del negocio.
Múltiples iteraciones contribuyen a crear un producto completamente integrado.
A esto se lo compara comúnmente con el enfoque de desarrollo en cascada.
3.4. Artefactos y UML en RUP
3.4.1. Artefacto
En el Lenguaje Unificado de Modelado (UML), un artefacto es la
especificación de un componente físico de información que es usado o producido
por un proceso de desarrollo de software, o por el desarrollo y operación de un
sistema.1
Ejemplos de artefactos incluyen modelo de archivos, archivos fuentes,
scripts, archivos binarios ejecutables, una tabla en una base de datos, un
development deliverable, o un documento de procesamiento de texto, como un
mensaje de correo electrónico.
En UML 2.0, los artefactos son las entidades físicas que son desplegadas
en Nodos, Dispositivos y Ambientes de Ejecución. Otros elementos de UML,
tales como las clases y los componentes, son primero manifestados como
artefactos, y las instancias de dichos artefactos son luego desplegados. Los
artefactos pueden también estar compuestos por otros artefactos.
37
Idem 36.
Página 56
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
3.4.1.1. Artefactos para el Desarrollo de Proyectos
Un artefacto es una información que es utilizada o producida mediante un
proceso de desarrollo de software. Pueden ser artefactos un modelo, una
descripción o un software. Los artefactos de UML se especifican en forma de
diagramas, éstos, junto con la documentación sobre el sistema constituyen los
artefactos principales que el modelador puede observar. Se necesita más de un
punto de vista para llegar a representar un sistema. UML utiliza los diagramas
gráficos para obtener estos distintos puntos de vista de un sistema:
 Diagramas de Implementación.
 Diagramas de Comportamiento o Interacción.
 Diagramas de Casos de uso.
 Diagramas de Clases38.
3.4.2. UML en RUP
3.4.2.1. UML
El lenguaje UML se expresa con símbolos y/o agrupaciones de estos
llamadas diagramas (ver figura 1.39.). Nos sirve fundamentalmente para crear
diferentes tipos de ellos permitiéndonos ver desde diferentes perspectivas un
sistema software.
38
http://www.monografias.com/trabajos5/insof/insof.shtml
Página 57
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 1.39. Tipos de Diagramas en UML. Tomado de http://www.queinformatica.com/index.php/software/uml-lenguaje-unificado-de-modelado-2/.
Los diagramas son de gran utilidad para trabajar en los requisitos, en el
análisis del sistema, en la construcción del mismo y en su posterior despliegue.
Nos permitirán conocer ese concepto del que tanto se habla y que parece tan
difícil de determinar que es la Arquitectura del Sistema.
El UML hace que esta sea algo tangible. Siendo el resultado de agrupar
los diferentes diagramas en lo que llamamos vistas (ver figura 1.40). Estas vistas
forman la Arquitectura del Sistema. Cada una de ellas nos ofrece diferente
información sobre el sistema software:
 Vista de Casos de Uso: Nos facilita información sobre el comportamiento
y funcionalidad del sistema.
 Vista de Diseño: Nos proporciona información del vocabulario y la
funcionalidad del sistema.
 Vista de Interacción: Nos da información sobre el rendimiento del
sistema, la escalabilidad del mismo y la capacidad de procesamiento
necesaria.
 Vista de Implementación: Establece el ensamblado del sistema y la
gestión de la configuración.
Página 58
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
 Vista de Despliegue: Nos permite establecer la topología del sistema, su
distribución y las pautas para su instalación39.
Figura 1.40. Vistas del UML. Tomado de http://www.queinformatica.com/index.php/software/uml-lenguaje-unificado-de-modelado-2/.
3.6. Ejercicios de repaso
1. Realizar un resumen con la información anterior.
2. Efectuar una síntesis con el contenido de los apartados anteriores y la
información del resumen anterior.
3. Crear Mapas conceptuales de los diversos temas vistos en este capítulo.
4. Crear un cuestionario con respuestas contestadas.
39
http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-modelado/
Página 59
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Página 60
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
CAPITULO IV. PERSPECTIVA PRÁCTICA DE LOS DIAGRAMAS
Este capítulo es un enfoque práctico del uso de los diagramas del UML y
cómo se utilizan dentro de la Metodología RUP. En este apartado se irá
realizando un ejemplo aplicado de la vida real de cada uno de los diagramas
utilizados dentro del lenguaje con ayuda de la herramienta software denominada
Visual Paradigm 6.5 trial versión. Este ejemplo será un sistema de control de
rentas de películas para una empresa como de tipo Blockbuster o
Macrovideocentro.
Se escoge el software Visual Paradigm 6.5 trial versión de entre otros
conocidos, que pueden manipular los símbolos y diagramas del UML (Rational
Software, Enterprise Architect, Poseidon, Umbrello, entre otros) por su facilidad
y organización dentro de su entorno de trabajo o de diagramación, que lo hacen
más manipulable que los otros software mencionados que hay en el mercado.
La forma en cómo se van desarrollando los diferentes diagramas en este
enfoque teórico del manual es la misma que se muestra dentro del temario de la
asignatura de especialidad denominada Análisis y Diseño con Lenguaje de
Modelado Unificado, clave DSF-0701, dentro del plan de la carrera de
Licenciatura en Informática LINF 2004-303 en el Instituto Tecnológico Superior
de la Región Sierra, y también dentro de la Metodología RUP para desarrollo de
software.
Primero se muestra la simbología básica para cada diagrama, luego el
ejemplo práctico que se va a diagramar y se culmina cada apartado con unos
ejercicios prácticos, mismos que se pueden visualizar en el anexo B de este
documento, respuestas a ejercicios o prácticas de los capítulos.
Página 61
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.1. Modelos de Casos de Uso
En ellos se captura los requisitos del sistema, es decir, qué funciones va a
realizar el sistema, desde el punto de vista de la interacción con el usuario.
4.1.1. Simbología principal del diagrama
NOTACIÓN
NOMBRE
DESCRIPCIÓN
Un caso de uso es una descripción de un
conjunto de secuencias de acciones que
un sistema ejecuta y que produce un
Caso de Uso resultado observable de interés para un
actor
particular.
estructurar
los
Se
utiliza
para
aspectos
de
comportamiento en un modelo.
Es un usuario del sistema, otro sistema,
un departamento u oficina u organización
Actor
o empresa, que necesita o usa algunos
de los casos de uso.
Entre los elementos de un diagrama de
Casos de uso se pueden presentar tres
Relación
tipos de relaciones, representadas por
líneas dirigidas entre ellos (del elemento
dependiente al independiente).
Página 62
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Es una relación semántica entre dos
elementos, en la cual un cambio a un
Relación
de
elemento (el elemento independiente)
dependencia
puede afectar a la semántica del otro
elemento (el elemento dependiente).
4.1.2. Ejemplo propuesto para el diagrama de Casos de Uso
El ejercicio que se propone a modelar, a nivel de sistema y luego a nivel de
diseño, se podrá visualizar en el Anexo A, sección A, Pág. 161 de este
documento.
4.1.3.1. Construcción del diagrama de Casos de uso a nivel modelado
del negocio o de análisis del software
1.
Se abre el entorno de trabajo de Visual Paradigm 6.5 y se le da un clic en los
links iniciales a “Nuevo diagrama de casos de uso”. Ver figuras 2.1 y 2.2:
Figura 2.1. Página de bienvenida del entorno de trabajo demostrando links iniciales. Elaborada
por el realizador del documento.
Página 63
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.2. Acercamiento del área de los links iniciales. Elaborada por el realizador del
documento.
2.
Una vez que el entorno de trabajo abre éste pedirá un nombre para el diagrama
que vamos a construir, el cual se le pondrá “Diagrama de Casos de Uso 1 Nivel
Modelado Negocio”. Ver figuras 2.3 y 2.4:
Figura 2.3. Acercamiento del área del nombre del diagrama.
Figura 2.4. Área de trabajo del entorno de diagramación. Elaborada por el realizador del
documento.
3.
Acto seguido se elige del cuadro de símbolos el símbolo del Actor y se le da un
clic a la zona de trabajo; se visualizará un actor y el entorno le pedirá un nombre
pare él; para nuestro ejemplo le daremos el nombre de “Encargado”. Ver
figuras 2.5:
Página 64
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.5. Símbolo del actor en el entorno de diagramación. Elaborada por el realizador del
documento.
Figura 2.6. Visualización del actor “Encargado” en el entorno de diagramación. Elaborada por
el realizador del documento.
4.
Repetir el paso anterior para introducir tres actores más cuyos nombres serán
“Cliente”, “Administrador Junior” y “Administrador Senior”. Ver figura
anterior.
5.
Ahora se introducirán los casos de uso para cada uno de los actores. Se le da
un clic al encargado y note que mientras el puntero del ratón esta encima del
símbolo se muestra lo siguiente. Ver figura 2.7:
Figura 2.7. Actor “Administrador Junior”. Elaborada por el realizador del documento.
6.
Se elige el símbolo de la asociación y del caso de uso. Sin soltar el botón se
arrastra a un lugar fuera del símbolo anterior, en alguna parte de la zona de
trabajo y se suelta; se le pedirá introducir un dato al caso de uso. Ver figura 2.8:
Página 65
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.8. Símbolos adicionales y selección del nombre del caso de uso. Elaborada por el
realizador del documento.
7.
Se introduce lo siguiente desde teclado: “Dar de alta en el sistema anterior a
la película”. Ver figura 2.9:
Figura 2.9. Contenido del caso de uso. Elaborada por el realizador del documento.
8.
Ahora se introduce la navegabilidad de la asociación, para eso hacemos lo
siguiente: se posiciona el puntero del ratón sobre la raya/Asociación y se le da
un clic derecho para ver el menú emergente de la siguiente figura:
Figura 2.10. Menú emergente del caso de uso. Elaborada por el realizador del documento.
9.
Se elige la ruta Role A (Encargado)/Navegable/Falso, y se muestra entonces
la asociación como en la siguiente figura:
Página 66
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.11. Visualización de la asociación. Elaborada por el realizador del documento.
10.
Repetir los pasos del 5 al 9 para introducir en la zona de trabajo los siguientes
Casos de Uso: “Poner las cajas de las películas en los estantes de clientes
y los DVDs en los estantes internos”, “Verificar el estado del cliente”,
“Verificar el estado de la película”, “Capturar los datos necesarios para
realizar la renta”, “Cobrar la renta al cliente” y “Dar Comprobante de Renta
al cliente”. Ver figura 2.12:
Figura 2.12. Casos de uso siguientes. Elaborada por el realizador del documento.
11.
Ahora se introducirá unas Extensiones al caso de uso “Cobrar la Renta al
cliente”, para eso se hace lo siguiente: se selecciona al caso de uso mencionado
anteriormente para poder ver los símbolos adicionales, como en la siguiente
figura:
Página 67
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.13. Opción a usar y leyenda Extend -> Use Case. Elaborada por el realizador del
documento.
12.
Se Posiciona el puntero del ratón y se elige la opción con la leyenda “Extend ->
Use Case”. Se le da un clic al botón izquierdo, arrastre ahora a la zona de trabajo
y suelte. Se mostrará un caso de uso como en la figura siguiente:
Figura 2.14. Caso de uso adicional. Elaborada por el realizador del documento.
13.
Y se escribe dentro del caso de uso la siguiente leyenda: “Cobrar al contado”.
Ver figura 2.15:
Página 68
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.15. Texto del caso de uso. Elaborada por el realizador del documento.
14.
Repetir los pasos del 11 al 13 para introducir en la zona de trabajo otra extensión
al Caso de Uso:”Cobrar la Renta al cliente”, con la siguiente leyenda “Cobrar
con tarjeta”.
15.
Se introducirá ahora una inclusión al Caso de Uso “Cobrar con tarjeta”. para
eso se hace lo siguiente: se selecciona al caso de uso mencionado
anteriormente para poder ver los símbolos adicionales:
Figura 2.16. Opción a usar y leyenda Include -> Use Case, Elaborada por el realizador del
documento.
16.
Se Posiciona el puntero del ratón y se elige la opción con la leyenda “Include > Use Case”. Se le da un clic al botón izquierdo, se arrastra a la zona de trabajo
y se suelta.
17.
Se escribe dentro del caso de uso “Verificar el estado de cuenta del cliente”.
Ver figura 2.17:
Página 69
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.17. Texto del caso de uso. Elaborada por el realizador del documento.
18.
Se introducirá ahora multiplicidad para actores y casos de uso. Se posiciona el
puntero del ratón sobre la asociación entre el “Encargado” (Actor) y “Dar de
alta en el sistema anterior a la película nueva” (CU).
Figura 2.18. Asociación Actor-Caso de uso. Elaborada por el realizador del documento.
19.
Una vez posicionado el puntero sobre esta asociación dar clic con el botón
derecho del ratón y elegir la ruta Role A (Encargado)/Multiplicidad/1. Ver
figura 2.19:
Figura 2.19. Menú emergente 1. Elaborada por el realizador del documento.
Página 70
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
20.
Cuando se realizó esta acción se visualiza un numero “1” cerca de la asociación.
Ahora el puntero del ratón sobre la misma asociación y busca la siguiente ruta
Role B (Dar de alta a… )/ Multiplicidad/1..*. Ver figura 2.20:
Figura 2.20. Menú emergente 2. Elaborada por el realizador del documento.
21.
Los dos pasos anteriores se visualizan de la siguiente manera:
Figura 2.21. Los dos pasos anteriores. Elaborada por el realizador del documento.
22.
Repetir los pasos del 18 al 21 para introducir la multiplicidad del actor con sus
casos de uso (Encargado-Poner las cajas de las películas…, EncargadoCapturar los datos n…) que se ven en la siguiente figura 2.22:
Página 71
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.22. Asociaciones faltantes. Elaborada por el realizador del documento.
23.
Se anexará ahora una asociación Actor-Actor (Encargado-Administrador
Junior). Del panel de símbolos se da un clic a la Asociación, ahora toque el actor
“Encargado” y sin dejar de soltar el botón izquierdo del ratón arrastre hasta el
actor “Administrador Junior”, y suelte el botón. Se mostrará una línea que
relaciona a estos dos actores. Ver figuras 2.23 y 2.24:
Figura 2.23. Símbolo Asociación en el panel de símbolos. Elaborada por el realizador del
documento.
Figura 2.24. Asociación Actor-Actor. Elaborada por el realizador del documento.
Página 72
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
24.
Para distinguir a la asociación entre los actores de otras líneas dentro del área
de trabajo seleccionamos a la asociación creada anteriormente dándole un clic,
y luego ir a la Ventana de Propiedades, ubicada abajo y hacia la izquierda del
entorno de desarrollo, y seleccionar la opción Foreground y después un clic a
botón … que aparece a la derecha de esta opción. Ver figuras 2.25 y 2.26:
Figura 2.25. Panel de Propiedades. Elaborada por el realizador del documento.
Figura 2.26. Cuadro de Diálogo Línea. Elaborada por el realizador del documento.
25.
En el apartado Línea se selecciona el botón fechas Arriba-Abajo del
subapartado Weight y se le agrega 2.5 con la flecha Arriba. Ver figura 2.27:
Página 73
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.27. Apartado Línea. Elaborada por el realizador del documento.
26.
Se le da un clic al botón OK y se visualiza la asociación con una línea más gruesa
que el valor por Default.
27.
Repetir los pasos del 23 al 26 para agregar las asociaciones “EncargadoCliente”,”Encargado-Administrador
Senior”
y
“Administrador
Junior-
Administrador Senior”.
28.
Ahora se guardará el proyecto creado en Visual Paradigm 6.5. Se guardan
los últimos cambios al diagrama de casos de uso y se le da un clic al Icono
Guardar, ubicado hacia arriba y a la izquierda del entorno de desarrollo, o bien
en el Menú Archivo/Guardar Proyecto. Ver figuras 2.28 y 2.29:
Figura 2.28. Ícono Guardar. Elaborada por el realizador del documento.
Figura 2.29. Opción Guardar proyecto. Elaborada por el realizador del documento.
29. Si es la primera vez que se va a guardar el proyecto se visualiza el
siguiente cuadro de dialogo, si nó solo se guardan los últimos cambios. Ver
figura 2.30:
Página 74
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.30. Cuadro de diálogo Guardar proyecto. Elaborada por el realizador del documento.
30. El entorno de desarrollo da por defecto la opción “Guardar en área de
trabajo”, y en el apartado Destino del Cuadro de Dialogo se puede visualizar la
ruta en donde se guardará el proyecto. Si el lector quiere guardar el proyecto en
otra ruta particular, se deberá dar un clic a la opción “Guardar en directorio”, si
se requiere guardar el archivo dentro de una memoria USB se le da un clic al
botón (Ver figuras 2.31. y 2.32)…
Figura 2.31. Botón Agregar. Elaborada por el realizador del documento.
Figura 2.32. Cuadro de diálogo Guardar proyecto. Elaborada por el realizador del documento.
31. En el apartado Select the directory to use se escogerá la unidad/carpeta
principal del resguardo del proyecto, y en la parte derecha la carpeta o carpetas
secundarias que serán parte de la ruta del resguardo del proyecto. El apartado
Folder y Ruta se rellenan por defecto. Ver figura 2.33:
Página 75
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.33. Cuadro de diálogo Seleccionar directorio. Elaborada por el realizador del documento.
32. Se le da clic a OK y se regresa al entorno de desarrollo. En la Barra de
Títulos del IDE se visualiza la ruta en donde se resguardo el proyecto.
4.1.2.1. Construcción del diagrama de Casos de uso a nivel modelado
del software o de diseño
1.
Se abre el entorno de trabajo de Visual Paradigm 6.5 y entonces aparecerá por
defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl + O, dar clic en
el botón Abrir Proyecto en la barra de herramientas estándar o ir a menú
Archivo/Abrir Proyecto…, seleccionaremos nuestro proyecto anterior y espere
a que abra el entorno. Ver figura 2.34:
Página 76
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.34. Cuadro de diálogo Abrir. Elaborada por el realizador del documento.
2.
Una vez que se está en el entorno de trabajo se le dará un clic derecho sobre
la etiqueta Diagrama de Casos de Uso (1) ubicado en el panel de Diagrama de
Navegación, y luego se seleccionará el comando “Nuevo diagrama de casos
de uso”. Ver figura 2.35:
Figura 2.35. Menú emergente. Elaborada por el realizador del documento.
3.
Éste pedirá un nombre para el diagrama que vamos a construir, el cual se le
pondrá “Diagrama de Casos de Uso 1 Nivel Modelado Sistema”. Ver figura
2.36:
Página 77
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.36. Zona de escritura del nombre de diagrama y acercamiento de la zona. Elaborada
por el realizador del documento.
4.
Acto seguido se elige del Panel de símbolos el símbolo del Sistema (System)
y se le da un clic a la zona de trabajo; se visualizará un rectángulo Azul y el
entorno le pedirá un nombre pare él; para el ejemplo se le dará el nombre de
“Sistema Películas”. Ver figuras:
Figura 2.37. Símbolo de sistema. Elaborada por el realizador del documento.
Página 78
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.38. Nombre que se le dará al símbolo. Elaborada por el realizador del documento.
5.
Ahora se elige del Panel de símbolos el símbolo del Paquete (Package) y acto
seguido se le pedirá un nombre pare él; para el ejemplo se le dará el nombre de
“Control de Películas”. Ver figura 2.39:
Figura 2.39. Símbolo de paquete y Nombre que se le dará al paquete. Elaborada por el
realizador del documento.
Página 79
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
6.
Repetir el paso anterior para introducir un paquete más cuyo nombre será “Área
de Consulta”. Ver figura 2.40:
Figura 2.40. Paquetes requeridos. Elaborada por el realizador del documento.
7.
Acto seguido se elige del cuadro de símbolos el símbolo del Actor y se le da un
clic a la zona de trabajo; se visualizará un actor y el entorno le pedirá un nombre
pare él; para nuestro ejemplo le daremos el nombre de “Usuario Sistema”. Ver
figura 2.41:
Figura 2.41. Símbolo actor del panel de símbolos y Colocación del actor. Elaborada por el
realizador del documento.
8.
Repetir el paso anterior para introducir otro actor más cuyo nombre será “Base
de datos”:
Página 80
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.42. Colocación del siguiente actor. Elaborada por el realizador del documento.
9.
Ahora se introducirá los casos de uso para cada uno de los actores. Se le da un
clic al actor Usuario Sistema y note que mientras el puntero del ratón esta
encima del símbolo se muestra lo siguiente:
Figura 2.43. Opciones del actor. Elaborada por el realizador del documento.
10.
Se elige el símbolo Association -> Use Case. Sin soltar el botón se arrastra
adentro del paquete “Control de Películas” y se suelta; se le pedirá introducir
el nombre al caso de uso, el cual se llamará “Controlar Películas”, Ver figuras
2.44 y 2.45:
Figura 2.44. Opción a seleccionar. Elaborada por el realizador del documento.
Página 81
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.45. Texto a introducir del caso de uso. Elaborada por el realizador del documento.
Agregar Navegabilidad al Diagrama de Casos de Uso
11.
Ahora se introducirá la navegabilidad de la asociación, para eso se posiciona el
puntero del ratón sobre la raya/Asociación y damos un clic derecho para ver el
menú emergente de la figura 2.46:
Figura 2.46. Opción a seleccionar del menú emergente. Elaborada por el realizador del
documento.
12.
Se elige la ruta Role A (Encargado)/Navegable/Falso, y se muestra entonces
la asociación como en la figura 2.47:
Página 82
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.47. Opción a seleccionar y Texto a introducir. Elaborada por el realizador del
documento.
13.
Repetir los pasos del 9 al 12 para introducir en el paquete “Área de Consulta” el
Caso de Uso: “Mostrar Películas”. Ver figura 2.48:
Figura 2.48. Vista actual del diagrama. Elaborada por el realizador del documento.
Página 83
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Agregar Inclusiones al Diagrama de Casos de Uso
14.
Se introducirá unas inclusiones al caso de uso “Controlar Películas”; se
selecciona al caso de uso mencionado anteriormente para poder ver los
símbolos adicionales. Ver figura 2.49:
Figura 2.49. Opciones del caso de uso. Elaborada por el realizador del documento.
15.
Se Posiciona el puntero del ratón y se elige la opción con la leyenda “Include ->
Use Case”. Se le da un clic al botón izquierdo, se arrastra dentro del paquete
“Control de Películas” y se suelta. Se mostrará un caso de uso como en la
figura siguiente:
Figura 2.50. Introducción de un caso de uso tipo Include. Elaborada por el realizador del
documento.
16.
Y escribimos dentro del caso de uso la siguiente leyenda: “Registrar Películas”.
Ver figura 2.51:
Figura 2.51. Texto a introducir en el caso de uso. Elaborada por el realizador del documento.
Página 84
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
17.
Repetir los pasos del 14 al 16 para introducir en la zona de trabajo otras
inclusiones al Caso de Uso “Controlar Películas”, con la siguiente leyenda:
“Eliminar Películas” y “Modificar Películas” (Ver figura 2.52).
Figura 2.52. Inclusiones adicionales a introducir. Elaborada por el realizador del documento.
Agregar Extensiones al Diagrama de Casos de Uso
18.
Se introducirá ahora una Extensión al Caso de Uso ”Controlar Películas”; se
selecciona al caso de uso mencionado anteriormente para poder ver los
símbolos adicionales y Se Posiciona el puntero del ratón y se elige la opción con
la leyenda “Extend -> Use Case”. Se le da un clic al botón izquierdo, se arrastra
dentro del paquete “Control de Películas” y se suelta (Ver figura 2.53).
Figura 2.53. Opción a seleccionar. Elaborada por el realizador del documento.
19.
Se escribe dentro del caso de uso “Imprimir Películas”. Ver figura 2.54:
Figura 2.54. Texto introducido en el caso de uso. Elaborada por el realizador del documento.
20.
En el apartado Extension Points del Caso de Uso “Controlar Películas”, de
doble clic y escribir también “Imprimir Películas”.
Página 85
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Agregar Asociaciones al Diagrama de Casos de Uso
21.
Se anexará ahora una asociación Caso de Uso-Actor (Controlar PelículasBase de datos). Del panel de símbolos se da un clic al símbolo Asociación,
ahora toque el Caso de Uso “Controlar Películas” y sin dejar de soltar el botón
izquierdo del ratón arrastre hasta el actor “Base de datos”, y suelte el botón. Se
mostrará una línea que relaciona a estos dos objetos. Ver figura 2.55:
Figura 2.55. Símbolo Asociación en el panel de símbolos y colocación en el diagrama.
Elaborada por el realizador del documento.
22.
Repetir el paso anterior para agregar la asociación “Mostrar Películas-Base de
datos”. Ver figura 2.56:
Figura 2.56. Asociación adicional. Elaborada por el realizador del documento.
23.
El diagramado final en la fase Diagrama de Casos de Uso Nivel Diseño del
Sistema se podrá ver en el Anexo A, Sección B, Pág. 162 de esta obra.
4.1.3. Ejercicios de Repaso
Página 86
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
1. Cree un diagrama de casos de uso nivel modelado de negocios para mostrar
los roles y responsabilidades de una estación de autobuses dentro del contexto
de venta de boletos.
2. Cree otro DCU nivel modelado de negocios para mostrar los roles y
responsabilidades de una repostería dentro del contexto de venta de piezas de
pan.
3. Cree otro DCU nivel diseño de sistema para mostrar los roles y
responsabilidades de un formulario de control de autobuses dentro del contexto
del control de la venta de boletos.
4. Cree otro DCU nivel diseño de sistema para mostrar los roles y
responsabilidades de un formulario de un catálogo de postres (consulta de
postres).
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección A
4.2. Modelos de Actividades
Página 87
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Es un diagrama de pasos lógicos a seguir, prácticamente es la forma o
representación de un algoritmo, que bien puede ser lineal, condicional o cíclico.
Se podría decir que el antecesor a este esquema es el diagrama de flujo,
propuesto por Wagnier.
4.2.1. Simbología principal del diagrama
NOTACIÓN
DESCRIPCIÓN
NOMBRE
Representa un estado con acción
Estado
Acción
de
acción
interna,
con
por
lo
menos
una
transición que identifica la culminación
de la acción (por medio de un evento
implícito).
Las flechas entre estados representan
Transiciones
transiciones
con
evento
implícito.
Pueden tener una condición en el caso
de decisiones.
Se representa mediante una transición
Decisiones
múltiple que sale de un estado, donde
cada camino tiene un label (nivel)
distinto.
Pasajero Vendedor Calles o Swin Utilizadas
Lines
Inicio y fin
para
separar
responsabilidades entre los objetos.
Marca el inicio o fin de las actividades
de un proceso.
4.2.2. Ejemplo propuesto para el diagrama de Actividades
Página 88
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
El diagramado final que se realizará para este ejercicio queda como en la figura
2.57:
Figura 2.57. Ejemplo propuesto de diagrama de actividades. Elaborada por el realizador del
documento.
Nota: Cualquier duda que se tenga con las actividades siguientes se puede
recurrir a la revisión de este diagrama.
1.
Se abre el entorno de trabajo de Visual Paradigma 7 y entonces aparecerá
por defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Archivo/Cerrar Proyecto, y luego teclear el meta comando Ctrl + O, dar clic en
el botón Abrir Proyecto en la barra de herramientas estándar o ir a menú
Archivo/Abrir Proyecto…, seleccionaremos nuestro proyecto anterior y espere
a que abra el entorno. Ver figura 2.58:
Página 89
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.58. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que se está en el entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Actividades ubicada en el panel Navegación de
Diagramas, y luego se seleccionará el comando
“Nuevo diagrama de
Actividades”. Ver figura 2.59:
Figura 2.59. Cómo adicionar un nuevo diagrama. Elaborada por el realizador del documento.
3.
Éste pedirá un nombre para el diagrama que se construirá, el cual se le
pondrá “Diagrama de Actividades 1”. Ver figura 2.60:
Página 90
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.60. Área de colocación del nombre de diagrama y acercamiento. Elaborada por el
realizador del documento.
4.
Acto seguido se elige del Panel de símbolos el símbolo de Swimlane
(calle) y se le da un clic a la zona de trabajo; se visualizará un recuadro
y el entorno le pedirá un nombre pare él; para el ejemplo se le dará el
nombre de “Cliente”. Ver figura 2.61:
Figura 2.61. Símbolo de Swinlane en el panel de símbolos y nombre a introducir.
Elaborada por el realizador del documento.
5.
Repetir el paso anterior para agregar otra Swimlane que se le
denominará “Vendedor de Mostrador”.
Página 91
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
6.
Acto seguido se elige del Panel de símbolos el símbolo de Inicio y se
le da un clic a la zona de trabajo; se visualizará un círculo negro. Ver
figura 2.62:
Figura 2.62. Introducción del símbolo Initial State. Elaborada por el realizador del documento.
7.
Ahora se introducirá el símbolo de Actividad, asociado al símbolo de
Inicio. Se le da un clic al símbolo de Inicio y notamos que mientras el
puntero del ratón esta encima del símbolo se muestra lo siguiente:
Figura 2.63. Opciones a seleccionar del símbolo. Elaborada por el realizador del documento.
8.
Se elige el símbolo Transition -> Action State (el primero de los
símbolos de izquierda a derecha), y sin soltar el botón se arrastra
dentro del entorno de trabajo y se suelta. Ver figura 2.64:
Figura 2.64. Símbolo ActionState. Elaborada por el realizador del documento.
Página 92
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
9.
Se le pedirá introducir el nombre a la actividad, el cual se escribirá
“Selecciona la o las películas de su preferencia” como se visualiza
en la siguiente figura:
Figura 2.65. Texto a introducir. Elaborada por el realizador del documento.
10.
Ahora se seleccionará el símbolo que anteriormente introducimos, al
seleccionarlo aparecerán los siguientes símbolos. Ver figura 2.66:
Figura 2.66. Opción a seleccionar. Elaborada por el realizador del documento.
11.
Selecciona el segundo símbolo, cuya leyenda dice “Transition ->
Action State”, y sin soltar el botón se arrastra adentro del entorno de
trabajo y se suelta dentro del segundo Swimlane, a la derecha. Ver
figura 2.67:
Página 93
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.67. ActionState adicional. Elaborada por el realizador del documento.
12.
Se le pedirá introducir el nombre a la actividad, el cual se escribirá
“Tomar con el verificador de código de barras la clave de las
películas que el cliente tomó” como se visualiza en la figura 2.68:
Figura 2.68. Texto a introducir. Elaborada por el realizador del documento.
13.
Ahora se selecciona el último símbolo insertado para visualizar las
siguientes símbolos:
Figura 2.69. Opciones a seleccionar. Elaborada por el realizador del documento.
14.
Se elige el símbolo Transition -> Action State (el segundo símbolo
de izquierda a derecha), y sin soltar el botón arrastre adentro del
Página 94
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
entorno de trabajo y suelte. Se visualizará el siguiente símbolo. Ver
figura 2.70:
Figura 2.70. Símbolo ActionState. Elaborada por el realizador del documento.
15.
Se le pedirá introducir el nombre a la actividad, el cual se escribirá
“Indicarle al cliente el monto a pagar de la renta de películas”
como se visualiza en la siguiente figura:
Figura 2.71. Texto a introducir. Elaborada por el realizador del documento.
16.
Se repiten los pasos del 11 al 13 para agregar dos Símbolos
ActionState dentro del diagrama y le anexamos las siguientes
leyendas: “Pagar el monto de la renta de películas” y “Entregarle
las películas al cliente, Indicarle la fecha de devolución de las
películas y proporcionarle el ticket de compra” respectivamente.
Agregar una Nota al diagrama de Actividades
17.
Seleccionar ahora el ActionState que dice en su leyenda “Tomar con
el verificador de código de barras la clave de las películas que el
cliente tomó” para ver los siguientes símbolos:
Figura 2.72. Selección del Símbolo Note. Elaborada por el realizador del documento.
Página 95
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
18.
Y sin soltar el botón arrastre adentro del entorno de trabajo y suelte.
Se visualizará el siguiente símbolo. Ver figura 2.73:
Figura 2.73. Símbolo Note a usar. Elaborada por el realizador del documento.
19.
Agregar dentro de la nota la siguiente leyenda “Dentro del sistema
se va registrando y sumando la cantidad del monto que pagará el
cliente”:
Figura 2.74. Texto a introducir. Elaborada por el realizador del documento.
20.
Por último se seleccionará el ActionState con la leyenda que se
visualiza en la figura 2.75:
Figura 2.75. ActionState a seleccionar. Elaborada por el realizador del documento.
21.
Con esta acción se visualizarán los siguientes símbolos, del cual se
seleccionará Transition -> Final State:
Figura 2.76. Símbolo Final State a seleccionar. Elaborada por el realizador del documento.
Página 96
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
22.
Y sin soltar el botón arrastre adentro del entorno de trabajo y suelte.
Se visualizará el siguiente símbolo. Ver figura 2.77:
Figura 2.77. Símbolo introducido. Elaborada por el realizador del documento.
4.2.3. Ejercicios de Repaso
1. Cree un Diagrama de Actividades para mostrar los pasos a realizar del caso
de uso Vender Boleto de Autobús.
2. Cree un Diagrama de Actividades para mostrar los pasos a realizar del caso
de uso Vender pan.
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección B.
Página 97
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.3. Modelos de Secuencias
Sobresale en este modelo la capacidad de poder mostrar como es la
interacción dentro de un formulario, sea de tipo Web o de Windows; con el
usuario, un objeto, control o componente, incluso entre ellos.
4.3.1. Simbología principal del diagrama
NOTACIÓN
NOMBRE
DESCRIPCIÓN
Un objeto se representa como una línea
: Socio
vertical punteada con un rectángulo de
Línea de vida
encabezado y con rectángulos a través de
de un objeto
la línea principal que denotan la ejecución
de métodos.
Muestra el periodo de tiempo en el cual el
Activación
objeto se encuentra desarrollando alguna
operación.
El envío de mensajes entre objetos se
denota mediante una línea sólida dirigida,
Mensaje
desde el objeto que emite el mensaje
hacia el objeto que lo ejecuta.
Es un usuario del sistema, otro sistema,
un departamento u oficina u organización
Actor
o empresa, que necesita o usa algunos de
los casos de uso.
Página 98
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.3.2. Ejemplo propuesto para el diagrama de Secuencias
El Diagrama de Secuencias propuesto para este ejemplo quedará de la
siguiente forma:
Figura 2.78. Ejemplo propuesto de diagrama de secuencias. Elaborada por el realizador del
documento.
Nota: Cualquier duda que se tenga con las actividades siguientes se puede
recurrir a la revisión de este diagrama.
1.
Se abre el entorno de trabajo de Visual Paradigm 6.5 y entonces
aparecerá por defecto el último proyecto abierto; en caso de realizar otro
proyecto ir a menú Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl
+ O, dar clic en el botón Abrir Proyecto en la barra de herramientas estándar o
ir a menú Archivo/Abrir Proyecto…, seleccionaremos nuestro proyecto anterior y
espere a que cargue el entorno. Ver figura 2.79:
Página 99
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.79. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que este en el entorno de trabajo se le dará un clic derecho sobre la
etiqueta Diagrama de Secuencias ubicado en el panel de Navegación de Diagramas,
y luego se seleccionará el comando “Nuevo diagrama de Secuencia”.
Figura 2.80. Seleccionando la opción correcta. Elaborada por el realizador del documento.
3.
Éste pedirá un nombre para el diagrama que vamos a construir, el cual se le
pondrá “Diagrama de Secuencias 1” (ver figura 2.81):
Página 100
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.81. Área de inserción de nombre de diagrama y acercamiento. Elaborada por el
realizador del documento.
4.
Acto seguido elegimos del Panel de símbolos el símbolo de Actor y le damos
un clic a la zona de trabajo y el entorno le pedirá un nombre pare él; para el ejemplo se
le dará el nombre de “Usuario”. Ver figura 2.82:
Figura 2.82. Símbolo Actor en el panel de símbolos. Elaborada por el realizador del
documento.
5.
Ahora introduzca el símbolo de LifeLine, para asociarlo con el símbolo del
Usuario. De un clic al símbolo Actor (Usuario) y note que mientras el puntero del ratón
esta encima del símbolo se muestra lo siguiente:
Figura 2.83. Opción a seleccionar. Elaborada por el realizador del documento.
Página 101
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Ahora Se elige el símbolo Message -> LifeLine. Sin soltar el botón arrastre
6.
adentro del entorno de trabajo y suelte; se le pedirá introducir el nombre al símbolo
LifeLine, el cual se llamará “Interfaz Control de Películas”:
Figura 2.84. Colocación del símbolo y texto a introducir. Elaborada por el realizador del
documento.
7.
Ahora se selecciona el símbolo Message, después se le da un doble
clic y se le introducirá la siguiente leyenda “Capturar los datos de la
película y dar clic al botón Registrar”. Ver figura 2.85:
Figura 2.85. Selección del símbolo Message y Texto a introducir. Elaborada por el
realizador del documento.
Página 102
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Ahora se selecciona el símbolo LifeLine introducido para mostrar los
8.
símbolos que aparecen en la figura siguiente:
Figura 2.86. Opciones del símbolo LifeLine. Elaborada por el realizador del documento.
Se escoge el símbolo cuya leyenda dice Self Message -> LifeLine.
9.
Sin soltar el botón arrastre adentro del entorno de trabajo y suelte; se
le pedirá introducir el nombre al símbolo Self Message que aparece,
el cual se dirá “Conectar con la Base de Datos”. Ver figura 2.87:
Figura 2.87. Selección de opción y texto a introducir. Elaborada por el realizador del
documento.
10.
Seleccionar el LifeLine Interfaz Control de Películas y repetir los
pasos del 5 al 7 para introducir un LifeLine y un Message que digan
“Tabla Películas” y “Verificar si la película no está registrada”
respectivamente:
Página 103
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.88. Textos a introducir. Elaborada por el realizador del documento.
11.
Ahora se selecciona el último LifeLine que se introdujo y se repiten los
pasos 8 y 9 para introducir un Self Message el cual dirá “Búsqueda
de la película”:
Figura 2.89. Texto a introducir. Elaborada por el realizador del documento.
12.
Ahora, tocando el LifeLine Tabla Películas aparecerá el siguiente
símbolo (Ver figura 2.90):
Página 104
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.90. Opción a seleccionar. Elaborada por el realizador del documento.
13.
Se toma al Message -> LifeLine, se mantiene apretado y se suelta
hasta tocar el LifeLine llamado Interfaz Control de Películas. Ver
figura 2.91:
Figura 2.91. Colocación del símbolo Message. Elaborada por el realizador del documento.
14.
El message debe decir “Película no encontrada”.
15.
Repetir los pasos del 12 al 14 para introducir otro Message dentro del
diagrama, del LifeLine Interfaz Control de Películas al LifeLine Tabla
Películas. El message debe decir “Registrar datos de la película”:
Figura 2.92. Texto a introducir. Elaborada por el realizador del documento.
16.
Nuevamente repetir los pasos del 12 al 14 para introducir otro Message
dentro del diagrama. Del LifeLine Interfaz Control de Películas al
Página 105
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Usuario. El message debe decir “Mostrar mensaje al usuario de
registro de película exitoso”. Ver figura 2.93:
Figura 2.93. Texto a introducir 1. Elaborada por el realizador del documento.
17.
Nuevamente repetir los pasos del 12 al 14 para introducir otro Message
dentro del diagrama. Del LifeLine Interfaz Control de Películas al
Tabla Películas. El message debe decir “Película encontrada”:
Figura 2.94. Texto a introducir 2. Elaborada por el realizador del documento.
18.
Nuevamente repetir los pasos del 12 al 14 para introducir otro Message
dentro del diagrama. Del LifeLine Interfaz Control de Películas al
LifeLine Usuario. El message debe decir “Mostrar mensaje al
usuario de registro de película no exitoso”:
Figura 2.95. Texto a introducir 3. Elaborada por el realizador del documento.
19.
Por último se introducirá un Alt. Combined Fragment. Dentro del
panel de símbolos se buscará el siguiente ícono. Ver figura 2.96:
Página 106
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.96. Símbolo A introducir desde el panel de símbolos. Elaborada por el realizador
del documento.
20.
Se le da un clic al comando y otro clic dentro del área de trabajo, para
visualizar el siguiente símbolo:
Figura 2.97. Símbolo Alt. Combined Fragment. Elaborada por el realizador del documento.
21.
En el botón negro, ubicado abajo y a la derecha del símbolo anterior,
de un clic, arrastre hacia la derecha y toque los tres LifeLine Usuario,
Interfaz Control de Películas y Tabla Películas. Ubicando los tres
LifeLines dentro del símbolo Alt. Combined Fragment suelte el botón
izquierdo del Mouse. Trate de ubicar el símbolo a como se muestra en
la figura 2.98:
Figura 2.98. Área a abarcar con el símbolo Alt. Combined Fragment. Elaborada por el
realizador del documento.
22.
Los puntos del 5 al 7 serán una respuesta satisfactoria de la interfaz.
Los puntos 8 y 9 serán una respuesta negativa de la interfaz. Compara
tu diagrama de secuencias realizado con el propuesto en esta sección.
Página 107
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.3.3. Ejercicios de Repaso
1. Cree un Diagrama de Secuencias para mostrar los pasos a realizar para dar
de alta aun autobús dentro de un formulario de control de autobuses.
2. Cree un Diagrama de Secuencias para mostrar los pasos a realizar para
modificar los datos de un postre dentro de un formulario de control de postres.
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección C.
Página 108
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.4. Modelos de Clases
Esta es la nueva forma de representar a un esquema de base de datos;
se puede decir con toda certeza que este tipo de diagrama reemplazará al
modelo relacional que la mayoría de los sistemas gestores de bases de datos
actuales tienen para representar sus tablas y relaciones entre éstas.
4.4.1. Simbología principal del diagrama
NOTACIÓN
DESCRIPCIÓN
NOMBRE
Una clase describe un conjunto
de objetos con características y
Clase
comportamiento idéntico.
Una asociación, en general, es
una línea que une dos o más
Asociación
símbolos. Pueden tener varios
tipos de adornos, que definen su
semántica y características.
Un paquete es una forma de
Ventas
agrupar
Paquete
elementos
clases
en
otro
(u
otros
tipo
de
diagramas) en modelos grandes.
Denota una relación semántica
entre dos elementos (clases o
Relación
de
Dependencia
paquetes, por el momento) del
modelo. Indica que cambiar el
elemento independiente puede
requerir
cambios
en
los
dependientes.
4.4.2. Ejemplo propuesto para el diagrama de Clases
Página 109
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.99. Ejemplo propuesto de diagrama de clases. Elaborada por el realizador del
documento.
1.
Abrimos el entorno de trabajo de Visual Paradigm 6.5 y entonces
aparecerá por defecto el último proyecto abierto; en caso de realizar otro
proyecto ir a menú Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl
+ O, dar clic en el botón Abrir Proyecto en la barra de herramientas estándar o
ir a menú Archivo/Abrir Proyecto…, seleccionaremos nuestro proyecto anterior y
esperamos a que abra el entorno. Ver figura 2.100:
Página 110
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.100. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que estemos en nuestro entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Clases ubicado en el panel de Diagrama de Navegación,
y luego se seleccionará el comando “Nuevo diagrama de Clases”. Ver figura 2.102:
Figura 2.101. Selección del comando correcto. Elaborada por el realizador del documento.
3.
éste pedirá un nombre para el diagrama que vamos a construir, el cual le
pondremos “Diagrama de Clases 1”:
Figura 2.102. Área de introducción de nombre de diagrama. Elaborada por el realizador del
documento.
Página 111
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.
Acto seguido elegimos del Panel de símbolos el símbolo de la Clase y le damos
un clic a la zona de trabajo y el entorno le pedirá un nombre pare él; para el ejemplo se
le dará el nombre de “Diagrama de Clases Base de Datos”:
Figura 2.103. Texto a introducir. Elaborada por el realizador del documento.
5.
Ahora se introducirá el símbolo de Clase. De un clic al símbolo de Clase dentro
del entorno de trabajo. Ver figura 2.104:
Figura 2.104. Símbolo a introducir en el panel y colocación en el área de trabajo. Elaborada
por el realizador del documento.
6. Aparece la palabra Class Seleccionada, lista para cambiarle el nombre. El nombre
de la clase será Clientes. Note que mientras el puntero del ratón esta encima del
símbolo se muestra lo siguiente:
Figura 2.105. Opciones del símbolo. Elaborada por el realizador del documento.
Página 112
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
7. Elegimos el símbolo Association -> Class. Sin soltar el botón arrastramos adentro
del entorno de trabajo y soltamos; se le pedirá introducir el nombre de la siguiente clase,
el cual se llamará “NotaRemision”. Ver figura 106:
Figura 2.106. Clase adicional y texto a introducir. Elaborada por el realizador del documento.
8. Se procede ahora a cargar las propiedades de la clase clientes. De un clic
derecho sobre la clase mencionada para mostrar un menú emergente, del cual
seleccionará el comando Abrir Especificación…
Figura 2.107. Comando Abrir especificación. Elaborada por el realizador del documento.
9. En pantalla se muestra el cuadro de diálogo Class Specification. Ver figura
2.108:
Página 113
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.108. Cuadro de diálogo Especificación de clase. Elaborada por el realizador del
documento.
10. De la ventana mostrada se le dará un clic a la pestaña Attributes, que
mostrará los siguientes datos:
Figura 2.109. Pestaña Attributes. Elaborada por el realizador del documento.
11. De un clic al botón Añadir, ubicado abajo y hacia la derecha del cuadro de
diálogo, y se mostrará lo siguiente:
Página 114
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.110. Cuadro de diálogo Attribute Specification. Elaborada por el realizador del
documento.
12. En el cuadro de diálogo Attribute Specification, por defecto está
seleccionado, en el apartado nombre, un valor estándar para denominar al
atributo o propiedad, cambie el nombre actual seleccionado por RFC:
Figura 2.111. Texto a introducir. Elaborada por el realizador del documento.
13. En el apartado Tipo se le capturará el valor de string(15). Ver figura 2.112:
Figura 2.112. Cuadro de texto Tipo. Elaborada por el realizador del documento.
Página 115
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
14. En el apartado Visibilidad se le cambiará el valor Privado por defecto, por
el de Protegidos, dándole un clic al botón del cuadro combinado y
seleccionando la opción mencionada, y se le da un clic al botón OK, ubicado
abajo:
Figura 2.113. Texto a seleccionar del cuadro combinado Visibilidad. Elaborada por el
realizador del documento.
15. El cuadro de diálogo Class Specification se mostrará de la siguiente
manera:
Figura 2.114. Visualización actual. Elaborada por el realizador del documento.
16. Repetir los pasos del 11 al 15 para introducir los siguientes atributos a la
clase Clientes (en el apartado Visibilidad para los siguientes atributos se dejará
el valor por defecto, Privado): nombre, ApellidoPat, ApellidoMat, direccion,
telefono. Ver figura 2.115:
Página 116
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.115. Textos a introducir. Elaborada por el realizador del documento.
17. La vista de la clase dentro del diagrama queda de la siguiente manera:
Figura 2.116. Apariencia clase actual. Elaborada por el realizador del documento.
18. Ahora se introducirán las operaciones a programar que se realizarán con la
clase. Tocando el nombre de la clase Clientes se da un clic derecho y se
selecciona del menú emergente el comando Abrir Especificación:
Página 117
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.117. Comando Abrir Especificación. Elaborada por el realizador del documento.
19. Del cuadro de dialogo Class Specification se le da un clic a la pestaña
Operations (ver figura 2.118):
Figura 2.118. Pestaña Operations del cuadro de diálogo Class Specification. Elaborada por el
realizador del documento.
20. De un clic al botón Añadir, ubicado abajo y hacia la derecha del cuadro de
diálogo, y se mostrará lo siguiente:
Página 118
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.119. Cuadro de diálogo Operation Specification. Elaborada por el realizador del
documento.
21. En el cuadro de diálogo Operation Specification, por defecto está
seleccionado, en el apartado nombre, un valor estándar para denominar a la
operación, cambie el nombre actual seleccionado por el de Registrar:
Figura 2.120. Texto a introducir. Elaborada por el realizador del documento.
22. Dar clic al botón OK, ubicado abajo y hacia la derecha. En el cuadro de
dialogo Class Specification se mostrará de la siguiente manera:
Página 119
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.121. Cuadro de dialogo Class Specification. Elaborada por el realizador del
documento.
23. Dar clic al botón OK y en el diagrama de clases se mostrará la figura
siguiente:
Figura 2.122. Clase Clientes. Elaborada por el realizador del documento.
24. Repetir los pasos del 18 al 23 para introducir las siguientes operaciones:
Eliminar, Modificar, Consultar, Imprimir. La clase queda de la siguiente
manera (ver figura 2.123):
Página 120
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.123. Operaciones de la clase Clientes. Elaborada por el realizador del documento.
25. Se le pondrá Multiplicidad a la asociación entre las clases Clientes y
NotaRemision:
Figura 2.124. Relación entre la clase Clientes y la clase NotaRemisión. Elaborada por el
realizador del documento.
26. Se posiciona el puntero del ratón sobre la asociación entre las clases
Clientes y NotaRemision, y se le da un clic al botón derecho del ratón para
mostrar en pantalla el siguiente menú emergente. Ver figura 2.125:
Figura 2.125. Seleccionando el comando Abrir Especificación. Elaborada por el realizador del
documento.
Página 121
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
27. Se selecciona la opción Role B (Clientes)/Multiplicidad/1, tal y como se
muestra la siguiente figura:
Figura 2.126. Seleccionando la opción Role B. Elaborada por el realizador del documento.
28. En el diagrama de Clases se muestra el cambio realizado de la siguiente
manera. Ver figura 2.126:
Figura 2.127. Multiplicidad 1. Elaborada por el realizador del documento.
29. Ahora se selecciona la opción Role A (NotaRemision)/Multiplicidad/*, tal y
como se muestra la figura 2.128:
Página 122
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.128. Seleccionando la opción Role A. Elaborada por el realizador del documento.
30. En el diagrama de Clases se muestra el cambio realizado de la siguiente
manera:
Figura 2.129. Multiplicidad 2. Elaborada por el realizador del documento.
31. Ahora se repiten los pasos del 5 al 30 para agregar las siguientes clases, con
sus atributos y operaciones, y su multiplicidad, tal y como se muestra en el
diagrama de clases propuesto para este apartado:
Usuarios
Atributo
Tipo
Visibilidad
CveUsuario
Int
Protegido
nombre
String(30)
Privado
Página 123
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
ApellidoPat
string(30)
Privado
ApellidoMat
string(30)
Privado
direccion
string(40)
Privado
telefono
string(40)
Privado
Operaciones
Nombre
Visibilidad
Registrar
Privado
Eliminar
Privado
Modificar
Privado
Consultar
Privado
Imprimir
Privado
Películas
Atributo
Tipo
Visibilidad
CvePelicula
Int
Protegido
titulo
String
Privado
Año
DateTime
Privado
Director
String
Privado
actores
string
Privado
sinopsis
string
Privado
Operaciones
Nombre
Visibilidad
Página 124
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Registrar
Privado
Eliminar
Privado
Modificar
Privado
Consultar
Privado
Imprimir
Privado
NotaRemision (La clase ya está en el diagrama, solo le falta sus atributos y
operaciones)
Atributo
Tipo
Visibilidad
NoFolio
Int
Protegido
Fecha
DateTime
Privado
CveCliente
Int
Privado
Total
double
Privado
Operaciones
Nombre
Visibilidad
Registrar
Privado
Eliminar
Privado
Modificar
Privado
Consultar
Privado
Imprimir
Privado
DetallesNotaRemision
Página 125
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Atributo
Tipo
Visibilidad
NoFolio
Int
Privado
CvePelicula
Int
Privado
Cantidad
Int
Privado
PrecioVta
double
Privado
Importe
double
Privado
32. Comparar su diagrama con el propuesto para este apartado.
4.4.3. Ejercicios de Repaso
1. Cree un Diagrama de Clases que muestre el modelo relacional de una base
de datos para el control de préstamos dentro de una biblioteca.
2. Cree un Diagrama de Clases que muestre el modelo relacional de una base
de datos para el control de ventas dentro de una refaccionaria.
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección D.
Página 126
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.5. Modelos de Estados
4.5.1. Simbología principal del diagrama de Estados
NOTACIÓN
DESCRIPCIÓN
NOMBRE
Identifica un periodo de tiempo del
objeto (no instantáneo) en el cual el
objeto
Estado
esta
operación,
Selecc_Azucar
esperando
tiene
alguna
cierto
estado
característico o puede recibir cierto
tipo de estímulos.
Es una ocurrencia que puede causar
Devolver
la transición de un estado a otro de un
Evento
[número_préstamos = 1]
objeto.
Las
Transiciones
flechas
entre
estados
representan transiciones con evento
implícito. Pueden tener una condición
en el caso de decisiones.
Denota una relación semántica entre
dos elementos (clases o paquetes,
Relación
de por el momento) del modelo. Indica
Dependencia que
cambiar
independiente
el
puede
elemento
requerir
cambios en los dependientes.
4.5.2. Ejemplo propuesto para el diagrama de Estados
Página 127
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
El diagrama propuesto para este apartado es el siguiente:
Figura 2.130. Ejemplo de diagrama de estados propuesto. Elaborada por el realizador del
documento.
1.
Abrimos el entorno de trabajo de Visual Paradigm 6.5 y entonces aparecerá por
defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl + O, dar clic en el botón
Abrir Proyecto
en la barra de herramientas estándar o ir a menú Archivo/Abrir
Proyecto…, seleccionaremos nuestro proyecto anterior y esperamos a que abra el
entorno.
Figura 2.131. Entorno de diagramación. Elaborada por el realizador del documento.
3. Una vez que estemos en nuestro entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Estados ubicado en el panel de Diagrama de
Página 128
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Navegación, y luego se seleccionará el comando “Nuevo diagrama de Máquina
de Estados”. Ver figura 2.132:
Figura 2.132. Selección de comando correcto. Elaborada por el realizador del documento.
3.
éste pedirá un nombre para el diagrama que vamos a construir, el cual le
pondremos “Diagrama de Estados 1” (ver figura 2.133):
Figura 2.133. Área de introducción del nombre de diagrama. Elaborada por el realizador del
documento.
4.
Acto seguido elegimos del Panel de símbolos el símbolo Initial State y le damos
un clic a la zona de trabajo (ver figura2.134):
Figura 2.134. Selección del símbolo Initial State. Elaborada por el realizador del documento.
5.
Note Usted los símbolos asociados a símbolo Initial State. Se escoge aquel que
contiene la leyenda Transition -> State,
y sin soltar el botón izquierdo de ratón
arrastramos adentro del entorno de trabajo y soltamos a la derecha; se le pedirá
introducir el nombre al estado, el cual se llamará “Película comprada”:
Página 129
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.135. Opciones de símbolo Initial State, selección de la opción correcta y texto a
introducir. Elaborada por el realizador del documento.
6. Seleccione el Estado “Película comprada” y note los símbolos que aparecen en su
contorno. Ver figura 2.136:
Figura 2.136. Opciones del símbolo State. Elaborada por el realizador del documento.
7. Se escoge aquel que contiene la leyenda Transition -> State, y sin soltar el botón
izquierdo de ratón arrastramos adentro del entorno de trabajo y soltamos a la derecha;
se le pedirá introducir el nombre al estado, el cual se llamará “Película registrada”:
Página 130
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.137. Texto a introducir. Elaborada por el realizador del documento.
8. Ahora repita los pasos 6 y 7 para introducir de manera similar los siguientes
estados: Película disponible, Película rentada, Película rentada, Película
devuelta y Película desechada. Ver figura 2.138:
Figura 2.138. Estados a introducir en el área de trabajo. Elaborada por el realizador del
documento.
9. Seleccione el Estado “Película desechada” y note los símbolos que aparecen en su
contorno (ver figura 2.139):
Figura 2.139. Opciones del estado seleccionado. Elaborada por el realizador del documento.
10. Se selecciona el símbolo con la leyenda Transition -> Final State, se
arrastra y se suelta a la izquierda del último símbolo State:
Página 131
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.140. Símbolo Final State. Elaborada por el realizador del documento.
11. Se selecciona el State con la leyenda “Película devuelta” para ver la siguiente
simbología (ver figura 2.141):
Figura 2.141. Opciones del estado seleccionado. Elaborada por el realizador del documento.
12. Se escoge aquel símbolo que contiene la leyenda Transition -> State, y sin soltar
el botón izquierdo de ratón arrastramos hacia el State “Película disponible”:
Figura 2.142. Colocación del estado seleccionado. Elaborada por el realizador del documento.
13. Ahora se le da doble clic a la transición entre el símbolo Initial State y el
State “Película comprada”, y se le escribe la siguiente leyenda “Enviar Película
al gerente (por el proveedor)”. Ver figura 2.143:
Página 132
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.143. Texto a introducir. Elaborada por el realizador del documento.
14. Ahora se le da doble clic a la transición entre el símbolo State “Película
comprada” y el State “Película registrada”, y se le escribe la siguiente leyenda
“Verificar daños de fábrica o físicos durante el viaje” (ver figura 2.144):
Figura 2.144. Texto a introducir. Elaborada por el realizador del documento.
15. Repita el paso anterior para anexar las siguientes leyendas de las diferentes
transiciones dentro del diagrama: “Catalogar la película para servicio de renta
a los clientes”, “Rentar la película por uno o varios días (el socio)”, “Dejar
película en el buzón después de usarla (socio)”, “Verificar si existe
rentabilidad de la película” y “Verificar daños físicos por el socio o recargos
del mismo” (Mirar el diagrama propuesto para este apartado para verificar la
posición de las leyendas en las transiciones).
4.5.3. Ejercicios de Repaso
Página 133
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
1. Crear un diagrama que muestre los estados de un libro, desde que se compra
a un proveedor hasta que se presta a un derechohabiente dentro de una
biblioteca.
2. Crear un diagrama que muestre los estados de un paquete, desde que se
recepciona hasta que se entrega a su dueño, dentro de un servicio de
paquetería.
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección E.
Página 134
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.6. Modelos de Colaboración
4.6.1. Simbología principal del diagrama
NOTACIÓN
NOMBRE
DESCRIPCIÓN
Un objeto es la instancia de una clase (o
: Socio
categoría). Es una entidad que tiene
Objeto
valores específicos de los atributos y
operaciones o acciones).
Un enlace es una instancia de una
asociación
en
un
diagrama
de
Enlace
colaboración. Se representa como una
línea continua que une a dos objetos.
Flujo
de Expresa el envío de un mensaje.
Mensajes
Página 135
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.6.2. Ejemplo propuesto para el diagrama de Colaboración
Figura 2.145. Ejemplo propuesto de diagrama de colaboración. Elaborada por el realizador del
documento.
1.
Abrimos el entorno de trabajo de Visual Paradigm 6.5 y entonces aparecerá por
defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl + O, dar clic en el botón
Abrir Proyecto
en la barra de herramientas estándar o ir a menú Archivo/Abrir
Proyecto…, seleccionaremos nuestro proyecto anterior y esperamos a que abra el
entorno (ver figura 2.146):
Página 136
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.146. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que estemos en nuestro entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Comunicación ubicado en el Panel de Diagrama de
Navegación, y luego se seleccionará el comando “Nuevo diagrama de Colaboración”
y se le da un clic. Ver figura 2.147:
Figura 2.147. Selección del comando correcto. Elaborada por el realizador del documento.
3. Éste pedirá un nombre para el diagrama que vamos a construir, el cual le pondremos
“Diagrama de Comunicación 1” (ver figura 2.148):
Figura 2.148. Área de introducción de nombre de diagrama. Elaborada por el realizador del
documento.
Página 137
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Acto seguido elegimos del Panel de símbolos el símbolo Actor y le damos un
4.
clic a la zona de trabajo y el entorno le pedirá un nombre pare él; para el ejemplo se le
dará el nombre de “Usuario” (ver figura 2.149):
Figura 2.149. Símbolo Actor del panel de símbolos y colocación en el área de trabajo.
Elaborada por el realizador del documento.
Ahora vamos a introducir el símbolo de LifeLine, para asociarlo con el símbolo
5.
anterior. Damos un clic al símbolo Actor que se introdujo dentro del entorno de trabajo
y note que mientras el puntero del ratón esta encima del símbolo se muestra la figura
2.150:
Figura 2.150. Opciones del símbolo Actor a seleccionar. Elaborada por el realizador del
documento.
6.
Elegimos el símbolo Message -> LifeLine. Sin soltar el botón arrastramos hacia
la izquierda y soltamos; se le pedirá introducir el nombre al LifeLine, el cual se llamará
“Interfaz Control de Películas”:
Figura 2.151. Selección del símbolo y texto a introducir. Elaborada por el realizador del
documento.
Página 138
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
7. Note que en la asociación se puede visualizar el número 1, al cual se le dará
un doble clic y se le agregará la siguiente leyenda “Capturar datos de película
y dar clic al botón Registrar” (ver figura 2.152):
Figura 2.152. Selección de la Asociación y Texto a introducir. Elaborada por el realizador del
documento.
8. Se le da un clic al símbolo LifeLine introducido dentro del área de trabajo para
visualizar los símbolos asociados a ella, y se seleccionará Self Message>LifeLine, y se visualizará una asociación como en la figura 2.153:
Figura 2.153. Selección de la opción y visualización del símbolo. Elaborada por el realizador
del documento.
9. Se le agregará la siguiente leyenda “Conectar con la base de datos” (ver
figura 2.154):
Página 139
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.154. Texto a introducir. Elaborada por el realizador del documento.
10. Se repite el paso 6 para agregar otro LifeLine. Arrastramos hacia abajo y
soltamos; se le pedirá introducir el nombre al LifeLine, el cual se llamará “Tabla
Películas”:
Figura 2.155. Agregación de LifeLine adicional y texto a introducir. Elaborada por el realizador
del documento.
11. Note que en la asociación se puede visualizar el número 3, al cual se le dará
un doble clic y se le agregará la siguiente leyenda “Verificar si la película no
está registrada” (ver figura 2.156):
Figura 2.156. Texto a introducir en la Asociación. Elaborada por el realizador del documento.
Página 140
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
12. Seleccione el LifeLine anterior para visualizar los diferentes símbolos
asociados a él, y seleccione Self Message -> LifeLine y se le agrega la siguiente
leyenda: “Búsqueda de película”. Ver figura 2.157:
Figura 2.157. Texto a introducir en el Self Message. Elaborada por el realizador del
documento.
13. Vuelva a seleccionar el LifeLine Tabla Películas para visualizar los diferentes
símbolos asociados a él, y seleccione el símbolo Message -> LifeLine.
Mantenga el botón izquierdo del ratón presionado y suelte hasta tocar el LifeLine
Interfaz Control de Películas. Ver figura 2.158:
Figura 2.158. Selección del símbolo indicado. Elaborada por el realizador del documento.
14. Se selecciona el número cinco aparecido dentro del diagrama, se le da doble
clic y se le inserta la siguiente leyenda: “Película no encontrada”. Ver figura
2.159:
Figura 2.159. Texto a introducir en la numeración indicada. Elaborada por el realizador del
documento.
Página 141
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
15. Para insertar la leyenda del paso número 6 vuelva el repetir el paso 14. La
leyenda dirá: “Mostrar mensaje de registro exitoso”. Ver la figura 2.160:
Figura 2.160. Texto a introducir en la Asociación. Elaborada por el realizador del documento.
16. Comparar el diagrama que ha realizado con el propuesto en este apartado.
4.6.3. Ejercicios de Repaso
1. Cree un Diagrama de Colaboración para mostrar los pasos a realizar para dar
de alta aun autobús dentro de un formulario de control de autobuses.
2. Cree un Diagrama de Colaboración para mostrar los pasos a realizar para
modificar los datos de un postre dentro de un formulario de control de postres.
NOTA: Ver ejemplos de los ejercicios en el anexo B, sección F.
Página 142
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.7. Modelos de Componentes
4.7.1. Simbología principal del diagrama
NOTACIÓN
DESCRIPCIÓN
NOMBRE
Un componente representa una
unidad de código (fuente, binario o
ejecutable) que permite mostrar las
Componente
dependencias
en
tiempo
de
compilación y ejecución. Pueden
mostrar también que interfaces
implementan
y
qué
objetos
contienen.
4.7.2. Ejemplo propuesto para el diagrama de Componentes
Figura 2.161. Ejemplo propuesto de diagrama de componentes. Elaborada por el realizador del
documento.
1.
Abrimos el entorno de trabajo de Visual Paradigm 6.5 y entonces aparecerá por
defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Página 143
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl + O, dar clic en el botón
Abrir Proyecto
en la barra de herramientas estándar o ir a menú Archivo/Abrir
Proyecto…, seleccionaremos nuestro proyecto anterior y esperamos a que abra el
entorno. Ver figura 2.162:
Figura 2.162. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que estemos en nuestro entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Componentes ubicado en el panel de Diagrama de
Navegación, y luego se seleccionará el comando “Nuevo diagrama de Componentes”.
Figura 2.163. Selección de comando correcto. Elaborada por el realizador del documento.
3.
Éste pedirá un nombre para el diagrama que vamos a construir, el cual le
pondremos “Diagrama de Componentes 1” (ver figura 2.164):
Página 144
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.164. Área de introducción de nombre de diagrama. Elaborada por el realizador del
documento.
4.
Acto seguido elegimos del Panel de símbolos el símbolo Interface y le damos
un clic a la zona de trabajo y el entorno le pedirá un nombre pare él; para el ejemplo se
le dará el nombre de “Control de Películas (cliente)”:
Figura 2.165. Símbolo Interface y texto a introducir. Elaborada por el realizador del documento.
5.
Ahora se introducirá el símbolo Component, para asociarlo con el símbolo
anterior. Damos un clic al símbolo anterior dentro del entorno de trabajo y note que
mientras el puntero del ratón esta encima del símbolo se muestra lo siguiente:
Figura 2.166. Opciones del Símbolo Interface a seleccionar. Elaborada por el realizador del
documento.
6.
Elegimos el símbolo Association -> Component. Sin soltar el botón arrastramos
adentro del entorno de trabajo y soltamos; se le pedirá introducir el nombre al
componente, el cual se llamará “AccesoDatos.cs (Cliente)”. Ver figura 2.167
Página 145
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.167. Opción a escoger del símbolo Interface y texto a introducir. Elaborada por el
realizador del documento.
7. Selecciona ahora el componente anterior y se repiten los pasos 5 y 6 para insertar
dentro del entorno de desarrollo el componente denominado “DatosMacroVideo.mdf
(Servidor)”. Ver la figura 2.168:
Figura 2.168. Texto a introducir. Elaborada por el realizador del documento.
8. Ahora se selecciona el último componente (DatosMacroVideo.mdf (Servidor)) para
visualizar los símbolos asociados a éste:
Página 146
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.169. Opciones del símbolo Component. Elaborada por el realizador del documento.
9. Elegimos el símbolo Association -> Component. Sin soltar el botón arrastramos
adentro del entorno de trabajo y soltamos; se le pedirá introducir el nombre al estado, el
cual se llamará “AccesoDatos.cs (Servidor)” (ver figura 2.170):
Figura 2.170. Texto a introducir en el componente. Elaborada por el realizador del documento.
10. Ahora se selecciona el último componente (AccesoDatos.cs (Servidor)) para
visualizar los símbolos asociados a éste:
Figura 2.171. Opciones del símbolo componente. Elaborada por el realizador del documento.
11. Elegimos el símbolo Usage -> Interface. Sin soltar el botón arrastramos adentro del
entorno de trabajo y soltamos; se le pedirá introducir el nombre al componente, el cual
se llamará “Sistema de Admon. (Servidor)” (ver figura 2.172):
Página 147
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.172. Texto a introducir en la interfase. Elaborada por el realizador del documento.
12. verificar y acomodar el diagrama a como esta el ejemplo de este apartado.
4.7.3. Ejercicios de Repaso
1. Cree un diagrama de componentes que muestre una arquitectura software de
tres capas para un sistema de control de boletos de autobús, modelo clienteservidor.
NOTA: Ver ejemplos del ejercicio en el anexo B, sección G.
Página 148
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
4.8. Modelos de Despliegue o Distribución
4.8.1. Simbología principal del diagrama
NOTACIÓN
DESCRIPCIÓN
NOMBRE
Un
componente
representa
una
unidad de código (fuente, binario o
ejecutable) que permite mostrar las
Componente
dependencias
en
tiempo
de
compilación y ejecución. Pueden
mostrar
también
implementan
y
que
qué
interfaces
objetos
contienen.
4.8.2. Ejemplo propuesto para el diagrama de Despliegue o Distribución
Así le deberá de quedar el diagrama al final de este ejercicio. Ver figura 2.173:
Figura 2.173. Ejemplo propuesto de diagrama de distribución. Elaborada por el realizador del
documento.
1.
Abrimos el entorno de trabajo de Visual Paradigm 6.5 y entonces aparecerá por
defecto el último proyecto abierto; en caso de realizar otro proyecto ir a menú
Archivo/Cerrar Proyecto, y luego teclear el metacomando Ctrl + O, dar clic en el botón
Página 149
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Abrir Proyecto
en la barra de herramientas estándar o ir a menú Archivo/Abrir
Proyecto…, seleccionaremos nuestro proyecto anterior y esperamos a que abra el
entorno. Ver figura 2.174:
Figura 2.174. Entorno de diagramación. Elaborada por el realizador del documento.
2.
Una vez que estemos en nuestro entorno de trabajo se le dará un clic derecho
sobre la etiqueta Diagrama de Despliegue ubicado en el panel de Diagrama de
Navegación, y luego se seleccionará el comando “Nuevo diagrama de Despliegue”.
Figura 2.175. Comando a seleccionar. Elaborada por el realizador del documento.
3.
éste pedirá un nombre para el diagrama que vamos a construir, el cual le
pondremos “Diagrama de Despliegue 1”:
Página 150
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.176. Nombre de diagrama. Elaborada por el realizador del documento.
4.
Acto seguido se elige del Panel de símbolos el símbolo denominado Paquete, y
se le da un clic a la zona de trabajo, y el entorno le pedirá un nombre pare él; para el
ejemplo se le dará el nombre de “Departamento de RH” y trate de dimensionarlo como
se ve en la figura siguiente:
Figura 2.177. Símbolo a seleccionar y texto a introducir. Elaborada por el realizador del
documento.
5. Repite el paso anterior para introducir tres paquetes más dentro del área de trabajo
de la siguiente manera:
Página 151
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.178. Paquetes adicionales a introducir. Elaborada por el realizador del documento.
Introduzca los siguientes nombres en cada paquete: Departamento de Finanzas,
Departamento de Recursos Materiales y Departamento de Ventas.
6. Ahora se introducirá el símbolo Node, al cual se le dará el nombre de SWITCH. Ver
figura 2.179:
Figura 2.179. Símbolo a seleccionar y texto a introducir. Elaborada por el realizador del
documento.
Página 152
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
7. Ahora se introducirá otros símbolos Node, y se asocian con los símbolos Paquete de
la siguiente manera. También Introduzca los siguientes nombres en cada Nodo: PC1,
PC2, PC3, PC4 y Servidor. Ver figura 2.180:
Figura 2.180. Nodos adicionales a introducir. Elaborada por el realizador del documento.
8. Ahora se selecciona al Nodo PC1 y se elige al primer símbolo de los que aparecen a
su alrededor (Association -> Node):
Figura 2.181. Selección de opción a introducir. Elaborada por el realizador del documento.
9. Y sin soltar el botón del ratón se asocia con el nodo SWITCH de la siguiente manera.
Vea la figura 2.182:
Página 153
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Figura 2.182. Colocación del Nodos seleccionado. Elaborada por el realizador del documento.
10. Se repite el paso anterior para asociar todos los nodos al nodo SWITCH como se
ilustra en la figura 2.183:
Figura 2.183. Asociaciones entre Nodos. Elaborada por el realizador del documento.
4.8.3. Ejercicios de Repaso
Cree un diagrama de Distribución que muestre una arquitectura software de tres
capas para un sistema de control de boletos de autobús, modelo cliente-servidor.
NOTA: Ver ejemplos del ejercicio en el anexo B, sección H.
Página 154
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
CAPITULO V. EL FUTURO DEL UML
Este último capítulo es una visión a futuro que se tendrá de este lenguaje,
el cual se ha convertido en un estándar de facto dentro de la Ingeniería del
Software.
5.1. Perspectiva a futuro del lenguaje
A pesar de que UML es un lenguaje preciso que utiliza las mejores técnicas, se
le puede realizar una extensión, además de mejoras en los conceptos de
modelamiento, y muchas técnicas avanzadas pueden ser definidas usando UML
como base.
Se espera que UML sea la base para muchas herramientas, incluyendo el
modelamiento visual, simulación y desarrollo de ambientes. En la medida que
integraciones de herramienta interesantes se desarrollen, normas de
implementación basadas en UML se tendrán disponibles40.
UML ha integrado muchas ideas dispares, de manera que dicha integración
acelerará el uso de OO.
Hay dos aspectos de “unificado” que UML logra: elimina efectivamente muchas
de las diferencias entre los lenguajes de modelamiento y métodos previos y
unifica las perspectivas entre muchas diferentes clases de sistemas, fases de
desarrollo y conceptos internos.
Muchos metodologistas, organizaciones y vendedores usan el Lenguaje de
Modelamiento Unificado como su estándar en el desarrollo de procesos y
productos y animan a otros adoptar UML.
Cada vez más usuarios adoptan UML debido a sus características similares en
cuanto a semántica y anotación a los métodos Booch, OMT, OOSE, entre otros,
la contribución de UML Partners, la incorporación de la información de la
comunidad general, así como la realización de artículos, cursos de enseñanza,
ejemplos y libros.
40
www.magma.com.ni/~jorge/upoli_uml/.../Resumen_de_UML.doc
Página 155
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
No obstante, la medida real del éxito de UML es su uso en proyectos exitosos y
el incremento en la demanda de herramientas de apoyo, libros, aprendizaje,
etc41.
5.2. Actividades de unidad por realizar
Realizar una síntesis de los capítulos 1, 2, 3 y 5 de esta obra.
Conclusión
41
Ídem.
Página 156
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
La culminación de este proyecto indica que para ciertos temas dentro del campo
de Ingeniería de Desarrollo de Software es necesario, para todas aquellas personas que
se están adentrando a este campo, sean estudiantes o intermedios, tener una
enseñanza adecuada, misma que les apoye y motive a realizar su trabajo más
profesionalmente y tener más creatividad e invención a la hora de desarrollar software
de calidad. Es por esto que el realizador de este documento se esforzó por hacer un
manual sencillo, amigable, y de forma visual, que permita responder dudas y llevar a la
práctica a toda aquella persona que se interese por este documento.
El ámbito de la enseñanza en específico, en este caso, para conocer más acerca
del Lenguaje de Modelado Unificado, y como saber utilizar de manera rápida y
profesional una herramienta OOCASE (como Visual Paradigm 6.5), es esencial en el
campo del Análisis y Diseño de Software. Se creó este documento como resultado de
experiencias dando clases especificas de Informática, y viendo la necesidad, muy
arraigada, de poder crear una herramienta que apoyase a la gente que necesita
practicar y saber como utilizar los diferentes diagramas del UML, así como también que
metodologías de desarrollo de software se pueden utilizar con éstos. Fue una labor de
compilación de información y experiencias vividas, sistematizarlas y conformarlas en un
manual sencillo y práctico, mismo que se volvió en algo tangible o real al realizar este
documento.
En base a la experiencia vivida en las aulas del instituto educativo superior,
cuando el realizador de este documento utilizó el presente manual para los discentes de
la asignatura Análisis y Diseño con Lenguaje de Modelado Unificado, de octavo
semestre de la carrera de Licenciatura en Informática, dentro del Instituto Tecnológico
Superior de la Región Sierra, estos discentes pudieron aprender de manera significativa
a desarrollar productos software por medio del uso de una herramienta automatizada
para el análisis y diseño de sistemas informáticos que manipule los diferentes diagramas
del UML. Con lo que se puede concluir que se cubrió el objetivo de la realización de este
manual,
Página 157
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Referencia Bibliográfica

Schmuller, Joseph. Aprendiendo Lenguaje de Modelado Unificado en 24
horas. 1ra. Edición, Edit. Prentice Hall. México, DF. 2001. 221 p.

Rumbaugh, James; et al. El Lenguaje Unificado de Modelado, manual de
referencia, 1ra. Edición, Edit. Prentice Hall. México, DF. 2000. 16-25 pp.
Referencia Electrónica

Enciclopedia en línea Wikipedia. Lenguaje de Modelado Unificado.
Disponible
en:
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado.
Recuperado el 02 de mayo de 2010.

(13 de junio 2010) UML, orientado a Objetos. Disponible en:
http://techfico.blogspot.com/2010/06/uml-orientacion-de-objetos.html.
Recuperado el 11 de julio de 2010.

Historia
de
UML.
Disponible
en:
http://alvearjofre.galeon.com/.
Recuperado el 10 de mayo de 2010.

UML
(Unified
Modeling
Language).
Disponible
en:
http://www.ctv.es/USERS/belmont/historia.htm. Recuperado el 12 de
junio del 2010.

Linares Pagán, Diego (octubre 2003). Introducción a UML. Disponible en:
http://repositorio.bib.upct.es/dspace/bitstream/10317/190/1/pfc1128.pdf.
Recuperado el 12 de junio del 2010.

La concepción del UML y Diagramas del UML. Disponible en:
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r69318.DOC
X. Recuperado el 03 de julio del 2010.

Hinojosa Castillo, Laura M.; Ramírez Gil, Ma. Del Pilar (22 de marzo del
2006).
Ingeniería
del
software.
Disponible
en:
Página 158
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
http://www.monografias.com/trabajos34/ingenieria-software/ingenieriasoftware.shtml. Recuperado el 03 de julio del 2010.

Enciclopedia en línea Wikipedia. Diagrama de clases. Disponible en:
http://es.wikipedia.org/wiki/Diagrama_de_clases. Recuperado el 03 de
julio del 2010.

Enciclopedia en línea Wikipedia. Programación orientada a objetos.
Disponible
en:
http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos.
Recuperado el 03 de junio del 2010.

Hitschfeld Kahler, Nancy. Unified Modeling Language UML (Tutorial),
Modelos
de
clases.
Disponible
en:
http://www.dcc.uchile.cl/~psalinas/uml/modelo.html. Recuperado el 03 de
junio del 2010.

Moreno Martínez, Gerardo. Ingeniería de Software UML. Disponible en:
http://www.monografias.com/trabajos5/insof/insof.shtml. Recuperado el
03 de junio del 2010.

Pérez Cuvit, Alejandro. Lenguaje UML, La importancia de modelar.
Disponible
en:
http://www.monografias.com/trabajos82/lenguaje-uml-
importancia-modelar/lenguaje-uml-importancia-modelar.shtml.
recuperado el 03 de junio del 2010.

Zamudio,
Lenis,
et.
al.
Disponible
en:
http://www.oocities.org/es/avrrinf/tabd/Foro/Foro_UML.htm. Recuperado
el 03 de junio del 2010.

Enciclopedia
en
línea
Wikipedia.
Software.
Disponible
en:
http://es.wikipedia.org/wiki/Software. Recuperado el 03 de junio del 2010.

Enciclopedia en línea Wikipedia. Desarrollo en espiral. Disponible en:
http://es.wikipedia.org/wiki/Desarrollo_en_espiral. Recuperado el 03 de
junio del 2010.
Página 159
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML

Enciclopedia en línea Wikipedia.
Disponible
en:
Proceso Unificado de Rational.
http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational.
Recuperado el 03 de junio del 2010.

Domínguez, José Alberto (9 de Mayo de 2012). UML: Lenguaje Unificado
de
Modelado.
Disponible
en:
http://www.que-
informatica.com/index.php/software/uml-lenguaje-unificado-demodelado/. Recuperado el 03 de junio del 2010.

Gestión de Sistemas (19 de mayo del 2009). Disponible en.
http://mdjesus.wordpress.com/2010/05/19/84/. Recuperado el 03 de junio
del 2010.
Página 160
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Anexos
A. Diagramas de los ejercicios prácticos de capítulos
Sección A. Diagrama de Casos de Uso Modelado de Negocios
Página 161
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección B. Diagrama de Casos de Uso Nivel Sistema
Página 162
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
B. Respuestas a ejercicios o prácticas de los capítulos
Sección A. Diagramas ejemplo de casos de uso
1. Cree un diagrama de casos de uso nivel modelado de negocios para mostrar
los roles y responsabilidades de una estación de autobuses dentro del contexto
de venta de boletos:
Página 163
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
2. Cree otro DCU nivel modelado de negocios para mostrar los roles y
responsabilidades de una repostería dentro del contexto de venta de piezas de
pan:
Página 164
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
3. Cree otro DCU nivel diseño de sistema para mostrar los roles y
responsabilidades de un formulario de control de autobuses dentro del contexto
de venta de boletos:
4. Cree otro DCU nivel diseño de sistema para mostrar los roles y
responsabilidades de un formulario de un catálogo de postres (consulta de
postres):
Página 165
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección B. Diagramas de Actividades de ejemplo
1. Cree un Diagrama de Actividades para mostrar los pasos a realizar del caso
de uso Vender Boleto de Autobús:
2. Cree un Diagrama de Actividades para mostrar los pasos a realizar del caso
de uso Vender pan:
Página 166
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección C. Diagrama de Secuencias
1. Cree un Diagrama de Secuencias para mostrar los pasos a realizar para dar
de alta aun autobús dentro de un formulario de control de autobuses:
Página 167
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
2. Cree un Diagrama de Secuencias para mostrar los pasos a realizar para
modificar los datos de un postre dentro de un formulario de control de postres:
Página 168
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección D. Diagrama de Clases
1. Cree un Diagrama de Clases que muestre el modelo relacional de una
base de datos para el control de préstamos dentro de una biblioteca.
Página 169
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
2. Cree un Diagrama de Clases que muestre el modelo relacional de una base
de datos para el control de ventas dentro de una refaccionaría.
Página 170
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección E. Diagrama de Estados
1. Crear un diagrama que muestre los estados de un libro, desde que se compra
a un proveedor hasta que se presta a un derechohabiente dentro de una
biblioteca:
2. Crear un diagrama que muestre los estados de un paquete, desde que se
recepciona hasta que se entrega a su dueño, dentro de un servicio de
paquetería.
Sección F. Diagrama de Colaboración
Página 171
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
1. Cree un Diagrama de Colaboración para mostrar los pasos a realizar para dar
de alta aun autobús dentro de un formulario de control de autobuses.
2. Cree un Diagrama de Colaboración para mostrar los pasos a realizar para
modificar los datos de un postre dentro de un formulario de control de postres.
Página 172
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección G. Diagrama de Componentes
1. Cree un diagrama de componentes que muestre una arquitectura software de
tres capas para un sistema de control de boletos de autobús, modelo clienteservidor.
Página 173
Manual básico de UML; apoyo para la Asign. Análisis y Diseño con UML
Sección H. Diagrama de Distribución
Cree un diagrama de Distribución que muestre una arquitectura software de tres
capas para un sistema de control de boletos de autobús, modelo cliente-servidor.
Página 174