Integrante:

Nicole Prez A.

Semestre: Primer semestre de Ingeniera en Informtica.

Asignatura: Tcnica de la Comunicacin Oral y Escrita.
Docente: Mara Isabel Hidalgo.
Fecha de entrega: 09/05/2014
2014- Sede Inacap Centro

INDICE.I UML.....1
I.1 INTRODUCCIN......1
II HISTORIA DE UML. .2
II.1 QUIENES LO IMPULSARON Y PORQUE ?....................................2
II.2 OBJETIVOS...3
II.3 MODELOS........4
II.3.1 Diagrama de Clase......4
II.3.2 Diagrama de Caso de Uso.......5
II.3.3 Diagrama de Secuencia....6
II.3.4 Diagrama de Componentes......6
II.3.5 Diagrama de Estados.......7
III.1 CONCLUSIN.....8
IV.1 BIBLIOGRAFIA...9

I UML
I.

1.- INTRODUCCIN.-

UML (Unified Modeling Language) es un lenguaje que permite modelar,

construir y documentar los elementos que forman un sistema software orientado
a objetos. Se ha convertido en el estndar de facto de la industria, debido a que
ha sido concebido por los autores de los tres mtodos ms usados de orientacin
a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron
contratados por la empresa Rational Software Co. para crear una notacin
unificada en la que basar la construccin de sus herramientas CASE. En el
proceso de creacin de UML han participado, no obstante, otras empresas
de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM,
as como grupos de analistas y desarrolladores.
Esta notacin ha sido ampliamente aceptada debido al prestigio de sus
creadores y debido a que incorpora las principales ventajas de cada uno de los
mtodos particulares en los que se basa: Booch, OMT y OOSE. UML ha
puesto fin a las llamadas guerras de mtodos que se han mantenido a lo
largo de los 90, en las que los principales mtodos sacaban nuevas versiones
que incorporaban las tcnicas de los dems. Con UML se fusiona la notacin de
estas tcnicas para formar una herramienta compartida entre todos los
ingenieros software que trabajan en el desarrollo orientado a objetos.
Historia de UML.-

II HISTORIA UML.-

II.

1.- QUIENES LO IMPULSARON Y PORQUE?

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 haba 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. Es
un lenguaje de modelado visual que se usa para especificar, visualizar, construir y
documentar artefactos de un sistema de software. Se usa para entender, disear,
configurar, mantener y controlar la informacin sobre los sistemas a construir. UML
capta la informacin sobre la estructura esttica y el comportamiento dinmico de
un sistema. Un sistema se modela como una coleccin de objetos discretos que
interactan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas
de modelado e incorporar las mejores prcticas actuales de un acercamiento
estndar. UML no es un lenguaje de programacin. Las herramientas pueden
ofrecer generadores de cdigo de UML para una gran variedad de lenguaje de
programacin, as como construir modelos por ingeniera inversa a partir de
programas existentes. La notacin UML se deriva y unifica las tres metodologas
de
anlisis
y
diseos
ms
extendidas.
Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus
relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object
Modelling Technique). Aproximacin de Ivar Jacobson (OOSE: Object- Oriented
Software Engineering) mediante la metodologa de casos de uso (use case). El
desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim
Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A
finales de 1995, Ivar Jacob son y su compaa Objectory se incorporaron a
Rational en su unificacin, aportando el mtodo OOSE. 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).

II. 2.-

OBJETIVOS DE UML.-

Durante el desarrollo del UML sus autores tuvieron en cuenta:

Proporcionar una notacin y semnticas suficientes para poder alcanzar

una gran cantidad de aspectos del modelado contemporneo de una forma
directa y econmica.

Proporcionar las semnticas suficientes para alcanzar aspectos del

modelado que son de esperar en un futuro, como por ejemplo aspectos
relacionados con la tecnologa de componentes, el cmputo distribuido, etc.

Proporcionar mecanismos de extensin de forma que proyectos concretos

puedan extender el meta-modelo a un coste bajo. Proporcionar
mecanismos de extensin de forma que aproximaciones de modelado
futuras podran desarrollarse encima del UML.

Permitir el intercambio del modelo entre una gran variedad de herramientas.

Proporcionar semnticas suficientes para especificar las interfaces a
bibliotecas para la comparacin y el almacenamiento de componentes del
modelo.

Ser tan simple como sea posible pero manteniendo la capacidad de

modelar toda la gama de sistemas que se necesita construir.

UML es un lenguaje de modelado de propsito general que pueden usar

todos los modeladores.

UML no pretende ser un mtodo de desarrollo completo. Debe ser un

lenguaje universal, como cualquier lenguaje de propsito general y as
imponer un estndar mundial.

II. 3.-

MODELOS.-

Un modelo representa a un sistema software desde una perspectiva especfica.

Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran
la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos
en un aspecto distinto del sistema.
Los modelos de UML que se trataran sern los siguientes:
Diagrama de Clases.
Diagrama de Casos de Secuencia.
Diagrama de Secuencias.
Diagrama de Componentes.
Diagrama de Estados.

Diagrama de Clases.Una clase se representa mediante una caja subdividida en tres partes: En la
superior se muestra el nombre de la clase, en la media los atributos y en la
inferior las operaciones. Una clase puede representarse de forma esquemtica
(plegada), con los detalles como atributos y operaciones suprimidos, siendo
entonces tan solo un rectngulo con el nombre de la clase.
Ejemplo.-

Diagrama de Casos de Uso.Un Diagrama de Casos de Uso muestra la relacin entre los actores y los
casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en
lo que se refiere a su interaccin externa y posee tres tipos de elementos que
pueden aparecer en ellos: actores, casos de uso y relaciones entre casos de
uso.
Actores.Un actor es una entidad externa al sistema que realiza algn tipo de interaccin
con el mismo. Se representa mediante una figura humana dibujada con palotes.
Esta representacin sirve tanto para actores que son personas como para otro
tipo de actores (otros sistemas, sensores, etc.).
Casos de Uso.Un caso de uso es una descripcin de la secuencia de interacciones que se
producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a
cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y
se representa en el Diagrama de Casos de Uso mediante una elipse con el
nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar
la tarea especfica que el actor desea llevar a cabo usando el sistema.
Relaciones entre Casos de Uso.Entre dos casos de uso puede haber las siguientes relaciones

Extiende: Cuando un caso de uso especializa a otro extendiendo su

funcionalidad.

 Usa: Cuando un caso de uso utiliza a otro.

Se representan como una lnea que une a los dos casos de uso relacionados,
con una flecha en forma de tringulo y con una etiqueta <<extiende>> o <<usa>>
segn sea el tipo de relacin. En el diagrama de casos de uso se representa
tambin el sistema como una caja rectangular con el nombre en su interior. Los
casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada
actor est unido a los casos de uso en los que participan mediante una lnea.

Ejemplo.-

Diagrama de Secuencias.Un diagrama de Secuencia muestra una interaccin ordenada segn la

secuencia temporal de eventos. En particular, muestra los objetos participantes
en la interaccin y los mensajes que intercambian ordenados segn su
secuencia en el tiempo.
El eje vertical representa el tiempo, y en el eje horizontal se colocan los
objetos y actores participantes en la interaccin, sin un orden prefijado. Cada
objeto o actor tiene una lnea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos. El tiempo fluye de arriba abajo.
Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de
acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o
activaciones a las que se refieren.
Ejemplo.-

Diagrama de Componentes.Muestra la organizacin y las dependencias entre un conjunto de componentes.

Cubren 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
Ejemplo.-

Diagramas de Estados.Un Diagrama de Estados muestra la secuencia de estados por los que pasa un
caso de uso o un objeto a lo largo de su vida, indicando qu eventos hacen que
se pase de un estado a otro y cules son las respuestas y acciones que genera.
En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos
son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres
de los eventos. Un estado se representa como una caja redondeada con el
nombre del estado en su interior. Una transicin se representa como una flecha
desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2
compartimentos. En el primer compartimento aparece el nombre del estado. El
segundo compartimento es opcional, y en l pueden aparecer acciones de
entrada, de salida y acciones internas.
Una accin de entrada aparece en la forma entrada/accin_asociada donde
accin_asociada es el nombre de la accin que se realiza al entrar en ese
estado. Cada vez que se entra al estado por medio de una transicin la accin de
entrada se ejecuta.
Una accin de salida aparece en la forma salida/accin_asociada. Cada vez
que se sale del estado por una transicin de salida la accin de salida se
ejecuta.
Una accin interna es una accin que se ejecuta cuando se recibe un
determinado evento en ese estado, pero que no causa una transicin a
otro estado. Se indica en la forma nombre_de_evento/accin_asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida finita,
en la que hay un estado inicial de creacin y un estado final de destruccin (del
caso de uso). El estado inicial se muestra como un crculo slido y el estado
final como un crculo slido rodeado de otro crculo. En realidad, los estados
inicial y final son pseudoestados, pues un objeto no puede estar en esos
estados, pero nos sirven para saber cules son la transicin inicial y final(es).
Ejemplo.-

III. 1.-

CONCLUSION.-

En este trabajo se puede ver revisar una parte de lo que es UML, debido a que es
un tema bastante extenso, pero ms que nada sirvi de aprendizaje personal y
para introducirse ms en el tema de UML, y por qu se generaron los diagramas
que hoy en da existen y para qu sirve cada uno de ellos en especfico, y como
evoluciono la orientacin y diseo orientado al objeto para que el usuario
comprendiera con mayor claridad lo que el necesita y lo que le estaban ofreciendo.

IV. 1.-

BIBLIOGRAFIA.-

Booch G., Rumbaugh J., Jacobson I. (1999). El Lenguaje Unificado de

Modelado (pp. 53-68) Addison Wesley Iberoamericana.
Booch G. Object-Oriented Analysis and Design (1994).
Benjamin/Cummings (pp. 37-51)
Larman C. UML y Patrones (1999). Prentice Hall.
Schmuller Joseph. Aprendiendo UML en 24 horas (1997). Prentice Hall.
Ferr Grau X. (2001). Desarrollo Orientado a Objetos con UML. Extrado el
2 de Mayo de 2014 desde
http://fermat.usach.cl/~msanchez/comprimido/OBJETOS.pdf