Está en la página 1de 11

3.

Funciones y aspectos del Lenguaje de Modelado Unificado




El Lenguaje de Modelado Unificado (UML: Unified Modeling Language) es
la sucesin de una serie de mtodos de anlisis y diseo orientadas a
objetos que aparecen a fines de los 80's y principios de los 90s. UML es
llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten
de ambos, de un lenguaje de modelado y de un proceso.
El lenguaje de modelado es la notacin (principalmente grfica) que usan
los mtodos para expresar un diseo. El proceso indica los pasos que se
deben seguir para llegar a un diseo. (Gnzales, 2008)

Las funciones del UML: visualizar, especificar, construir y documentar los
artefactos de modelamiento del negocio, de los sistemas software y no software,
ofrecen un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocios y funciones del sistema,
y aspectos concretos como expresiones de lenguajes de programacin, esquemas
de bases de datos y componentes de software reutilizables.

UML tiene una notacin grfica muy precisa que reconoce la representacin en
menor o mayor grado de las fases de un proyecto informtico: desde el anlisis
con los casos de uso, el diseo con los diagramas de clases, objetos, entre otros,
hasta la implementacin y configuracin con los diagramas de despliegue; UML es
un lenguaje de modelamiento visual y especificacin y habilitacin de procesos.

UML no es un proceso, UML no es un lenguaje de programacin visual, ni una
herramienta o instrumento de especificacin.

Cundo usar UML?

UML es muy til cuando se requiere documentar un proyecto sin afectar su
tamao. Es recomendable evidenciarlo, debido a que las personas que se
encuentran actualmente en el desarrollo, podran abandonar la empresa por
alguna razn.



Cuando se trabaja en equipo, se requiere del UML para una correcta
estructuracin de los requerimientos del sistema. Una prctica comn en algunos
programadores, es no documentar los proyectos que desarrollan. Esto trae
consigo problemas posteriores cuando alguna otra persona toma el proyecto y
realiza ajustes. No cuenta con la documentacin requerida para comprender el
cmo funciona el sistema.

Se recomienda usar casos de uso en todos los proyectos por su gran ayuda en la
planeacin, exposicin y determinacin de requerimientos. Conforme avanza el
desarrollo de un proyecto, los casos de uso se hacen ms visibles y tiles.

Por qu usar UML?

Mientras que el valor estratgico del software aumenta para muchas compaas,
la industria busca tcnicas para automatizar la produccin del mismo, mejorar su
calidad, reducir costos y tiempo. Estas tcnicas incluyen tecnologa, programacin
visual, patrones, entre otros.

Los negocios tambin intentan tcnicas para manejar la complejidad de sistemas
mientras que aumentan el alcance y complejidad, reconociendo problemas
arquitectnicos que se repiten, tales como distribucin fsica, concurrencia, rplica,
seguridad, balance de la carga y tolerancia de fallas. Adems, el desarrollo para la
web a nivel mundial, mientras que hace algunas cosas ms simples, ha agravado
estos problemas arquitectnicos. UML fue diseado para responder a estas
necesidades.

Diagramas de caso de uso

UML proporciona notacin para los diagramas de casos de uso con el fin de
ilustrar sus nombres, actores y las relaciones entre ellos.
El diagrama tambin puede ser utilizado para que los expertos de dominio
(usuarios del sistema y clientes) se comuniquen con los informticos sin llegar a
niveles de complejidad.

Se emplean para visualizar el comportamiento del sistema, una parte de l o de
una sola clase. De forma que se pueda conocer cmo responder a esa parte del
sistema. El diagrama UML de casos de uso es muy til para definir como debera
ser el comportamiento de una parte del sistema, ya que solo especifica cmo
deben comportarse y no como estn implementadas las partes que define. En el
diagrama se encuentran diferentes figuras que pueden mantener diversas
relaciones entre ellas:


Casos de uso: representado por una elipse, cada caso de uso contiene un
nombre que indica su funcionalidad. Pueden tener relaciones con otros y los
ms comunes son:

o Include: representado por una flecha, en el diagrama de ejemplo se puede
ver como un caso de uso, el de totalizar el coste incluye a dos casos de
uso. Utilizar include cuando se est repitiendo en dos o ms casos de uso
por separado y quiere evitar repeticiones.

o Extends: una relacin de un caso de uso A hacia un caso de uso B indica
que B implementa la funcionalidad de A. La idea es crear casos de uso que
se extiende o aade y con l, describe donde y bajo qu condiciones
extiende el comportamiento de algn caso de uso base.

o Generalization: es la tpica relacin de herencia. La hereda el
comportamiento y significado de otro, es decir las relaciones de
comunicacin, inclusin y extensin del sper-caso de uso.


Actores: se representan por un mueco. Sus relaciones son:

o Communicates: comunica un actor con un caso de uso.

o Parte del sistema (System boundary): representado por un cuadro,
identifica las diferentes partes del sistema y contiene los casos de uso que
la forman.



Fuente: SENA


Se debe modelar la relacin del sistema con los elementos externos, ya que son
los que forman el contexto del sistema.
Casos de uso
Actor


Los pasos a seguir son:

1. Identificar los actores que interactan con el sistema.
2. Organizar a los actores.
3. Especificar sus vas de comunicacin con el sistema.





Fuente: SENA



Para modelar los requerimientos es recomendable:

Determinar su contexto, para lo que tambin se puede usar un diagrama de
casos de uso.
Identificar las necesidades de los elementos del contexto (actores).
Definir esas necesidades y darles forma de caso de uso.
Identificar qu casos de uso pueden ser especializaciones de otros o buscar
especializaciones comunes para los casos de uso ya encontrados.




Actores

Un actor es cualquier cosa con comportamiento, inclusive el propio sistema
que se est estudiando (SuD, System Under Discussion). Los actores
principales y de apoyo aparecern en los pasos de accin del texto del
caso de uso. Los autores no son solamente roles que juegan las personas,
sino tambin organizaciones, sistemas, metas, responsabilidades, software
y mquinas. Hay tres tipos de actores externos con relacin al SuD:
Actor principal: tiene objetivos de usuarios que se satisfacen mediante el
uso de los servicios de SuD. Por ejemplo, el cajero.
Por qu se identifica? Por encontrar los objetivos de usuario, los cuales
dirigen los casos de uso.
Actor de apoyo: proporcionan un servicio (por ejemplo: informacin) al
SuD. Un ejemplo, los servicios de autorizacin de pago.
Por qu se identifica? Por aclarar las interfaces externas y los
protocolos.
Actor pasivo: est interesado en el comportamiento de casos de uso, pero
no es principal ni de apoyo; por ejemplo, la agencia tributaria del gobierno.
Por qu se identifica? Por asegurar que todos los intereses necesarios
sean identificados y satisfechos. (Universidad de El Salvador, 2007,
p.23)









Fuente: SENA



Asociaciones

Asociacin: indica que un actor forma parte de un caso de uso.

Un tipo especializado de asociacin, llamado Communication association
contesta a los interrogantes Cmo los actores y los casos de uso se relacionan?
y Qu actores inicializan o participan en los casos de uso?

Una asociacin entre un actor y un caso de uso indica que el actor se comunica
con el sistema y participa en el caso de uso.

Un caso de uso puede tener asociaciones con mltiples actores y un actor puede
tener asociaciones con mltiples casos de uso.

Una asociacin se muestra con una lnea slida entre el actor y el caso de uso.






Fuente: SENA



Una flecha de navegacin en una asociacin dirigida hacia el caso de uso,
indica que el actor inicializa la interaccin con el sistema.

Una flecha de navegacin en una asociacin con direccin hacia el actor, indica
que el sistema inicializa la interaccin con el actor.

Sea cuidadoso de no mostrar flechas de navegacin, ya que puede indicar al
modelador que no existe ningn tipo de interaccin entre el actor y el caso de
uso.


Dependencias

Un modelo puede tener varios casos de uso, entonces, Cmo organizar esos
casos de uso para definir lo que el sistema debe hacer? Cmo usar esa
informacin para determinar cmo debe ejecutarse el proyecto mientras se
considera? Cmo usar los casos de uso y relacionarlos con otros, incluyendo los
puntos en comn que puedan tener? Las dependencias llamadas include y extend,
contestan los anteriores interrogantes.



Dependencia include

Indica que un caso de uso siempre llama la funcionalidad de otro caso de uso el
cul se decidi separarlo debido a que su funcionalidad poda ser reutilizada.

Una dependencia include se muestra con una flecha desde el caso de uso hacia el
caso de uso a incluir marcado con la palabra <<include>>.







Fuente: SENA



Dependencia extend

La dependencia extend especifica un caso de uso, que puede o no llamar la
funcionalidad de otro caso de uso.






























Fuente: SENA


StarUML

StarUML es una herramienta para el modelamiento de software basado en los
estndares UML y MDA (Model Driven Arquitecture), anteriormente llamada
Plastic o gora plastic.

Es de fcil uso y ayuda a generar diagramas compatibles con la suite de ofimtica
de Microsoft Office. Tiene cdigo que es compatible con C++ y Java.


Historia de StarUML

Ao Descripcin
1996, nace de la
primera versin
(V 0.9) de Plastic.
Fue una herramienta muy simple que se utilizaba para dibujar
mdulos de software y sus dependencias.
1997,
lanzamiento de
Plastic 1.0.
Programas de dominio pblico, apoy OMT (Object Modeling
Technique -Tcnica de Modelado de Objetos).
1998, Plastic 1.1. Diagrama de clases UML apoyado.
1999, fundacin
de software de
Plastic. Inc.
Lanzamiento de Plastic 2.0 apoyo UML, generacin de cdigo
Java e ingeniera inversa.
2001, Plastic
versin 3.0.
UML 1.3 totalmente compatible.
2003, Plstic
libre.
Completamente rediseado y reescrito, UML 1.4 totalmente
compatible, de arquitectura abierta.
2005, gora
plastic libre.
Se internacionaliza, muchas caractersticas se implementan
en la plataforma extensible. Good Software" Certificado del
Ministerio de Informacin y Comunicaciones de Corea.
StarUML 5.0 cambia de nombre y se libera.
Se volvi a abrir el proyecto de cdigo, UML 2.0 compatibles,
la tecnologa y la notacin de extensin se implementan.









Referencias

Jos, G. (2008). Qu es UML? Consultado el 28 de enero de 2014, en
http://www.docirs.cl/uml.htm

Universidad de El Salvador. (2007). Definicin de Requisitos. Consultado el 28
de enero de 2014, en
http://ybathich.site90.com/documentos/Material/Metodologia/Requerimientos/Un
idad_2.pdf

Servicio Nacional de Aprendizaje, SENA. (2010). Diseo de casos de uso.
Colombia: Autor.


Control del documento


Nombre Cargo Dependencia Fecha
Autor
Patricia Isabel
Lozada
Arregocs
Contratista
Centro Agroturstico
Regional Santander
Diciembre
de 2013
Adaptacin
Ana Mara Mora
Jaramillo
Guionista -
Lnea de
produccin
Centro
Agroindustrial
Regional Quindo
Enero de
2014