Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tarea de Desa. Impl. Sist. Infor.
Tarea de Desa. Impl. Sist. Infor.
figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista
no es una grfica, pero s una abstraccin que consiste en un nmero de
diagramas y todos esos diagramas juntos muestran una "fotografa" completa del
sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos o
procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:
Vista Use-Case: Una vista que muestra la funcionalidad del sistema como
la perciben los actores externos.
Diagramas: Los diagramas son las grficas que describen el contenido de una
vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para
proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de
objetos, de estados, de secuencia, de colaboracin, de actividad, de componentes
y de distribucin.
Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas
son los elementos de modelo que representan conceptos comunes orientados a
objetos, tales como clases, objetos y mensajes, y las relaciones entre estos
conceptos incluyendo la asociacin, dependencia y generalizacin. Un elemento
de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el
mismo significado y simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras, informacin o
semntica acerca del elemento de modelo; adems proveen mecanismos de
extensin para adaptar o extender UML a un mtodo o proceso especfico,
organizacin o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Anlisis de
requerimientos, Anlisis, Diseo, Programacin y Pruebas.
Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A
travs del modelado de casos de uso, los actores externos que tienen inters en el
sistema son modelados con la funcionalidad que ellos requieren del sistema (los
casos de uso). Los actores y los casos de uso son modelados con relaciones y
tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y
casos de uso son descritos en un diagrama use-case. Cada use-case es descrito
en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del
sistema sin considerar la funcionalidad que se implementar. Un anlisis de
requerimientos puede ser realizado tambin para procesos de negocios, no
solamente para sistemas de software.
Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que estn presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
tambin se consideran en esta fase a travs de los modelos dinmicos en UML.
Es importante notar que slo se consideran clases que estn en el dominio del
problema (conceptos del mundo real) y todava no se consideran clases que
definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseo
En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica.
Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
anlisis son agregadas en esta fase. El diseo resulta en especificaciones
detalladas para la fase de programacin.
Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin integran
componentes y clases en orden para verificar que se ejecutan como se especific.
Las pruebas de sistema ven al sistema como una "caja negra" y validan que el
sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptacin conducidas por el cliente verifican que el sistema satisface los
requerimientos y son similares a las pruebas de sistema.
Tabla de Contenido
figura 4
Los elementos de un diagrama de casos de uso son:
Sistema
Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre
del sistema aparece arriba o dentro de la caja. sta tambin contiene los smbolos
para los casos de uso del sistema.
Actores
Un actor es alguien o algo que interacta con el sistema; es quien utiliza el
sistema. Por la frase "interacta con el sistema" se debe entender que el actor
enva a o recibe del sistema unos mensajes o intercambia informacin con el
sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor
puede ser una persona u otro sistema que se comunica con el sistema a modelar.
Casos de uso
Un caso de uso representa la funcionalidad completa tal y como la percibe un
actor. Un caso de uso en UML es definido como un conjunto de secuencias de
acciones que un sistema ejecuta y que permite un resultado observable de valores
para un actor en particular. Grficamente se representan con una elipse y tiene las
siguientes caractersticas:
DIAGRAMA DE SECUENCIA
Este diagrama muestra la interaccin de los objetos entre ellos. Es
importante comentar que hasta este momento no se han considerado
objetos tcnicos. En UML, durante el Anlisis de los requerimientos y
el Anlisis, no se consideran objetos tcnicos que definan detalles y
soluciones en el sistema de software, tales como objetos para interfaces de
usuario, bases de datos, comunicaciones, etc. Todos esos objetos se
consideran hasta el diseo del sistema (figura 5).
figura 5
En este diagrama se observa que slo se consideran algunos objetos y es
importante aclarar que estos no sern todos los objetos a considerar dentro
del sistema, ya que todava es posible agregar nuevos objetos que no se
haban considerado en el dominio del anlisis as como los objetos
tcnicos, como se mencion anteriormente. Los objetos considerados se
representan en rectngulos con el nombre subrayado y cada uno cuenta
con su lnea de vida vertical que muestra la vida del objeto.
DIAGRAMA DE COLABORACIN
ESTANDARIZACIN UML
El Lenguaje de Modelado Unificado (UML) es la sucesin de una serie de mtodos de anlisis y
diseos orientados a objetos que aparecen a fines de los 80's y principios de los 90s.
Directamente unifica los mtodos de Booch, Rumbaugh (OMT), y Jacobson, y algo ms.
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.
La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal de
comunicacin. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje
de modelado y no as el proceso que se sigui para obtenerlo.
Una de la metas principales de UML es avanzar en el estado de la industria proporcionando
herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr
un intercambio exitoso de modelos de informacin entre herramientas, se requiri definirle una
semntica y una notacin.
La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de
modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los
elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa
exactamente una asociacin o multiplicidad en una clase?. Un metamodelo es la manera de
definir sto (un diagrama, usualmente de clases, que define la notacin).
Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la
notacin.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo
modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin
de UML.
Software libre para modelado en UML [editar]ArgoUML, Herramienta de modelado UML escrito en
java (enlace externo)
BOUML, Ligera herramienta de modelado UML y generacin de cdigo C++, Java e IDL.
Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial)
Fujaba, No solo sirve para modelar sino que puede generar cdigo Java automticamente.
Tambin es capaz de hacer ingenieria inversa y crear los diagramas a partir del cdigo Java [1].
Dia Puede ser usado para modelar varios tipos de diagramas UML (enlace externo)
gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el navegador),
que permite generar cdigo Action Script 2.0 Compatible (enlace externo)
MonoUML Herramienta CASE para la plataforma mono (Sitio Oficial)
Papyrus, Herramienta grfica basada en Eclipse para el modelado con UML2, es de cdigo
abierto y se ofrece bajo licencia EPL (Sitio Oficial)
StarUML Herramienta de modelado para Windows desarrollada en Delphi. Bastante estable y
usable (enlace externo)
TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de diagramas
incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial)
Umbrello Herramienta para modelado UML para el entorno KDE
UMLet Herramienta para modelado rpido de UML tambin escrita en Java
Vistas de UML:
Una vista es un subconjunto de construcciones de modelado que se enfocan en un
aspecto en particular del sistema.
Las vistas pueden dividirse en tres reas :
Clasifiacin Estructural.
Comportamiento Dinmico.
Vista de Gestin.
2.3.1. Esteroetipos
Los estereotipos son el mecanismo de extensibilidad incorporado ms utilizado
dentro de UML. Un estereotipo respresenta una distincin de uso. Puede ser
aplicado a cualquier elemento de modelado, incluyendo clases, paquetes,
relaciones de herencia, etc. Por ejemplo, una clase con estereotipo 'actor' es una
clase usada como un agente externo en el modelado de negocio. Una clase patrn
es modelada como una clase con estereotipo parametrizado, lo que significa que
puede contener parmetros.