Lenguaje de modelado de sistemas de software (UML)

Es la herramienta grafica que Se utiliza para especificar mtodos o

procesos realizados por el sistema, por medio de una serie de smbolos.
Unified Modeling Language o Lenguaje Unificado de Modelado
Nos proporciona una serie de herramientas que permiten mostrar el
programa en sus diferentes etapas o procesos, delimitarlos y organizarlos
de tal forma que sean entendibles por la persona que va a desarrollar el
sistema.
Cabe destacar que UML no es un lenguaje de programacin, sino el
sistema que permite modelar la estructura del programa.

Para qu sirve?
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

Para qu se utiliza?
Esta consolidado como el lenguaje estndar en el anlisis y diseo de
sistemas de cmputo. 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.
Fases del Proceso de Desarrollo del Software
El proceso requiere una metodologa con 5 etapas:
Anlisis de requerimientos: Se extraen los requisitos del producto de
software. En esta etapa la habilidad y experiencia en la ingeniera del
software es crtica para reconocer requisitos incompletos, ambiguos o
contradictorios. Usualmente el cliente/usuario tiene una visin
incompleta/inexacta de lo que necesita y es necesario ayudarle para
obtener la visin completa de los requerimientos. El contenido de
comunicacin en esta etapa es muy intenso ya que el objetivo es eliminar
la ambigedad en la medida de lo posible.
Especificacin: Es la tarea de describir detalladamente el software a ser
escrito, de una forma rigurosa. Se describe el comportamiento esperado
del software y su interaccin con los usuarios y/o otros sistemas.
Diseo y arquitectura: Determinar cmo funcionar de forma general
sin entrar en detalles incorporando consideraciones de la
implementacin tecnolgica, como el hardware, la red, etc. Consiste en
el diseo de los componentes del sistema que dan respuesta a las
funcionalidades descritas en la segunda etapa tambin conocidas como
las entidades de negocio. Generalmente se realiza en base a diagramas
que permitan describir las interacciones entre las entidades y su
secuenciado.
Programacin: Se traduce el diseo a cdigo. Es la parte ms obvia del
trabajo de ingeniera de software y la primera en que se obtienen
resultados tangibles. No necesariamente es la etapa ms larga ni la ms
compleja, aunque una especificacin o diseo incompletos/ambiguos
pueden exigir que, tareas propias de las etapas anteriores se tengan que
realizarse en esta.
Prueba: Consiste en comprobar que el software responda/realice
correctamente las tareas indicadas en la especificacin. Es una buena
praxis realizar pruebas a distintos niveles (por ejemplo, primero a nivel
unitario y despus de forma integrada de cada componente) y por equipos
diferenciados del de desarrollo (pruebas cruzadas entre los
programadores o realizadas por un rea de test independiente).
Documentacin: Realizacin del manual de usuario, y posiblemente un
manual tcnico con el propsito de mantenimiento futuro y ampliaciones
al sistema. Las tareas de esta etapa se inician ya en la primera fase, pero
slo finalizan una vez terminadas las pruebas.
Mantenimiento: En esta etapa se realizan un mantenimiento correctivo
(resolver errores) y un mantenimiento evolutivo (mejorar la funcionalidad
y/o dar respuesta a nuevos requisitos).

Diagramas UML

Tipo de Etapa de
diagrama Descripcin utilidad en el
desarrollo del
software
Diagrama de Es uno de los tipos de Anlisis; en esta
Clases diagramas o smbolo ocasin las clases no
esttico y tiene como deben ser clases de
fin describir la diseo, sino clases de
estructura de un anlisis,
sistema mostrando conceptuales.
sus clases, atributos Esto significa que lo
y relaciones entre importante es recoger
ellos. la esencia del
Estos diagramas son concepto, reconocer
utilizados durante el los aspectos clave de
 proceso de anlisis y ese concepto, sus
diseo de los atributos sin
sistemas preocuparse de cmo
informticos, en se implementar ese
donde se intentan atributo (si es inti,
conformar el string, etc.), y sus
diagrama conceptual responsabilidades
de la informacin que
se manejar en el
sistema.
Casos de uso Muestra un conjunto Se utilizan durante
de casos de uso, los todo el ciclo de vida
actores implicados y del proyecto, la fase de
sus relaciones. Son anlisis, comienza con
diagramas la captura de
fundamentales en el requisitos, y los CU
modelado y son una herramienta
organizacin del para capturar
sistema. requisitos funcionales
del sistema.
Actividad Tipo especial de Cubren la parte
diagrama de estados dinmica de un
que muestra el flujo sistema y se utilizan
de actividades dentro para modelar el
de un sistema. funcionamiento de un
sistema resaltando el
flujo de control entre
objetos.
Diagrama de Son diagramas de Se utilizan mucho
secuencia interaccin, muestran para explicar cmo las
un conjunto de clases conceptuales
objetos y sus colaboran para
relaciones, as como resolver los casos de
los mensajes que se uso del anlisis. Ms
intercambian entre adelante, se utilizan
ellos. Cubren la vista para explicar cmo las
dinmica del sistema. clases de diseo
colaboran para
resolver actividades
en un escenario dado.
Diagrama de Muestra una Pueden ser utilizados
Estados mquina de estados, en todas las fases, lo
con sus estados, que cambian son
transiciones, eventos algunos detalles de
 y actividades. Cubren interpretacin pero
la vista dinmica de son muy tiles al
un sistema. Modelan momento de modelar
comportamientos el comportamiento de
reactivos en base a una interfaz, clase o
eventos. colaboracin.
Diagrama de En este diagrama se Pueden ser utilizados
objetos modelan las en todas las fases, lo
instancias de las que cambian son
clases del Diagrama algunos detalles de
de Clases. Este interpretacin
diagrama cabe aclarar
que cuenta con
objetos y enlaces. En
estos diagramas
tambin es posible
encontrar las clases
para tomar como
referencia su
instanciacin.
Diagrama de En el diagrama de Pueden ser utilizados
colaboracin colaboracin de los en todas las fases, lo
elementos grficos no que cambian son
son cajas algunos detalles de
rectangulares, como interpretacin
cabra esperar, y en
su lugar encontramos
sus versiones
adornadas. Estas
versiones tienen como
finalidad evidenciar
un rol especfico del
objeto siendo
modelado.
Diagrama de Representan la Pueden ser utilizados
despliegue configuracin de los en todas las fases, lo
nodos de que cambian son
procesamiento en algunos detalles de
tiempo de ejecucin y interpretacin
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.
Diagramas de Muestra la Pueden ser utilizados
Componentes organizacin y las en todas las fases, lo
dependencias entre que cambian son
un conjunto de algunos detalles de
componentes. Cubren interpretacin
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

Diagrama de clases
Sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenimiento.
Est compuesto por los siguientes elementos:
- Clase: atributos, mtodos y visibilidad.
- Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Clase Abstracta
Las clases se representan con
rectngulos divididos en tres reas: la
superior contiene el nombre de la
clase, la central contiene los
atributos y la inferior las acciones.
Clase Aviones
En el rea superior figura el nombre
de la clase que utilizamos como ejemplo,
en la central estn sus atributos y en
la inferior las acciones que ella realiza.

Asociaciones
Las asociaciones son
las que representan
a las relaciones estticas entre las clases.
El nombre de la asociacin va por sobre o
por debajo de la lnea que la representa.

Multiplicidad
Las notaciones utilizadas para sealar la
multiplicidad se colocan cerca del final de
una asociacin. Estos smbolos indican el
nmero de instancias de una clase
vinculadas a una de las instancias de la
otra clase.

Asociacin Tripartita
Composicin y Agregacin
Composicin es un tipo especial de
agregacin que denota un fuerte
posesin de la Clase Todo, a la Clase
Parte. Se grafica con un rombo
diamante relleno contra la clase que
representa el todo.
La agregacin es una relacin en la que la
Clase Todo juega un rol ms importante
que la Clase "Parte", pero las dos clases
no son dependientes una de otra. Se
grafica con un rombo diamante vaco
contra la Clase Todo.

Generalizacin
Generalizacin es otro nombre para
herencia. Se refiere a una relacin entre
dos clases en donde una Clase
Especfica es una versin especializada
de la otra, o Clase General. Por
ejemplo, Honda es un tipo de auto, por lo
que la Clase Honda va a tener una
relacin de generalizacin con la Clase
Auto.
Ejemplo:

Diagrama de objetos
Forma parte de la vista esttica del sistema. En este diagrama se modelan
las instancias de la clase del Diagrama de Clases. Este diagrama cabe
aclarar que cuenta con objetos y enlaces. En estos diagramas tambin es
posible encontrar las clases para tomar como referencia su instanciacin.

Nombre de los objetos

Cada objeto es representado como un
rectngulo, que contiene el nombre del objeto
y
su clase subrayadas y separadas por dos
puntos.
 Atributos
Como con las clases, los atributos se listan en
un rea inferior. Sin embargo, los atributos de
los objetos deben tener un valor asignado.

Ejemplo:

Diagrama de secuencias
Un Diagrama de Secuencias muestra una interaccin ordenada segn la
secuencia temporal de eventos y el intercambio de mensajes. Los
diagramas diagramas de secuencia ponen especial nfasis en el orden y
el momento en el que se envan los mensajes a los objetos.

Rol de la Clase
El rol de la clase describe la manera en que
un objeto se va a comportar en el contexto.
No se listan los atributos del objeto.
Activacin
Los cuadros de activacin representan el
tiempo que un objeto necesita para
completar una tarea.

Mensajes
Los mensajes son flechas que representan
comunicaciones entre objetos. Las medias
flechas representan mensajes asincrnicos.
Los mensajes asincrnicos son enviados
desde un objeto que no va a esperar una
respuesta del receptor para continuar con
sus tareas.
Lneas de Vida
Las lneas de vida son verticales y en lnea
de puntos, ellas indican la presencia del
objeto durante el tiempo.

Destruccin de Objetos
Los objetos pueden ser eliminados
tempranamente usando una flecha
etiquetada "<<destruir>>" que apunta a
una X.

Loops
Una repeticin o loop en un diagrama de
secuencias, es representado como un
rectngulo. La condicin para abandonar el
loop se coloca en la parte inferior entre
corchetes [].

En los diagramas de Secuencias los elementos estn representados por

lneas intermitentes verticales, con el nombre del objeto en la parte ms
alta.
Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del
mensaje donde se pasa el control a objeto llamad hasta que el mtodo
finalice, o asncronos donde se devuelve el control directamente al objeto
que realiza la llamada.
Los mensajes sncronos tienen una caja vertical en un lateral del objeto
invocarte que muestra el flujo del control del programa
Ejemplo:
Referencias:
- http://ingenieriadesistemas-shirley.blogspot.mx/2012/05/tipos-
de-diagramas-uml.html
- http://www.monografias.com/trabajos28/proyecto-
uml/proyecto-uml3.shtml
- https://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-
modelado-sistemas-UML/multiple-html/x219.html
- http://ithuejutlaisabelgarciamendez.blogspot.mx/2013/02/13-
etapas-de-desarrollo-de-software_19.html
- http://www.lawebdelprogramador.com/foros/UML/645685-Que-
diagram-utilizo-en-cada-fase.html
- http://www.teatroabadia.com/es/uploads/documentos/iagramas
_del_uml.pdf
- https://es.slideshare.net/jjgramp/descripcin-general-de-los-13-
diagramas-uml-y-sus-componentes
- http://aprenderaprogramar.com/index.php?option=com_content
&view=article&id=688:ique-es-y-para-que-sirve-uml-versiones-de-
uml-lenguaje-unificado-de-modelado-tipos-de-diagramas-
uml&catid=46:lenguajes-y-entornos&Itemid=163
- https://docs.kde.org/trunk4/es/kdesdk/umbrello/uml-
basics.html
- https://www.altova.com/es/umodel/object-diagrams.html
- https://www.altova.com/es/umodel/uml-deployment-
diagrams.html
- http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html