Lenguaje unificado de modelado

Es un lenguaje grfico para visualizar, especificar, construir y documentar un

sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin, esquemas de
bases de datos y compuestos reciclados.
Para que sirve?
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que est descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar

soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado
Racional, Rational Unified Process o RUP), pero no especifica en s mismo qu
metodologa o proceso usar.

UML no puede compararse con la programacin estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad
de una utilizacin en un requerimiento. Mientras que programacin estructurada
es una forma de programar como lo es la orientacin a objetos, la programacin
orientada a objetos viene siendo un complemento perfecto de UML, pero no por
eso se toma UML solo para lenguajes orientados a objetos. UML es un lenguaje
para hacer modelos y es independiente de los mtodos de anlisis y diseo. Existen
diferencias importantes entre un mtodo y un lenguaje de modelado. Un mtodo es
una manera explcita de estructurar el pensamiento y las acciones de cada
individuo. Adems, el mtodo le dice al usuario qu hacer, cmo hacerlo, cundo
hacerlo y por qu hacerlo; mientras que el lenguaje de modelado carece de estas
instrucciones. Los mtodos contienen modelos y esos modelos son utilizados para
describir algo y comunicar los resultados del uso del mtodo.
 ETAPAS DE DESARROLLO DE SOFTWARE
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 como 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: En esta etapa se realizarn consultas bibliogrficas

relacionadas con el anlisis y diseo de sistemas de informacin con UML, a los
fines de elaborar un manual de UML con sus diagramas, definicin y ejemplos.
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 el primera fase pero slo finalizan una vez terminadas las
pruebas. Todo lo concerniente a la documentacin del propio desarrollo del
software y de la gestin del proyecto, pasando por modelaciones (UML),
diagramas, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el
propsito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.
Mantenimiento: En esta etapa se realizan un mantenimiento correctivo (resolver
errores) y un mantenimiento evolutivo (mejorar la funcionalidades y/o dar
respuesta a nuevos requisitos).

Nombre Definicin
Clases Los diagramas de clases describen la estructura
esttica de un sistema. Las cosas que existen y que
nos rodean se agrupan naturalmente en categoras.
Una clase es una categora o grupo de cosas que
tienen atributos (propiedades) y acciones similares.
Objetos Los Diagramas de Objetos estn vinculados con los
Diagramas de Clases. Un objeto es una instancia de
una clase, por lo que un diagrama de objetos puede
ser visto como una instancia de un diagrama de
clases. Los diagramas de objetos describen la
estructura esttica de un sistema en un momento
particular y son usados para probar la precisin de
los diagramas de clases.
Casos de Uso Un caso de uso es una descripcin de las acciones
de un sistema desde el punto de vista del usuario.
Los diagramas de caso de uso modelan la
funcionalidad del sistema usando actores y casos de
uso. Los casos de uso son servicios o funciones
provistas por el sistema para sus usuarios.
Estados En cualquier momento, un objeto se encuentra en
un estado particular, la luz est encendida o
apagada, el auto en movimiento o detenido, la
persona leyendo o cantando, etc. . El diagrama de
estados UML captura esa pequea realidad.
Secuencias Los diagramas de clases y los de objetos
representan informacin esttica. No obstante, en
un sistema funcional, los objetos interactan entre
s, y tales interacciones suceden con el tiempo. El
diagrama de secuencias UML muestra la mecnica
de la interaccin con base en tiempos.
Actividades Un diagrama de actividades ilustra la naturaleza
dinmica de un sistema mediante el modelado del
flujo ocurrente de actividad en actividad. Una
actividad representa una operacin en alguna clase
del sistema y que resulta en un cambio en el estado
del sistema. Tpicamente, los diagramas de
actividad son utilizados para modelar el flujo de
trabajo interno de una operacin.
 Colaboraciones El diagrama de colaboraciones describe las
interacciones entre los objetos en trminos de
mensajes secuenciados. Los diagramas de
colaboracin representan una combinacin de
informacin tomada de los diagramas de clases, de
secuencias y de casos de uso, describiendo el
comportamiento, tanto de la estructura esttica,
como de la estructura dinmica de un sistema.
Componentes Un diagrama de componentes describe la
organizacin de los componentes fsicos de un
sistema.
Distribucin El diagrama de distribucin UML muestra la
arquitectura fsica de un sistema informtico.
Puede representar a los equipos y a los dispositivos,
y tambin mostrar sus interconexiones y el software
que se encontrar en cada mquina.

Modelos de Desarrollo de Software

1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent
durante la creacin del mtodo estructurado. Si se
elige un proyecto, el mtodo varia en etapas.2 Como
todo modelo, existen sus pros y contras al usar este
paradigma: Si se aplica este paradigma, unos de los
principales problemas , es que las etapas realizadas
no son autnomas de las siguientes, creando una
dependencia estructural y en el acaso de un error
atrasara todo el proyecto. Se tiene que tener pautas bien definidas, y que no se
incurra a modificacin porque implicara en que el software no cumpla con su ciclo
de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.3

2. Paradigma Orientado a Objetos: Estos modelos se basan en

la Programacin orientada a objetos; por lo tanto, se refiere al concepto de clase, el
anlisis de requisitos y el diseo. El modelo o paradigma orientado a objetos posee
dos caractersticas principales, las cuales son: Permite la re-utilizacin de software.
Facilita el desarrollo de herramientas informticas de apoyo al desarrollo, el cual es
simple al implementarla en una notacin orientado a objetos llamado UML.4

3. Paradigma de Desarrollo gil: Es un paradigma de las Metodologas De

Desarrollo basado en procesos giles. Estos intentan evitar los tediosos caminos de
las metodologas tradicionales enfocndose en las personas y los resultados. Usa un
enfoque basado en el Valor para construir software, colaborando con el cliente e
incorporando los cambios continuamente.
 Diagrama de clase
Los diagramas de clases son diagramas de estructura esttica que muestran las
clases del sistema y sus interrelaciones (incluyendo herencia, agregacin,
asociacin, etc.). Los diagramas de clase son el pilar bsico del modelado con UML,
siendo utilizados tanto para mostrar lo que el sistema puede hacer (anlisis), como
para mostrar cmo puede ser construido (diseo). El diagrama de clases de ms
alto nivel, ser lgicamente un dibujo de los paquetes que componen el sistema.
Las clases se documentan con una descripcin de lo que hacen, sus mtodos y sus
atributos. Las relaciones entre clases se documentan con una descripcin de su
propsito, sus objetos que intervienen en la relacin y su opcionalidad (cuando un
objeto es opcional el que intervenga en una relacin).

Elementos:
Clase: Es la unidad bsica que encapsula toda la informacin de un Objeto (un
objeto es una instancia de una clase). A travs de ella podemos modelar el entorno
en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es
representada por un rectngulo que posee tres divisiones: En donde: Superior:
Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de
instancia) que caracterizan a la Clase (pueden ser private, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como
interacta el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).

Atributos: son valores que corresponden a un objeto, como color, material,

cantidad, ubicacin. Generalmente se conoce como la informacin detallada del
objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos seran: la
marca, tamao, color y peso. Tipos de atributos: public (+, ): Indica que el
atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde
todos lados. private (-, ): Indica que el atributo slo ser accesible desde dentro de
la clase (slo sus mtodos lo pueden utilizar). protected (#, ): Indica que el
atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por
mtodos de la clase adems de las subclases que se deriven (ver herencia).

Operaciones/Mtodos: son aquellas actividades o verbos que se pueden realizar

con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar,
cargar. El nombre de una operacin se escribe con minsculas si consta de una sola
palabra. Si el nombre contiene ms de una palabra, cada palabra ser unida a la
anterior y comenzar con una letra mayscula, a excepcin de la primera palabra
que comenzar en minscula. Por ejemplo: abrirPuerta, cerrarPuerta,
buscarPuerta, etc. Tipos de mtodos: public (+, ): Indica que el mtodo ser
visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.
private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase lo pueden utilizar). protected (#, ): Indica que el mtodo
no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de
la clase adems de mtodos de las subclases que se deriven (ver herencia).
EJEMPLO 1

EJEMPLO 2
 Diagrama de secuencia
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que
el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementacin del
escenario, incluyendo los objetos y clases que se usan para implementar el
escenario y mensajes intercambiados entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu
objetos son necesarios para la implementacin del escenario. Si se dispone de la
descripcin de cada caso de uso como una secuencia de varios pasos, entonces se
puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para
que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que
intervienen en el escenario con lneas discontinuas verticales, y los mensajes
pasados entre los objetos como flechas horizontales.

Elementos

OBJETOS: Los objetos se colocan cerca de la parte superior del diagrama de

izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.

MENSAJES: Un mensaje puede ser simple, sncrono y asncrono:

Mensaje simple: es la transferencia de datos de un objeto a otro.
Mensaje sncrono: es cuando el objeto espera la respuesta a ese mensaje
antes de continuar con su trabajo.
Mensaje asncrono: es cuando el objeto no espera la respuesta a ese mensaje
antes de continuar.

LINEA DE TIEMPO: La lnea de vida o lnea de tiempo, se representan con una

lnea vertical estas expresan el tiempo de vida del objeto. El rectngulo vertical que
se puede apreciar es una barra de activacin su funcin es representar el tiempo de
duracin del mensaje.

RECURSIVIDAD: En ocasiones un objeto posee una operacin que se invoca a si

misma. A esto se le conoce como recursividad y es una caracterstica fundamental
de varios lenguajes de programacin
EJEMPLO 1

EJEMPLO 2
 Diagramas de objetos
Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un
instante de tiempo determinado. Puede verse como una fotografa del sistema que
muestra el estado de los objetos en ese instante. La representacin grfica de un
objeto en UML es igual que la de una clase pero con el nombre subrayado. Para
mostrar el estado de un objeto, se indica el valor de sus atributos y sus objetos
agregados. La nica relacin entre objetos que se puede representar en UML es el
enlace. Un enlace indica una conexin entre dos objetos. Dos objetos pueden estar
conectados si existe una asociacin o una dependencia entre las clases que
instancian. Los diagramas de objetos pueden contener paquetes y, cuando se quiere
mostrar la clase que hay detrs de cada instancia, tambin pueden contener clases.

Elementos

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 1

EJEMPLO2
REFERENCIA BIBLIOGRAFICAS

http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf
https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
https://www.slideshare.net/myle22/qu-es-uml-para-que-sirve-pasos
http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml
http://egdamar877.blogspot.mx/2009/05/expocicion.html
https://es.wikipedia.org/wiki/Proceso_para_el_desarrollo_de_software
http://mood.itdurango.edu.mx/mod/forum/discuss.php?d=25
https://sistemasvd.wordpress.com/2008/07/05/fases-del-proceso-de-desarrollo-del-
software/
http://www.arqhys.com/general/diagrama-de-objetos.html
http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf