1

AO DE LA INVERSIN PARA EL DESARROLLO

RURAL Y LA SEGURIDAD ALIMENTARIA
ADMINISTRACIN II
LENGUAJE UNIFICADO DE MODELADO (UML)
PROFESOR:
Cesar Figueroa
CARRERA:
Redes y Comunicaciones
ALUMNO:
Llanos Cortez Richard
AO:


TRUJILLO - PERU
2013

2





INTRODUCCIN

En el presente trabajo se muestra el Lenguaje Unificado de
Modelado (UML), el cual contemplara los diferentes temas
vistos en el curso de Administracin II.
En primer lugar les describir la historia de UML.
En segundo lugar les explicare la definicin de UML y sus
principales beneficios. Adems tambin explicare los tipos
de vista y los distintos diagramas que existen
Finalmente terminare hablando de UML y su gran
importancia en cualquier empresa y los grandes beneficios
que ofrece para lograr una mejor eficiencia.
Tambin hay les muestro un ejercicio practico






3

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.
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 un 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).
Evolucin de UML:
4


LENGUAJE UNIFICADO DE MODELADO (UML)

Concepto:
Es un lenguaje grfico para visualizar, especificar, construir y documentar los
artefactos de un sistema orientado a objetos. Un artefacto es una informacin
que es utilizada o producida mediante un proceso de desarrollo de software.
Est demostrado que trabajar con UML incrementa la productividad, reduce el
ciclo de vida de la construccin del software e incrementa la calidad del
sistema.
UML entrega una forma de modelar cosas conceptuales como lo son procesos
de negocio y funciones de sistema, adems de cosas concretas como lo son
escribir clases en un lenguaje determinado, esquemas de base de datos y
componentes de software reusables.

PRINCIPALES BENEFICIOS DE UML:
Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas (y no slo de software) utilizando conceptos
orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de
misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por
mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.
Modela estructuras complejas.
Analiza el comportamiento del sistema.
Descripcin de UML:
Los elementos y diagramas UML estn basados en el modelo orientado a
objetos.
Entre las partes de UML tenemos:
1. Las Vistas: Muestran los diferentes aspectos del sistema que son
modelados. Una vista no es un grfico, pero es una abstraccin
consistente de un nmero de diagramas.
Se tiene las siguientes vistas:
a. Vista de Casos de Uso: Muestra la funcionalidad del sistema
percibido por actores externos.
b. Vista Logica o de Diseo: Muestra como la funcionalidad es
diseada dentro del sistema, define la estructura y el
comportamiento del sistema.
5

c. Vista de Componentes o Implementacion: Muestra la
organizacin de componentes del cdigo y su implementacin.
d. Vista Interaccin o de Procesos: Muestra la concurrencia en el
sistema dividido en procesos y procesadores. Da cuenta de los
aspectos de comunicacin e integracin.
e. Vista de Despliegue: Muestra la arquitectura fsica del sistema.

2. Los Diagramas: Son los grficos que describen el contenido de una
vista. UML tiene nueve tipos de diagramas que se usan para mostrarnos
todos los enfoques del sistema.

A. Diagrama de Casos de Uso: Que muestra a los actores (otros
usuarios de sistema), los casos de uso (las situaciones que se
producen cuando utilizan el sistema) y sus relaciones.

6



B. Diagrama de Clase: 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.


Clase: Una clase define los atributos y los mtodos de una serie
de objetos. Todos los objetos de esta clase (instancias de esa
clase) tienen el mismo comportamiento y el mismo conjunto de
atributos (cada objetos tiene el suyo propio).
En las clases estn representadas por rectngulos, con el nombre
de la clase, y tambin pueden mostrar atributos y operaciones de
la clase en otros dos compartimentos dentro del rectngulo.
Representacin visual de una clase en UML:





7



Atributos: En UML, los atributos se muestran al menos
con su nombre y tambin puede mostrar su tipo, valor
inicial y otras propiedades. Los atributos tambin pueden
ser mostrados visualmente.
+ indica atributos pblicos
# indica atributos protegidos
- indica atributos privados

Operaciones: Los operaciones (mtodos) tambin se
muestran al menos con su nombre, y pueden mostrar sus
parmetros y valores de retorno. Al igual que los atributos,
se pueden mostrar visualmente.
+ indica operaciones publicas
# indica operaciones protegidas
- indica operaciones privadas

Plantillas: Las clases pueden tener plantillas, un valor
usado para una clase no especificada o un tipo. El tipo de
plantilla se especifica cuando se inicia una clase (es decir
cuando se crea un objeto).

Asociaciones de Clase: Las clases pueden relacionarse con
otras de diferentes maneras.


Generalizacin: En UML, una asociacin de
generalizacin entre dos clases, coloca a estas en una
jerarqua que representa el concepto de herencia (recoger
los atributos y operaciones de la clase que es heredera) de
una clase derivada de la clase base. En UML, las
generalizaciones se representan por medio de una lnea
que conecta las dos clases, con una flecha en el lado de la
clase base.
Representacin visual de una generalizacin en UML:

Asociaciones: Una asociacin representa una relacin
entre clases, y aporta la semntica comn y la estructura
de muchos tipos de conexiones entre objetos.
Las asociaciones son los mecanismos que permite a los
objetos comunicarse entre s. Describe la conexin entre
diferentes clases (la conexin entre los objetos reales se
denomina conexin de objetos o enlace).
8




Acumulacin: Las acumulaciones son tipos especiales de
asociaciones en las que las dos clases participantes no
tienen un estado igual, pero constituyen una relacin
completa. Una acumulacin describe cmo se compone la
clase que asume el rol completo de otras clases que se
encargan de las partes. En las acumulaciones, la clase que
acta como completa, tiene una multiplicidad de uno.
En UML, las acumulaciones estn representadas por una
asociacin que muestra un rombo en uno de los lados de
la clase completa.




Composicin: Las composiciones son asociaciones que
representan acumulaciones muy fuertes. Esto significa que
las composiciones tambin forman relaciones completas,
pero dichas relaciones son tan fuertes que las partes no
pueden existir por s mismas. nicamente existen como
parte del conjunto, y si este es destruido las partes tambin
lo son.
En UML, est representado por un rombo solido al lado del
conjunto.




Otros componentes de los diagramas de clases:
Los diagramas de clases pueden contener ms componentes
aparte de clases
Interfaces: Las interfaces son clases abstractas, esto es,
instancias que no pueden ser creadas directamente a partir
de ellas. Pueden contener operaciones, pero no atributos.
Las clases pueden heredarse de las interfaces pudiendo
as realizarse instancias a partir de estos diagramas.
Tipos de Datos: Los tipos de datos son primitivas
incluidas en algunos lenguajes de programacin. Algunos
ejemplos son: bool y el float. No pueden tener relacin con
clases, pero las clases si pueden relacionarse con ellos.
Enumeraciones: Las enumeraciones son simples listas de
valores. Un ejemplo tpico de esto sera una enumeracin
de los das de la semana. Al igual que los tipos de datos,
no pueden relacionarse con las clases, pero las clases s
pueden hacerlo con ellos.
Paquetes: Los paquetes, en lenguajes de programacin,
representan un espacio de nombres en un diagrama se
9

emplean para representar partes del sistema que
contienen ms de una clase, incluso cientos de ellas.

C. Diagrama 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.
Los mensajes pueden ser o bien sncronos, el tipo normal de
llamada del mensaje donde se pasa el control a objeto llamado
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 invocante que muestra el flujo del control del programa.

D. 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.
10

En los diagramas de colaboracin los mensajes enviados de un
objeto a otro se representan mediante flechas.
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.


E. Diagramas 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.
Por ejemplo:
Mensajes recibidos, tiempo rebasado o errores, junto con sus
respuestas y acciones. Tambin ilustran qu eventos pueden
cambiar el estado de los objetos de la clase.
Hay dos tipos especiales de estados: Inicio y Fin. Son especiales
en el sentido de que no hay ningn evento que pueda devolver a
un objeto a su estado de inicio, y de la misma forma no hay
ningn evento que pueda sacar a un objeto de su estado de fin.
11






















F. Diagrama de Actividad: Diagrama que captura acciones, es
decir flujos de trabajo y actividades a llevarse a cabo. Este
diagrama permite enfocar:
Las actividades de un caso de uso de negocio.
La implementacin de operaciones de una clase
Las actividades de un objeto.
Las actividades de una situacin
Los diagramas de actividad siempre estn asociados a una
clase, a una operacin o a un caso de uso.
Los diagramas de actividad soportan actividades tanto
secuenciales como paralelas. La ejecucin paralela se
representa por medio de iconos de fork/espera, y en el caso
de las actividades paralelas, no importa en qu orden sean
invocadas (pueden ser ejecutadas simultneamente o una
detrs de otra).

12


G. Diagrama de Componentes: Representa los componentes de
software, sus dependencias y la estructura del cdigo. Los
componentes implementan en la arquitectura fsica, los conceptos
y la funcionalidad definidas en la arquitectura lgica.
Los componentes pueden ser fuentes binarias y ejecutables.
Los componentes pueden tener interfaces (es decir clases
abstractas con operaciones) que permiten asociaciones entre
componentes.




H. D
i
a
g
r
a
mas de Implementacin: Los diagramas de implementacin
muestran las instancias existentes al ejecutarse as como sus
relaciones. Tambin se representan los nodos que identifican
recursos fsicos, tpicamente un ordenador as como interfaces y
objetos (instancias de las clases).
Los diagramas de implementacin ofrecen una ilustracin de la
arquitectura fsica del hardware, del software y de los artefactos
del sistema. Los diagramas de implementacin pueden
entenderse como lo contrario de los casos de uso, porque ilustran
la forma fsica del sistema, en lugar de representar
conceptualmente los usuarios y dispositivos que interactan con
el sistema.







13

I. Diagrama de Objetos: Se puede considerar un caso especial de
un diagrama de clases en el que se muestran instancias
especficas de clases (objetos) en un momento particular del
sistema.
Los diagramas de objetos utilizan un subconjunto de los
elementos de un diagrama de clase. Los diagramas de objetos no
muestran la multiplicidad ni los roles, aunque su notacin es
similar a los diagramas de clase








J. Diagrama de Despliegue: Es un diagrama estructurado que
muestra la arquitectura del sistema desde el punto de vista del
despliegue (distribucin) de los artefactos del software en los
destinos de despliegue.
Los artefactos representan elementos concretos en el mundo
fsico que son el resultado de un proceso de desarrollo. Ejemplos
de artefactos son archivos ejecutables, bibliotecas, archivos,
esquemas de bases de datos, archivos de configuracin, etc
Destino de despliegue est generalmente representado por
un nodo que es o bien de los dispositivos de hardware o bien
algn entorno de ejecucin de software. Los nodos pueden ser
conectados a travs de vas de comunicacin para crear
sistemas en red de complejidad arbitraria.


3. Los elementos del modelo: Los conceptos usados son elementos del
modelo que representan conceptos orientados a objetos como clases,
objetos, mensajes y relaciones incluyendo asociacin, dependencia y
generalizacin.

4. Los mecanismos de extensin: Son los smbolos que complementan
la informacin de los diagramas, tenemos las notas, cajas de textos para
ttulos, lneas de indicacin, entre otros.

14

Importancia de UML?
Porque, 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.
Entre ms complejo es el sistema que se desea crear ms beneficios presenta
el uso de UML, las razones de esto son evidentes, sin embargo, existen dos
puntos claves : El primero se debe a que mediante un plano/visin global
resulta ms fcil detectar las dependencias y dificultades implcitas del sistema,
y la segunda razn radica en que los cambios en una etapa inicial (Anlisis)
resultan ms fciles de realizar que en una etapa final de un sistema como lo
sera la fase intensiva de codificacin.










15

Ejercicios
EJERCICIO 1:
Representa mediante un diagrama de clase la siguiente especificacin:
Una aplicacin necesita almacenar informacin sobre empresas, sus
empleados y sus clientes.
Ambos se caracterizan por su nombre y edad.
Los empleados tienen un sueldo bruto, los empleados que son directivos
tienen una categora, as como un conjunto de empleados subordinados.
De los clientes adems se necesita conocer su telfono de contacto.
La aplicacin necesita mostrar los datos de empleados y clientes.





16

EJERCICIO 2:
Una biblioteca tiene copias de libros. Estos ultimo se caracterizan por su
nombre, tipo (novela, teatro, poesa, ensayo), editorial, ao y autor.
Los autores se caracterizan por su nombre, nacionalidad y fecha de
nacimiento,
Cada copia tiene un identificador y puede estar en la biblioteca, prestada, con
retraso o en reparacin.
Los lectores pueden tener un mximo de 3 libros en prstamo.
Cada libro se presta un mximo de 30 das, por cada da de retraso, se impone
una multa de dos dias sin posibilidad de coger un nuevo libro.
Realiza un diagrama de clases y aade los mtodos necesarios para realizar el
prstamo y devolucin de libros.
Adems realiza el diagrama de estados de la clase Copia


17

Solucin de estados de la clase copia:

EJERCICIO 3: (Diagrama de Estado)
Modelar el comportamiento de una cadena de msica. Esta puede estar
encendida (ON) o apagada (Standby). La cadena tiene reproductor de CD,
Radio Cinta. Se cambia de uno a otro con el botn mode. Cuando se
enciende la cadena se recuerda el ultimo estado en el que estuvo.

Modelar el mismo sistema sin usar estado histrico.
18

Ejercicio 4:
Especificar el diagrama de secuencia de la operacin Crear Laberinto

Solucin:




19

EJERCISIO 5:
Especificar el diagrama de secuencia de la operacin realizar Jugada definida
en la clase jugador, para el juego de parchs.

Solucin: