Casos de usos.

Introduccin
El diagrama de casos de uso representa la forma en cmo un Cliente
(Actor) opera con el sistema en desarrollo, adems de la forma, tipo y
orden en como los elementos interactan (operaciones o casos de
uso).
Un diagrama de casos de uso consta de los siguientes elementos:

Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega

con respecto al sistema. Es importante destacar el uso de la
palabra rol, pues con esto se especifica que un Actor no
necesariamente representa a una persona en particular, sino ms bien
la labor que realiza frente al sistema.
Como ejemplo a la definicin anterior, tenemos el caso de un sistema
de ventas en que el rol de Vendedor con respecto al sistema puede
ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden

de algn agente externo, sea desde una peticin de un actor o
bien desde la invocacin desde otro caso de uso.

Relaciones:
o

Asociacin

Es el tipo de relacin ms bsica que indica la invocacin

desde un actor o caso de uso a otra operacin (caso de
uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la
cual una clase depende de otra, es decir, se instancia (se
crea). Dicha relacin se denota con una flecha punteada.

Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple
una doble funcin dependiendo de su estereotipo, que
puede
ser
de Uso (<<uses>>)
o
de
Herencia (<<extends>>).
Este tipo de relacin est orientado exclusivamente para
casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es
similar a otro (caractersticas).
uses: Se recomienda utilizar cuando se tiene un conjunto
de caractersticas que son similares en ms de un caso de
uso y no se desea mantener copiada la descripcin de la
caracterstica.
De lo anterior cabe mencionar que tiene el mismo
paradigma en diseo y modelamiento de clases, en donde
est la duda clsica de usar o heredar.

Ejemplo:
Como ejemplo esta el caso de una Mquina Recicladora:
Sistema que controla una mquina de reciclamiento de botellas, tarros
y jabas. El sistema debe controlar y/o aceptar:

Registrar el nmero de tem es ingresados.

Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado
b. El valor de cada tem
c. Total

El usuario/cliente presiona el botn de comienzo

Existe un operador que desea saber lo siguiente:

a. Cuantos temes han sido retornados en el da.
b. Al final de cada da el operador solicita un resumen de todo
lo depositado en el da.

El operador debe adems poder cambiar:

a. Informacin asociada a temes.
b. Dar una alarma en el caso de que:
i.
ii.

Item se atora.
No hay ms papel.

Como una primera aproximacin identificamos a los actores que

interactan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador

puede cambiar la informacin de un Item o bien puede Imprimir un
informe:

Adems podemos notar que un item puede ser una Botella, un Tarro o
una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser

realizada despus de depositar algn item por un cliente o bien puede
ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:

Diagrama de Interaccin
Introduccin
El diagrama de interaccin, representa la forma en cmo un Cliente
(Actor) u Objetos (Clases) se comunican entre s en peticin a un
evento. Esto implica recorrer toda la secuencia de llamadas, de donde
se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama
Esttico de Clases o el de Casos de Uso (son diferentes).

Los componentes de un digrama de interaccin son:

Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectngulo representa una instancia de un Objeto en

particular, y la lnea punteada representa las llamadas a mtodos
del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa
la llamada de un mtodo (operacin) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a mtodos de objetos externos pueden realizarse,

tambin es posible visualizar llamadas a mtodos desde el mismo
objeto en estudio.
Ejemplo
En el presente ejemplo, tenemos el diagrama de interaccin
proveniente del siguiente modelo esttico:

Aqu se representa una aplicacin que posee una Ventana grfica, y

sta a su vez posee internamente un botn.
Entonces el diagrama de interaccin para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre

objetos) y la llamada a Paint() por el objeto Botn.

HISTORIA DE UML

Historia de UML
El lenguaje UML comenz a gestarse en octubre de 1994, cuando Rumbaugh se
uni a la compaa Rational fundada por Booch (dos reputados investigadores en
el rea de metodologa del software).
El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo
Booch y el OMT (Object Modelling Tool ). El primer borrador apareci en octubre
de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a
Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los
tres amigos. Adems, este lenguaje se abri a la colaboracin de otras empresas
para que aportaran sus ideas. Todas estas colaboraciones condujeron a la
definicin de la primera versin de UML.
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir
y documentar artefactos de un sistema de software. Se usa para entender, disear,
configurar, mantener y controlar la informacin sobre los sistemas a construir.
UML capta la informacin sobre la estructura esttica y el comportamiento
dinmico de un sistema. Un sistema se modela como una coleccin de objetos
discretos que interactan para realizar un trabajo que finalmente beneficia a un
usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de
modelado e incorporar las mejores prcticas actuales en un acercamiento
estndar.
UML no es un lenguaje de programacin. Las herramientas pueden ofrecer
generadores de cdigo de UML para una gran variedad de lenguaje de
programacin, as como construir modelos por ingeniera inversa a partir de

programas existentes.
La notacin UML se deriva y unifica las tres metodologas de anlisis y diseos
ms extendidas.
Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus
relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object Modelling Technique).
Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering)
mediante la metodologa de casos de uso (use case).
El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim
Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A
finales de 1995, Ivar Jacob son y su compaa Objectory se incorporaron a
Rational en su unificacin, aportando el mtodo OOSE.
De las tres metodologas de partida, las de Bco. 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 relacin y colaboracin.
Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo
en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y
aceptando como estndar desde el OMG, que es tambin el origen de CORBA, el
estndar lder en la industria para la programacin de objetos distribuidos.
En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar
de facto para el anlisis y el diseo orientado a objetos.
UML es el primer mtodo en publicar una meta-modelo en su propia notacin,
incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y
diseo. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de
modelado de propsito general debera ser capaz de modelarse a s mismo).
Objetivos
Durante el desarrollo del UML sus autores tuvieron en cuenta:

Proporcionar una notacin y semnticas suficientes para poder alcanzar una

gran cantidad de aspectos del modelado contemporneo de una forma directa y
econmica.
Proporcionar las semnticas suficientes para alcanzar aspectos del modelado
que son de esperar en un futuro, como por ejemplo aspectos relacionados con la
tecnologa de componentes, el cmputo distribuido, etc.
Proporcionar mecanismos de extensin de forma que proyectos concretos
puedan extender el meta-modelo a un coste bajo.
Proporcionar mecanismos de extensin de forma que aproximaciones de
modelado futuras podran desarrollarse encima del UML.
Permitir el intercambio de los modelos entre una gran variedad de herramientas.
Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas
para la comparacin y el almacenamiento de componentes del modelo.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda
la gama de sistemas que se necesita construir.
UML es un lenguaje de modelado de propsito general que pueden usar todos los
modeladores.
UML no pretende ser un mtodo de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propsito general.
Imponer un estndar mundial.
Mediante el fomento del uso de UML 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 extensin y especializacin.
Ser independiente del proceso de desarrollo y de los lenguajes de
programacin.

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
colaboraciones, frameworks, patterns, y componentes.

como

pueden

ser

Integrar las mejores prcticas utilizadas hasta el momento.

El UML debe entenderse como un estndar para modelado y no como un estndar
de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso,
la experiencia ha mostrado que organizaciones diferentes y dominios del problema
diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en
una meta-modelo comn (que unifica las semnticas) y una notacin comn que
proporcione una representacin de esas semnticas. De todas formas, los autores
de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura,
iterativo e incremental. Bajo estas lneas genricas proponen el proceso software
definido en una de las extensiones del UML (Objectory Extension for Software
Enginnering) , pero en general el proceso software es fuertemente dependiente de
la organizacin y del dominio de aplicacin.
Los conceptos y modelos de UML pueden agruparse en las siguientes reas
conceptuales:
Estructura esttica:
Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos
clave de la aplicacin, sus propiedades internas, y las relaciones entre cada una de
ellas. Este conjunto de construcciones es la estructura esttica. Los conceptos de
la aplicacin son modelados como clases, cada una de las cuales describe un
conjunto de objetos que almacenan informacin y se comunican para implementar
un comportamiento. La informacin que almacena es modelada como atributos; La
estructura esttica se expresa con diagramas de clases y puede usarse para
generar la mayora de las declaraciones de estructuras de datos en un programa.
Comportamiento dinmico:
Hay dos formas de modelar el comportamiento, una es la historia de la vida de un
objeto y la forma como interacta con el resto del mundo y la otra es por los
patrones de comunicacin de un conjunto de objetos conectados, es decir la forma
en que interactan entre s. La visin de un objeto aislado es una mquina de

estados, muestra la forma en que el objeto responde a los eventos en funcin de

su estado actual. La visin de la interaccin de los objetos se representa con los
enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este
punto de vista unifica la estructura de los datos, el control de flujo y el flujo de
datos.
Construcciones de implementacin:
Los modelos UML tienen significado para el anlisis lgico y para la
implementacin fsica. Un componente es una parte fsica reemplazable de un
sistema y es capaz de responder a las peticiones descritas por un conjunto de
interfaces. Un nodo es un recurso computacional que define una localizacin
durante la ejecucin de un sistema. Puede contener componentes y objetos.
Mecanismos de extensin:
UML tiene una limitada capacidad de extensin pero que es suficiente para la
mayora de las extensiones que requiere el da a da sin la necesidad de un cambio
en el lenguaje bsico. Un estereotipo es una nueva clase de elemento de
modelado con la misma estructura que un elemento existente pero con
restricciones adicionales.
Organizacin del modelo:
La informacin del modelo debe ser dividida en piezas coherentes, para que los
equipos puedan trabajar en las diferentes partes de forma concurrente. El
conocimiento humano requiere que se organice el contenido del modelo en
paquetes de tamao modesto. Los paquetes son unidades organizativas,
jerrquicas y de propsito general de los modelos de UML. Pueden usarse para
almacenamiento, control de acceso, gestin de la configuracin y construccin de
bibliotecas que contengan fragmentos de cdigo reutilizable.
Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML. Son
comentarios que se pueden aplicar para describir, clasificar y hacer observaciones
sobre cualquier elemento de un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para
mostrar restricciones y comentarios junto a un elemento o un conjunto de

elementos
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML.
Dependencia, asociacin, generalizacin y realizacin, estas se describen a
continuacin
Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento
(el elemento independiente) puede afectar a la semntica del otro elemento
(elemento dependiente). Se representa como una lnea discontinua, posiblemente
dirigida, que a veces incluye una etiqueta.
Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregacin es un tipo especial de asociacin y
representa una relacin estructural entre un todo y sus partes. La asociacin se
representa con una lnea continua, posiblemente dirigida, que a veces incluye una
etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles
de los objetos involucrados.
Generalizacin
Es una relacin de especializacin / generalizacin 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. Grficamente, la generalizacin se representa con una lnea con punta de
flecha vaca.
Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica un
contrato que otro clasificador garantiza que cumplir. Se pueden encontrar
relaciones de realizacin en dos sitios: entre interfaces y las clases y componentes
que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La
realizacin se representa como una mezcla entre la generalizacin y la
dependencia, esto es, una lnea discontinua con una punta de flecha vaca.

Diagramas
Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema
de forma que un diagrama es una proyeccin del mismo. UML proporciona un
amplio conjunto de diagramas que normalmente se usan en pequeos
subconjuntos para poder representar las cinco vistas principales de la arquitectura
de un sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as como sus
relaciones. Estos diagramas son los ms comunes en el modelado de sistemas
orientados a objetos y cubren la vista de diseo esttica o la vista de procesos
esttica (s incluyen clases activas).
Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de
los diagramas de clases y cubren la vista de diseo esttica o la vista de procesos
esttica desde la perspectiva de casos reales o prototpicos.
Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus
relaciones. Cubren la vista esttica de los casos de uso y son especialmente
importantes para el modelado y organizacin del comportamiento.
Diagramas de Secuencia y de Colaboracin
Tanto los diagramas de secuencia como los diagramas de colaboracin son un tipo
de diagramas de interaccin. Constan de un conjunto de objetos y sus relaciones,
incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la
vista dinmica del sistema. Los diagramas de secuencia enfatizan el ordenamiento
temporal de los mensajes mientras que los diagramas de colaboracin muestran la
organizacin estructural de los objetos que envan y reciben mensajes. Los
diagramas de secuencia se pueden convertir en diagramas de colaboracin sin
prdida de informacin, lo mismo ocurren en sentido opuesto.

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y
actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy
importantes a la hora de modelar el comportamiento de una interfaz, clase o
colaboracin.
Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de
actividades dentro de un sistema. Los diagramas de actividades cubren la parte
dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema
resaltando el flujo de control entre objetos.
Diagramas de Componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes.
Cubren la vista de la implementacin esttica y se relacionan con los diagramas de
clases ya que en un componente suele tener una o ms clases, interfaces o
colaboraciones
Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de
ejecucin y los componentes que residen en ellos. Muestran la vista de despliegue
esttica de una arquitectura y se relacionan con los componentes ya que, por lo
comn, los nodos contienen uno o ms componentes.

UML (Unified Modeling Language)

El Lenguaje Unificado de Modelado (UML) es una tcnica para la
especificacin de sistemas en todas sus fases. Este ha sido desarrollado
por los ms importantes autores en materia de Anlisis y Diseo de
Sistemas y ha sido usada con xito en sistemas hechos para toda clase de
industrias alrededor del mundo: Salud, Bancos, Comunicaciones,
Aeronutica, Finanzas, etc.
Sin lugar a dudas OOAD (Object Oriented Analysis and Design),
implementado con UML (Unified Modeling Language), es la metodologa
ms avanzada en la actualidad. Esta metodologa introduce los Casos de
Uso, una poderosa herramienta para reducir los riesgos en la definicin de
requerimientos de sistemas nuevos. Los Casos de Uso sirven como
columna vertebral del proceso de desarrollo de aplicaciones y tienen como
objetivo garantizar que los resultados se ajusten completamente a las
expectativas de los usuarios finales.
El Lenguaje Unificado de Modelado (UML). Analiza los diagramas que
componen UML y ofrece acercamientos a casos de uso guiados sobre cmo
estos diagramas se usan para modelar sistemas. Tambin trata los
mecanismos de extensibilidad de UML, los cuales permiten ampliar su
notacin y su semntica.
UML: Es un lenguaje grfico para visualizar, especificar, construir y
documentar un sistema de software. UML ofrece 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.
El punto importante para notar aqu es que UML es un "lenguaje" para
especificar y no un mtodo o un proceso. UML se usa para definir un
sistema de software; para detallar los artefactos en el sistema; para
documentar y construir -es el lenguaje en el que est descrito el modelo.
UML se puede usar en una gran variedad de formas para soportar una
metodologa de desarrollo de software (tal como el Proceso Unificado
de Rational) -pero no especifica en s mismo qu metodologa o proceso
usar.

PARA QU SIRVE UML?

UML sirve para hacer modelos que permitan:
Visualizar como es un sistema o como queremos que sea.
Especificar la estructura y/o comportamiento de un sistema.
Hacer una plantilla que gue la construccin de los sistemas
Documentar las decisiones que hemos tomado.
El modelado sirve no solamente para los grandes sistemas; an en
aplicaciones de pequeo tamao se obtienen beneficios de modelar, sin
embargo, es un hecho que entre ms grande y ms complejo es el sistema,
el modelado juega un papel ms importante. Esto se debe a una razn
simple: Hacemos modelos de sistemas complejos porque no podemos
entenderlos en su totalidad
Hay lmites para el entendimiento de la complejidad. A travs del modelado
reducimos el mbito del problema de estudio al enfocar solo un aspecto a la
vez.
UML puede ser usado extensivamente en: Recopilacin de requerimientos,
Anlisis de aplicaciones, Diseo de sistemas, en pruebas, en
implementacin, en reingeniera y prcticamente en cualquier actividad de
desarrollo que sea susceptible de ser modelada.
Cabe aclarar que aunque UML es orientado a objetos preferentemente, es
til en cualquier modelo tecnolgico ya que es independiente de lenguajes
de programacin o tecnologa determinada.
PORQUE ES IMPORTANTE UML?
Esta consolidado como el lenguaje estndar en el anlisis y diseo de
sistemas de computo. Mediante UML es posible establecer la serie de
requerimientos y estructuras necesarias para plasmar un sistema de
software previo al proceso intensivo de escribir cdigo.
En otros trminos, as como en la construccin de un edificio se realizan
planos previo a su construccin, en Software se deben realizar diseos en
UML previa codificacin de un sistema, ahora bien, aunque UML es un
lenguaje, ste posee ms caractersticas visuales que programticas,
mismas que facilitan a integrantes de un equipo multidisciplinario participar
e intercomunicarse fcilmente, estos integrantes siendo los analistas,
diseadores, especialistas de rea y desde luego los programadores.

BENEFICIOS DE ESTA TECNOLOGA.

Los beneficios son claros al ocupar este lenguaje de modelamiento:
Mejores tiempos totales de desarrollo (de 50% o ms). En la mayora de
organizaciones hoy en da el tiempo que pasa desde que un proyecto
arranca hasta que se estabiliza es ms del doble de lo planeado
originalmente. Con el uso de UML las fases de anlisis y diseo consumirn
mayor tiempo, pero el tiempo de construccin, implantacin y estabilizacin
se reducen drsticamente debido a que no hay correcciones mayores en las
fases de mayor impacto de un proyecto.
Mejor calidad. El uso de UML hace indispensable la participacin del
usuario en la definicin de requerimientos y por lo tanto mejora
considerablemente el apego del sistema a las necesidades de sus usuarios.
El mantenimiento correctivo se reduce drsticamente (hasta un 80% con
respecto a un sistema hecho sin metodologa). Algo similar ocurre en los
proyectos de reingeniera.
Mejor soporte a la planeacin y al control de proyectos. Al existir
entregables definidos y estandarizados en las distintas fases de un proyecto
y al ser stos revisables y certificables por gente distinta del autor, tenemos
que los planes de trabajo pueden ser fcilmente creados y corroborados en
avance. Lo que permite tomar decisiones a tiempo.
Mayor independencia del personal de desarrollo. Al tener documentadas
las aplicaciones en un lenguaje estndar, podemos mover al personal de
una aplicacin a otra sin correr altos riesgos y sin depender del
conocimiento personal de las aplicaciones.
Mayor soporte al cambio organizacional, comercial y tecnolgico. Un
modelo permite cuantificar el impacto de un cambio antes de hacerlo y
permite ensayar distintos enfoques de solucin. Con UML un cambio se
puede hacer primero en papel.
Alto reuso. Los productos de un desarrollo pueden ser usados en otro. Se
pueden crear componentes reusables que con la difusin y administracin
adecuadas minimizarn costos y errores.
Minimizacin de costos. Los puntos antes mencionados tienen un impacto
econmico que generalmente tiende a ser proporcional al tamao de la
organizacin.

SERVICIOS NECESARIOS PARA IMPLANTAR ESTA TECNOLOGA.

Aunque vara un poco de organizacin a organizacin los servicios de
apoyo necesarios para la implantacin de esta tecnologa, podemos
mencionar los siguientes:
Consultora para la Planeacin. Cuando las reas involucradas son
muchas, el impacto de la introduccin de esta tecnologa requerir una
planeacin adecuada, este proceso debe ser hecho por la organizacin y
apoyado por un equipo con experiencia en la administracin de este
cambio.
Capacitacin. Las tcnicas involucradas pueden ser aprendidas
directamente de los libros y manuales de UML, sin embargo el tiempo
necesario puede ser prohibitivo. Un servicio de capacitacin de alta calidad
generar la cultura bsica para el ptimo aprovechamiento de la tecnologa.
Capacitacin en UML, Anlisis y Diseo de aplicaciones es sugerida.
Mentoring. El desarrollo de proyectos pilotos de Desarrollo, Documentacin
o Reingeniera deben ser apoyados por uno o ms expertos en el uso de
UML que aseguren que el equipo adquiere el conocimiento prctico del uso
de UML y agilicen su uso.
Control de Calidad. Una vez que un equipo ya ha aprendido el uso de UML
es sano contar con un staff de control de calidad externo (y experto) que
certifique la calidad de los productos y genere gente con ste perfil hacia el
interior de la organizacin. Este servicio tambin puede ser til para
controlar la calidad de los desarrollos efectuados por empresas externas
ELEMENTOS DE UML
Diagrama de casos de uso
Los diagramas de casos de uso describen las relaciones y las dependencias
entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no estn
pensados para representar el diseo y no puede describir los elementos
internos de un sistema. Los diagramas de casos de uso sirven para facilitar
la comunicacin con los futuros usuarios del sistema, y con el cliente, y
resultan especialmente tiles para determinar las caractersticas necesarias
que tendr el sistema. En otras palabras, los diagramas de casos de uso
describen qu es lo que debe hacer el sistema, pero no cmo.

Diagrama de clases
Los diagramas de clases muestran las diferentes clases que componen un
sistema y cmo se relacionan unas con otras. Se dice que los diagramas de
clases son diagramas estticos porque muestran las clases, junto con sus
mtodos y atributos, as como las relaciones estticas entre ellas: qu
clases conocen a qu otras clases o qu clases son parte de otras
clases, pero no muestran los mtodos mediante los que se invocan entre
ellas.
Diagramas de secuencia
Los diagramas de secuencia muestran el intercambio de mensajes (es decir
la forma en que se invocan) en un momento dado. Los diagramas de
secuencia ponen especial nfasis en el orden y el momento en que se
envan los mensajes a los objetos.
En los diagramas de secuencia, los objetos estn representados por lneas
intermitentes verticales, con el nombre del objeto en la parte ms alta. El eje
de tiempo tambin es vertical, incrementndose hacia abajo, de forma que
los mensajes son enviados de un objeto a otro en forma de flechas con los
nombres de la operacin y los parmetros.
Diagramas de colaboracin
Los diagramas de colaboracin muestran las interacciones que ocurren
entre los objetos que participan en una situacin determinada. Esta es ms
o menos la misma informacin que la mostrada por los diagramas de
secuencia, pero destacando la forma en que las operaciones se producen
en el tiempo, mientras que los diagramas de colaboracin fijan el inters en
las relaciones entre los objetos y su topologa.
En los diagramas de colaboracin los mensajes enviados de un objeto a
otro se representan mediante flechas, mostrando el nombre del mensaje,
los parmetros y la secuencia del mensaje. Los diagramas de colaboracin
estn indicados para mostrar una situacin o flujo programa especficos y
son unos de los mejores tipos de diagramas para demostrar o explicar
rpidamente un proceso dentro de la lgica del programa.

Diagrama de estado
Los diagramas de estado muestran los diferentes estados de un objeto
durante su vida, y los estmulos que provocan los cambios de estado en un
objeto.
Los diagramas de estado ven a los objetos como mquinas de estado o
autmatas finitos que pueden estar en un conjunto de estados finitos y que
pueden cambiar su estado a travs de un estmulo perteneciente a un
conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener
durante su vida uno de los siguientes estados:

Listo
Escuchando
Trabajando
Detenido

Y los eventos que pueden producir que el objeto cambie de estado son

Se crea el objeto
El objeto recibe un mensaje de escucha
Un cliente solicita una conexin a travs de la red
Un cliente finaliza una solicitud
La solicitud se ejecuta y ser termina
El objeto recibe un mensaje de detencin
Etc.

Diagrama de actividad
Los diagramas de actividad describen la secuencia de las actividades en un
sistema. Los diagramas de actividad son una forma especial de los
diagramas de estado, que nicamente (o mayormente) contienen
actividades.

Preguntas
1. Qu es UML?
2. Por qu es importante UML?
3. Complejidad de Objetos?
4. Elementos de UML?
5. Qu son Diagramas de Componentes?
6. Beneficios de usar UML

7. Para qu sirve UML?

8. Qu servicios son necesarios para implantar esta tecnologa?
9. Qu son los Diagramas de Actividad?
10. Qu son los Casos de Uso?

UML - CASOS DE USOS Y DIAGRAMAS DE CASOS DE USO.

Es un lenguaje estndar para:
Visualizar.
Especificar
Construir
Documentar los planos del Software.
Indican cmo crear modelos bien formados pero no nos dicen que modelos
se deben crear ni cuando se los deberan crear.
UML Es un lenguaje para Visualizar.
La distancia entre pensar en una implementacin y transformarla en
cdigo es casi cero.
En algunos casos: Lo que piensas lo codificas.
Algunas cosas se modelan mejor textualmente; otras se modelan
mejor de forma grfica.
UML Es algo ms que un simple montn de smbolos grficos.
UML Es un lenguaje para Especificar.
Significa construir modelos precisos, no ambiguos y completos.
UML Cubre todas la decisiones de Anlisis, Diseos e
implementacin.
UML Es un lenguaje para Construir
No es un lenguaje de programacin.
Peros sus modelos pueden conectarse a una gran variedad de
lenguajes de programacin.
UML Es un lenguaje para Documentar.
UML Cubre la documentacin de la arquitectura de un sistema y
todos sus detalles.
Proporciona un lenguaje.

 Expresar requisitos y pruebas.

Modelar actividades de planificacin de proyectos y gestin de
versiones.

CASOS DE USO.

Qu es un caso de uso?
Para qu sirve un caso de uso?.
Cmo se representan?
Cmo se debe crear un caso de uso?
Flujo de Eventos
Relaciones.
Diagramas de caso de Uso.

Qu es un caso de uso?
Describe una interaccin tpica entre un usuario (actores) y un
sistema de cmputo.
Es una tcnica para capturar informacin de cmo un sistema o
negocio trabaja actualmente, o de cmo se desea que trabaje.
Produce algo de valor para algn actor como el clculo de algn
resultado.
Para qu sirve un caso de uso?
Para capturar el comportamiento deseado del sistema sin tener que
especificar cmo se implementa ese comportamiento.
Como medio de compresin del sistema para desarrolladores,
Usuarios finales y expertos del dominio.
Ayuda a validar la arquitectura y verificar el sistema en el transcurso
del desarrollo de ste.
Como se Representan?
Un caso de uso se representa en UML como un ovalo:

Nombre del Caso de Uso

En UML, un Actor se representa como un monigote.

Actor
ACTORES
Representa un conjunto de roles que los usuarios de los casos de uso
juegan al interactuar con stos.
Representa un Rol que es jugado por un persona, un dispositivo
hardware u otros sistemas que interacte con nuestro sistema.
Se puede definir categoras generales de actores (como cliente) y
especializarlos (como Cliente Comercial) a travs de relaciones de
generalizacin.

Un actor y un caso de uso se pueden comunicar a travs de

una asociacin donde cada uno de ellos pueden enviar y
recibir mensajes.

Flujo de Eventos.
Cmo y Cundo Empieza y Acaba el Caso de Uso.
Cundo interactan
intercambian.

con

los

actores

y que

Objetos

se

Conviene separar el flujo principal de una alternativa.

Bibliografa:
http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html
Autores: Diana Palliotto; Gabriel Romano Universidad Nacional
de Santiago del Estero Facultad de Ciencias Exactas y
Tecnologas Direccin: Departamento de Informtica - Av.
Belgrano (S) 1912, (4200) Santiago del Estero, Argentina.- EMail:
UML
Tools
By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

Los beneficios del Modelador Bizagi

http://www.docirs.cl/uml.htm
http://www.oocities.org/es/avrrinf/tabd/Foro/Foro_UML.htm

https://sites.google.com/site/disenodesistemasiads/home/ben
eficios-uml
http://alvearjofre.galeon.com/
http://www.usmp.edu.pe/publicaciones/boletin/fia/info21/uml.h
tm