c
cc





c

c 

 
UML es una técnica para la especificación sistemas en todas sus
fases. Nació en 1994 cubriendo los aspectos principales de todos los
métodos de diseño antecesores y, precisamente, los padres de UML son
Grady Booch, autor del método Booch; James Rumbaugh, autor del
método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory.
La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado
con éxito en sistemas construidos para toda clase de industrias a lrededor
del mundo: hospitales, bancos, comunicacio nes, aeronáutica, finanzas.
 

c


Hoy en día, UML ("Unified Modeling Language") esta consolidado
como el lenguaje estándar en el análisis y diseño 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 código.
En otros términos, así como en la construcción de un edificio se
realizan planos previo a su construcción, en Software se deben realizar
diseños en UML previa codificación de un sistema, ahora bien, aunque
UML es un lenguaje, éste posee más características visuales que
programáticas, mismas que facilitan a integrantes de un equipo
multidisciplinario participar e intercomunicarse fácilmente, estos
integrantes siendo los analistas, diseñadores, especialistas de área y
desde luego los programadores.


cc

c


UML es un lenguaje para:
 Visualizar.
 Especificar.
 Construir.
 Documentar.





Un lenguaje proporciona vocabulario y las reglas para combinar

palabras de ese vocabulario con el objetivo de posibilitar la comunicación.
En un lenguaje de modelado su vocabulario y reglas se centran en la
representación conceptual y física de un sistema. UML es un lenguaje
estándar para los planos software.
Proporciona una comprensión del sistema. Nunca es suficiente un
único modelo, para comprender cualquier cosa se necesitan
múltiples modelos conectados entre sí. Para sistemas con gran cantidad
de software, se requiere un lenguaje que abarque las diferentes vistas de
la arquitectura de un sistema conforme evoluciona a través del ciclo de
vida del desarrollo de software.
El vocabulario y las reglas de un lenguaje como UML indican cómo
crear y leer modelos bien formados pero no dicen qué modelos se deben
crear ni cuándo se deberían crear. Esta es la tarea del proceso de
desarrollo de software. Un proceso bien definido guiará a sus usuarios al
decidir qué artefactos producir, qué actividade s y qué personal se emplea
para crearlos y gestionarlos, y cómo usar esos artefactos para medir y
controlar el proyecto de forma global.





 

Un programador a veces realiza el modelado mentalmente, es
decir, avanza en el desarrollo codificando simultáneamente. Se puede
vales de bosquejos de ideas, pero no son entendibles fácilmente por otros
ó simplemente este sujeta a errores, a menos que haya personas
implicadas que hablen el mismo lenguaje. El código fuente del sistema no
es bagaje suficiente para interpretar un sistema y
surgen lenguajes de texto y gráficos como UML.


 



c!"!
Especificar es construir modelos precisos, no ambiguos y
completos. UML cubre la especificación de todas las decisiones
de análisis, diseño e implementación que deben realizarse al desarrollar y
desplegar un sistema con gran cantidad de software
.





#$

No es un lenguaje de programación visual, pero sus modelos
pueden conectarse de forma directa a un gran variedad de lenguajes de
programación. Java, C++, Visual Basic, tablas en una base de
datos relacional. Las cosas que se expresan mejor se gráficamente se
expresan en UML mientras que las que se expresan mejor textualmente
se plasman en el lenguaje de programación.
Esto permite la ingeniería directa, es decir la generación de código
a partir de un modelo UML como también la ingeniería inversa q ue
consiste en escribir código a partir de una implementación, ésta requiere
de herramientas que la soporten y de la intervención humana. UML es lo
suficientemente expresivo y no ambiguo para permitir la ejecución directa
de modelos, la simulación de sistemas y la coordinación de sistemas de
ejecución.







#!%$

Una organización de software, además de código ejecutable, debe
producir toda clase de artefactos como:
 Requisitos.
 Arquitectura.
 Diseño.
 Código fuente.
 Planificación de proyectos.
 Pruebas.
 Prototipos.
 Versiones.
Estos son críticos para el control, la medición y comunicación que
requiere un sistema durante sus desarrollo y después de su despliegue.
UML cubre la documentación de la arquitectura y todos sus detalles. UML
proporciona un lenguaje para expresar requisitos y pruebas y para
modelar las actividades de planificación de proyectos y gestión de
versiones.

  

c




%
&
c$!$
enfatizan en los elementos que deben existir en

el sistema modelado:
* Diagrama de clases
* Diagrama de componentes
* Diagrama de objetos
* Diagrama de estructura compuesta
* Diagrama de despliegue
* Diagrama de paquetes

%
&
#%#$%$# enfatizan en lo que debe suceder en el

sistema modelado:
* Diagrama de actividades
* Diagrama de casos de uso
* Diagrama de estados

%
&
$!!' son un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos entre los
elementos del sistema modelado:
* Diagrama de secuencia
* Diagrama de comunicación, que es una versión simplificada
del Diagrama de colaboración (UML 1.x)
* Diagrama de tiempos (UML 2.0)
* Diagrama global de interacciones o Diagrama de vista de
interacción (UML 2.0)



c
c 

De los Diagramas de Estructura se hará énfasis en el diagrama de
clases y el diagrama de objetos.

%
&


El Diagrama de Clases es el diagrama principal para el análisis y
diseño. Un diagrama de clases presenta las clases del sistema con sus
relaciones estructurales y de herencia. La definición de clase incluye
definiciones para atributos y operaciones. En el diagrama de clases es
donde se define las características de cada una de las clases, interfaces,
colaboraciones y relaciones de dependencia y generaliza ción.
Es decir, es donde se da rienda suelta a los conocimientos de
diseño orientado a objetos, definiendo las clases e implementando las ya
típicas relaciones de herencia y agregación. Ejemplo:

En este diagrama se han creado cuatro clases. La clase principal

es Usuario, que tiene dos clases hijas UsuarioADM y UsuarioINF . El
usuario mantiene una relación de asociación con la clase Clave, se indica
que es propietario de una clave, o de un número indeterminado de ellas.
Se le crea también una relación de dependencia con la clase Perfil, es
decir las instancias de usuario contendrán como miembro una instancia
de Perfil.

%
&
($#

Forma parte de la vista estática del sistema. En este diagrama se
modelan las instancias de las clases del diagrama de clases. Muestra a
los objetos y sus relaciones, pero en un momento concreto del sistema.
Estos diagramas contienen objetos y enlaces. En los diagramas de
objetos también se pueden incorporar clases, para mostrar la clase de la
que es un objeto representado.
En este diagrama se muestra un estado del diagrama de eventos.
Para realizar el diagrama de objetos primero se debe decidir que situación
queremos representar del sistema. Es decir si disponemos de un sistema
de mensajería, deberemos decidir que representaremos el sistema con
dos mensajes entrantes, los dos para diferen tes departamentos, dejando
un departamento inactivo. Para el siguiente diagrama de clases:
 Tendríamos un diagrama de objetos con dos instancias de
Mensaje, mas concretamente con una instancia de MensajeDIR y otra de
MensajeADM, con todos sus atributos valorados. También tendríamos
una instancia de cada una de las otras clases que deban tener instancia.
Como CanalEnt, INS, Distr, y el Buzon correspondiente a la instancia de
mensaje que se este instanciando. En la instancia de la clase INS se
deberá mostrar en su miembro Estado, que esta ocupado realizando una
inserción.
En un diseño no podemos encontrar con multitud de diagramas de
objetos, cada uno de ellos representando diferentes estados del sistema.



c
c

Los diagramas de comportamiento se emplean para visualizar,
especificar, construir y documentar los aspectos dinámicos de un sistema.
Los aspectos dinámicos de un sistema de software involucran
cosas tales como el flujo de mensajes a lo largo del tiempo y el
movimiento físico de componentes en una red.
A continuación se describe y ejemplifica los diagramas de
comportamiento de UML

%
&
#
&
#

Se emplean para visualizar el comportamiento del sistema, una
parte de el o de una sola clase. De forma que se pueda conocer cómo
responde esa parte del sistema. El diagrama de uso es muy útil para
definir como debería ser el comportamiento de una parte del sistema, ya
que solo especifica cómo deben comportarse y no como están
implementadas las partes que define. Por ello es un buen sistema de
documentar partes del código que deban ser reutilizables por otros
desarrolladores.
El diagrama también puede ser utilizado para que los expertos de
dominio se comuniquen con los informát icos sin llegar a niveles de
complejidad. Un caso de uso especifica un requerimiento funcional, es
decir indica esta parte debe hacer esto cuando pase esto.
En el diagrama nos encontramos con diferentes figuras que
pueden mantener diversas relaciones entr e ellas:
 #
&
#) representado por una elipse, cada caso de uso
contiene un nombre, que indique su funcionalidad. Los casos de uso
pueden tener relaciones con otros caso de uso. Sus relaciones son:
 !&) Representado por una flecha, en el diagrama d e ejemplo
podemos ver como un caso de uso, el de totalizar el coste incluye a dos
casos de uso.
 c*$&) Una relación de una caso de Uso A hacia un caso de uso
B indica que el caso de uso B implementa la funcionalidad del caso de
uso A.
  $#) Es la típica relación de herencia.
 !$#) se representan por un muñeco. Sus relaciones son:
Communicates: Comunica un actor con un caso de uso, o con otro actor.
Parte del sistema (System boundary): Representado por un cuadro,
identifica las diferentes partes del sistema y contiene los casos de uso
que la forman.
 En este grafico encontramos tres casos de usos Crear producto
utiliza Validar producto, y Crear pack productos es una especialización de
Crear productos.
Podemos emplear el diagrama de dos formas diferentes, para
modelar el contexto de un sistema, y para modelar los requisitos del
sistema.

%
&
!$+&&

En UML un diagrama de actividades se usa para mostrar la
secuencia de actividades. Los diagramas de actividades muestran el flujo
de trabajo desde el punto de inicio hasta el punto final detallando muchas
de las rutas de decisiones que existen en el progreso de eventos
contenidos en la actividad. Estos también pueden usarse para detallar
situaciones donde el proceso paralelo puede ocurrir en la ejecución de
algunas actividades. Los Diagramas de Actividades son útiles para el
Modelado de Negocios donde se usan para detallar el proceso
involucrado en las actividades de negocio.







%
&
$&#

Es un diagrama utilizado para identificar cada una de las rutas o
caminos que puede tomar un flujo de información luego de ejecutarse
cada proceso. Permite identificar bajo qué argumentos se ejecuta cada
uno de los procesos y en qué momento podrían tener una variación. El
diagrama de estados permite visualizar de una forma secuencial la
ejecución de cada uno de los procesos.

















 , 



Luego de estudiar cada uno de los diagramas de UML, así como su
utilidad para proyectos de ingeniería y para muchos otros tipos de
sistemas, se puede decir que aunque no es la única herramienta para el
análisis y diseño de sistemas, sí es una opción muy poderosa que puede
ofrecer excelentes soluciones y una gran ayuda a la hora de crear o
diseñar un sistema.
Esto también ayuda a trabajar ordenadamente, ahorrando tiempo,
dinero y muchos problemas que se podrían desencadenar como
consecuencia de no tener una adecuada y correcta documentación de las
partes que componen un sistema.
Por supuesto que este documento explica cada u no de los temas
expuestos de manera breve, pero la idea que se da es suficiente como
para presentar un buen panorama de lo que es el UML y los usos que
tiene, así como de los elementos que componen una interfaz gráfica de
usuario.
En síntesis se puede decir que, UML no es el único lenguaje de
modelado que existe, por lo cual conviene examinar también otras
opciones. Sin embargo, se debe tener presente que UML es el lenguaje
de modelado de sistemas más usado y conocido en la actualidad, lo cual
sugiere que es una herramienta útil, e n gran medida usada como
estándar, y digna de ser conocida e implementada para proyectos de
sistemas.
 REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN
SUPERIOR
UNIVERSIDAD POLITÉCNICA DE LOS LLANOS
EXTENSIÓN ALTAGRACIA DE ORITUCO
ESTADO GUÁRICO

cc

c

c 

  

 











  
)















 c)

Ing. José Ytriago Mecia Villensa C.I. 18.352.920

Abril 2011