Metodologa Orientada a

Objetos
Clave 43100007
Maestra en Sistemas Computacionales
Convenio SEP - UPAEP

Mdulo 01
Introduccin al
Unified Modeling Language (UML)
Mayo Junio, 2008

Contenido del mdulo 1

1. Introduccin al Unified Modeling Language (UML)
1.1 Vista Rpida: ADOO
1.1.1 Que es el Anlisis y Diseo?
1.1.2 Porqu analizar y disear?
1.1.3 Qu son el Anlisis y Diseo Orientado a Objetos?
1.1.4 Orientacin a Objetos
1.1.5 Como se realiza la identificacin de objetos.
1.1.6 Uso de la Orientacin a Objetos
1.2 Antecedentes de UML
1.3 Qu es UML?
1.4 Objetivos del UML
1.5 Evolucin del UML
1.6 reas conceptuales de UML

Vista Rpida
Anlisis y Diseo Orientado a Objetos
Antes de empezar con el estudio de UML como metodologa orientada a objetos,
es necesario aclarar algunos conceptos necesarios para su entendimiento, as,
empezaremos teniendo claro algunos preceptos que la anteceden; en este sentido,
sabemos que el anlisis y diseo son dos actividades fundamentales para el
desarrollo de software; esto es una introduccin al A/DOO, nos centraremos en el
dominio y comprensin de los fundamentos, de esta manera para empezar
formlese a manera de reflexin las siguientes preguntas:

Que son el anlisis y el diseo?

Para que analizar y disear?
Qu son el anlisis y el diseo orientado a objetos?
Qu significa orientacin a objetos?
Para que se usa la orientacin a objetos?

Qu son el anlisis y el diseo?

El anlisis pone nfasis en la investigacin del problema y los requisitos, en lugar
de ponerlo en la solucin. Por ejemplo si se desea un nuevo sistema de
informacin para una biblioteca; Cmo se utilizar el anlisis?
Anlisis es un termino amplio, es mas adecuado calificarlo como -Anlisis de
requisitos (un estudio de los requisitos) o Anlisis de Objetos (un estudio de los
objetos del dominio)
El diseo pone nfasis en la solucin conceptual que satisface los requisitos, en
lugar de ponerlo en la implementacin. Como en el Anlisis, en el diseo es ms
apropiado calificar el trmino como diseo de objetos.
En resumidas cuentas, en el anlisis se da respuesta al Qu, mientras que
durante el diseo se responde al Como.
Para que analizar y disear?
En resumidas cuentas, a pesar de todas las indicaciones de los procesos de
desarrollo de software, usted y yo sabemos que la cuestin fundamental e
importante del desarrollo del software es la escritura de cdigo. Despus de todo,
los diagramas son slo imgenes bonitas. Ningn usuario va a agradecer la belleza
de los dibujos, lo que el usuario quiere es software que funcione; entonces para
que analizar y disear.

Por tanto, ahora que esta considerando usar UML, es importante preguntarse
porque lo har y como le ayudar a usted en el momento de escribir el cdigo. No
existe una evidencia emprica adecuada que demuestre que estas tcnicas son
buenas o malas.
Son muchos los beneficios logrados con estas actividades cuando se trata de
desarrollar software, en contrapunto con la curva de aprendizaje asociada a la OO;
no es difcil aprender a programar en un lenguaje OO; el problema es que es
necesario cierto tiempo para aprovecha sus ventajas. Como dice Tom Hadfield: los
leguajes OO permiten ventajas pero no las proporcionan; para aprovechar estas
ventajas hay que realizar el infame cambio de paradigma.
Qu son el anlisis y el diseo orientado a objetos?
Durante el anlisis orientado a objetos se presta especial atencin en encontrar y
describir los objetos en el dominio del problema. Por ejemplo en el sistema de
informacin de una biblioteca algunos de los conceptos objetos- con libros,
biblioteca, socio.
El proceso de anlisis para identificar objetos y clases de stos es una de las reas
ms difciles en el desarrollo OO; este proceso comprende el desarrollo de un
modelo OO del dominio de la aplicacin. Los objetos identificados reflejan las
entidades y operaciones que se asocian con el problema a resolver.
Sin importar el ciclo de vida, un desarrollo OO requiere varios pasos para describir
requerimientos, disear el sistema, codificar y probar. El anlisis de requerimientos
OO es usualmente hecho en lenguaje natural e incluye los conceptos y escenarios
que tiene que ver con el dominio de la aplicacin. Los conceptos incluyen
informacin, servicios y responsabilidades. El conocimiento del dominio hace que
los desarrolladores entiendan el contexto en el cual el sistema ser usado y
describe los requerimientos en la manera que el usuario los entender; en este
sentido, esta expresin de los requerimientos ser la misma, sin importar como los
desarrolladores decidan implementar el sistema.
Durante el diseo orientado a objetos se presta especial atencin a la definicin de
los objetos de software, y en como colaboran para satisfacer los requisitos. Por
ejemplo en el sistema de la biblioteca, un objeto software libro podra tener un
atributo titulo y un mtodo obtenerCapitulo.
El proceso de diseo OO comprende la creacin de clases de objetos y las
relaciones entre estas clases; este proceso comprende el desarrollo de un modelo
OO de un sistema de software para implementar los requisitos identificados. Los
objetos del diseo OO estn relacionados con la solucin del problema a resolver.

Hay dos lneas gua que aplicar para representar el diseo de un sistema OO.
Primera, es importante identificar y representar clases y objetos. Debemos conocer
no solo los objetos del mundo real del dominio de la aplicacin, tambin los
detalles de los atributos y comportamiento de los objetos. Segunda. Debemos
identificar las interacciones y relaciones de los objetos y clases: Sus asociaciones,
composiciones, agregaciones y relaciones inherentes.

Programacin Orientada a Objetos Se refiere a llevar a cabo el diseo de

software utilizando un lenguaje de programacin orientado a objetos. Un lenguaje
de este tipo, permite la implementacin directa de los objetos y suministra
recursos para definir las clases de objetos.
Qu significa Orientacin a Objetos?
Es fundamental que comprenda todo lo relacionado a la orientacin a objetos para
el proceso que realizar, especficamente es importante que conozca algunos
conceptos clave sobre la orientacin a objetos. Estos conceptos son:

Abstraccin
Herencia
Polimorfismo
Encapsulamiento
Envo de mensajes
Asociaciones
Agregacin

La OO es un paradigma que depende de ciertos principios fundamentales, en las

siguientes lneas veremos dichos principios que hacen funcionar a los objetos y
como utilizarlos para hacer el anlisis y diseo.
El mundo esta lleno de objetos, mire a su alrededor y vera objetos por doquier,
incluso usted y yo somos un objeto en este mundo. Los sistemas tratan de simular
los objetos (o al menos parte de estos) mediante el software; as pues,
definiremos un objeto como la instancia de una clase (o categora); de esta
manera usted y yo somos instancia de la clase persona.
Objeto: Es una entidad que tiene un estado y un conjunto de operaciones
definidas que operan sobre este estado. Es estado representa un conjunto
de atributos del objeto. Las operaciones que son asociadas con el objeto
proveen servicios a otros objetos que solicitan estos servicios cuando se
requiere llevar a cabo algn clculo.

En este sentido, un objeto cuenta con una estructura, es decir atributos

(propiedades) y acciones; las acciones son todas las actividades que el objeto es
capaz de realizar. Como objetos de la clase persona, usted y yo contamos con los
siguientes atributos: altura, peso, edad y mucho otros; adems de las siguientes
acciones: comer, leer, escribir, hablar, trabajar, etctera.
En el mundo de la orientacin a objetos, una clase tiene otro propsito adems de
la categorizacin, es en realidad una plantilla para crear objetos (algunos dicen
que es lo mismo, pero evitaremos ese debate).
Es importante que recuerde que el propsito de la orientacin a objetos es
desarrollar software que refleje particularmente un esquema del mundo. Entre
mas atributos y acciones tome en cuenta, mayor ser la similitud de sus software
con la realidad.
Cmo realizar la identificacin de Objetos?
No hay una formula mgica para realizar la identificacin de objetos, usualmente
se basa en la experiencia y el conocimiento del dominio de los diseadores; sin
embargo, se presentan algunos puntos que le ayudarn sustancialmente a realizar
esta tarea.
1. Utilizar un anlisis gramatical de la descripcin en lenguaje natural de un
sistema. Los objetos y los atributos son sustantivos, las operaciones o
servicios son verbos. (Enfoque del mtodo HOOD, Robinson, 1992)
2. Utilizar entidades tangibles (cosas) en el domino de la aplicacin como
aviones; papeles como administrador; eventos como una peticin;
interacciones como reuniones; ubicaciones como oficinas; unidades
organizacionales como compaas. Esto debe complementarse identificando
estructuras de almacenamiento (estructuras de datos abstractos) en el
dominio de la solucin, las cuales podran requerirse para apoyar a estos
objetos. (Coad y Yourdon, 1990)
3. Utilizar un enfoque de comportamiento en el cual el diseador, primero
comprende el comportamiento total del sistema. Los diversos
comportamientos se asignan a distintas partes del sistema para as
comprender quien inicia y participa en esos comportamientos. Los
participantes que juegan papeles importantes se identifican como objetos.
(Rubin y Goldberg, 1992)
4. Utilizar un anlisis basado en escenarios en el cual se identifican y analizan
en su momento varios escenarios de la forma de utilizar el sistema. Puesto
que cada escenario se analiza, el equipo responsable del anlisis debe de
identificar los objetos, atributos y operaciones requeridas. (Beck y
Cunningham, 1989).

La OO refiere adems de atributos y acciones, otros aspectos importantes como

son abstraccin, herencia, polimorfismo y encapsulamiento; adems de las
asociaciones y la agregacin.
Abstraccin Se refiere a quitar las propiedades y acciones de un objeto y dejar
solo las necesarias; se puede definir como la extraccin de las propiedades
esenciales de un concepto.
Herencia Como ya dijimos un objeto es la instancia de una clase, esta accin de
inicio tiene una consecuencia importante, que el objeto tiene todas las
caractersticas de la clase de la que proviene, ha esto se le conoce como herencia.
Adems un objeto no solo hereda de la clase de una clase, si no que una clase
tambin puede heredar de otra clase.
Polimorfismo Como sabemos las clases tienen atributos y operaciones; en
ocasiones las operaciones tiene el mismo nombre en diferentes clases; en la OO
cada clase Sabe como realizar tal operacin.
En sentido literal, polimorfismo significa la capacidad de tener ms de una forma,
en esencia se refiere al hecho que una misma operacin puede tener diferente
comportamiento en diferentes objetos; en otras palabras, diferentes objetos
reaccionan al mismo mensaje de modo diferente.
Encapsulamiento la esencia del encapsulamiento es que cuando un objeto trae
consigo su funcionalidad, esta ltima se oculta. Cul es la importancia de esto?,
en el software este principio permite el reducir el potencial de errores que se
pueden ocurrir. En un sistema que consta de objetos, stos dependen unos de
otros en diversas formas; si uno de ellos falla y los especialistas en software tienen
que modificarlo de alguna forma, el ocultar sus operaciones de otros objetos,
significar que tal vez no sea necesario modificar los dems objetos.
Envo de mensajes En un sistema los objetos trabajan en conjunto, esto se
logra mediante el envo de mensajes entre ellos, un objeto enva a otro un
mensaje para realizar una operacin y el objeto receptor ejecutar la operacin.
Asociaciones Otro principio del paradigma OO, es que los objetos se relacionan
entre s de alguna forma.
La multiplicidad es un aspecto importante de las asociaciones entre objetos. Indica
la cantidad de objetos de una clase que se relacionan con otro objeto en particular
de la clase asociada.
Agregacin Un tipo de agregacin trae consigo una estrecha relacin entre un
objeto agregado y sus objetos componentes, a esto se le conoce como

composicin, el punto central de la composicin es que el componente se

considera como tal slo como parte del objeto compuesto.
La agregacin y la composicin son importantes dado que reflejan casos
extremadamente comunes, y ello ayuda a que se creen modelos que se asemejen
considerablemente a la realidad.
Uso de la Orientacin a Objetos
Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad
de los sistemas. Para modelarlos necesitar comprender lo que son las
asociaciones, si esta conciente de los posibles tipos de asociaciones, tendr una
amplia gama de posibilidades cuando hable con los clientes respecto a sus
necesidades, estar en condiciones de obtener sus requerimientos y crear los
modelos de los sistemas que le ayudarn a cumplir los retos del negocio.
Lo importante es utilizar los conceptos de la Orientacin a Objetos para ayudarle a
comprender el rea de conocimiento de su cliente (su dominio), y establecer sus
puntos de vista al cliente en trminos que el o ella puedan comprender.
Es all donde se aplica el UML.

UML
Antecedentes
Inicialmente surgieron los LOO (lenguajes Orientados a Objetos), el primero
reconocido como tal es SIMULA 67, desarrollado en 1967; aunque no tuvo un
seguimiento significativo influyo en desarrollos posteriores de LOO, como Smalltalk
a principios de los 80s, adems de Objective C, C++, Eiffel y CLOS; el uso de
dichos lenguajes fue limitado, pero lo que mas atrajo la atencin fue el Paradigma
OO surgiendo as los primeros mtodos de desarrollo OO.
Aparecieron muchos libros de MOO, cada uno con su propio conjunto de
conceptos, definiciones, notacin, terminologa y procesos; pero en general hubo
gran similitud ente los conceptos propuestos por los diferentes autores. Todos los
mtodos eran similares, sin embargo, tenan entre s una gran cantidad de
diferencias menores, con frecuencia muy incmodas. Los mismos conceptos
bsicos aprecian con denominaciones muy diferentes, lo cual confunda a los
clientes y desarrolladores.

Metodologas OO
-

Booch (OOAD)
CASEIode (CCM)
Coad-Yourdon- Nicola (OOA,OOD)
NE University (Demeter)
Object Engin. (Fresco)
HP Coleman94 (Fusion)
Graham (SOMA)
Texas Instruments (IE\O)
ICL (MTD)
ParcPlace (OBA)
Jacobson (OOSE)

Olivetti (OGROUP)
Martin-Odell (OOIE)
TASKON (OORAM)
Winter (OSMOSYS)
Rumbaugh (OMT)
LBMS (SE/OT)
Shlaer/Mellor (OOSA)
CCTA (SSADM)
Wirfs-Brock (RDD)
Lloyds Register (Z++)

Evidentemente surgi la imperiosa necesidad de unificar la maremagum de

mtodos existentes; el primer intento exitoso de combatir y reemplazar los
mtodos existentes lleg cuando Rumbaugh se uni a Booch en racional Software
Corporation en 1994; ellos empezaron a combinar sus mtodos (Booch, OMTObject Modeling Technique), resultando una primera propuesta en 1995; en este
momento, Ivar Jacovson tambin se uni a Rational dejando General Electric;
trabajando conjuntamente con Rumbaugh y Booch con al intencin de unificar sus
mtodos y crear el Lenguaje Unificado de Modelado.
Este esfuerzo de los autores de tres prestigiados mtodos, inclin favorablemente
la balanza en el campo de la MOO; desde entonces UML se considera como el
sucesor de la oleada de mtodos de A/DOO que surgi a finales de los 80s y
principios de los 90s.
Decimos pues que el UML es un lenguaje de modelado, y no un mtodo. La mayor
parte de los mtodos consisten, al menos en principio, en un lenguaje y en
proceso para modelar. El UML es una notacin (principalmente grfica), de que se
valen los mtodos para expresar los diseos. El proceso es la orientacin que nos
dan sobre los pasos a seguir para hacer el diseo. Si usted desea analizar un
diseo con alguien, lo que ambos necesitan comprender es el lenguaje de
modelado, no el proceso que usted sigui para lograr el diseo.
UML no es A/DOO o un mtodo para entenderlo, es simplemente una notacin. No
es tan til aprender a hacer diagramas UML sintcticamente correctos (una
herramienta CASE podra ayudarle a eso), si no es capaz de crear un diseo
excelente o evaluar y mejorar uno existente. Esta es la habilidad ms difcil y
valiosa.

Como ya se mencion, la unin de los creadores de las metodologas Booch94,

OMT y OOSE (Grady Boochy , James Rumbaugh y Ivar Jacobson ), conocidos
como los tres amigos, dio origen a UML; cuya primera versin 1.1, se present
para su estandarizacin en 1997 a la OMG ( Object Management Group) y fue
aceptada unnimemente.
La creacin de UML, se debi inicialmente a los tres amigos, ellos iniciaron el
esfuerzo, pero muchos ayudaron a llevarlo a una conclusin exitosa; el resultado
es una norma construida sobre las muchas ideas y contribuciones de muchos
individuos y compaas de la comunidad OO.
UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran nmero
mtodos de desarrollo orientado a objetos que haban surgido (y terminar as con
la guerra de los mtodos).
La construccin de modelos, al igual que se emplea en otras reas de la ingeniera,
hace que los usuarios entienda la realidad de la tecnologa y la posibilidad de que
reflexione antes de invertir y gastar grandes cantidades en proyectos que no estn
seguros en su desarrollo, reduciendo costos y el tiempo empelado en la
construccin de las piezas que construirn dicho modelo.
Qu es UML? (Lenguaje Unificado de Modelado)

UML es un lenguaje de modelado visual, que se usa para especificar,

visualizar, construir y documentar artefactos de un sistema de software.
Esta pensado para usarse con todos los mtodos de desarrollo, etapas del
ciclo de vida, dominio de la aplicacin y medios.
La especificacin del UML no define un proceso estndar, pero esta pensado
para ser til en un proceso de desarrollo iterativo; pretende dar apoyo a la
mayora de los procesos de desarrollo orientado a objetos.
UML capta la informacin sobre las estructuras estticas y dinmicas de un
sistema; las primeras definen los tipos de objetos importantes para un
sistema y para su implementacin, as como las relaciones entre los objetos;
las segundas definen la historia de los objetos en el tiempo y la
comunicacin entre los objetos para cumplir con los objetivos.

Objetivos del UML

1. El primero y ms importante, UML es un lenguaje de modelado de
propsito general que pueden usar todos los modeladores.
2. UML, no tiene propietario y esta basado en el comn acuerdo de gran
parte de la comunidad informtica.

10

3. Esta pensado para reemplazar al menos los modelos OMT, Booch,

Objectory y otros mtodo importantes.
4. Pretende abordar los problemas actuales del desarrollo de software,
tales como el tamao, distribucin, concurrencia, patrones y desarrollo
en equipo.
5. UML no pretende ser un mtodo de desarrollo completo. No incluye un
proceso de desarrollo paso a paso. Es importante darse cuenta que UML
y el proceso para usarlo son dos cosas independientes.
El objetivo final de UML era ser tan simple como fuera posible pero manteniendo la
capacidad de modelar toda la gama de sistemas que se necesitan construir.
UML es un lenguaje para modelar sistemas de informacin, y su objetivo
fundamental es lograr modelos que, adems de describir con cierto grado de
formalismo tales sistemas, pueden ser entendidos por los clientes o usuarios de
aquello que se modela.
Sin importar el proceso, no olvide que puede emplearse cualquier proceso con el
UML. El UML es independiente del proceso, es libre de elegir el mas adecuado par
su proyecto; se cual fuere el proceso con el que trabaje; el UML pude servirle par
registrar las decisiones de anlisis y diseo que resulten.
Por otra parte, distintos factores relacionados con el desarrollo de software
conducen necesariamente a diferentes tipos de procesos. Entre estos factores se
incluyen el tipo de software que se esta desarrollando (tiempo real, sistema de
informacin, producto de computadora de escritorio), la escala (un solo
desarrollador, un solo equipo, un equipo de mas de 100 miembros), entre muchos
otros factores.

11

Evolucin del UML

reas conceptuales del UML

Estructura esttica
Cualquier modelo define los conceptos clave de la aplicacin, sus propiedades
internas y las relaciones entre cada uno de estos; estos conceptos son modelados de
clases, que categorizar un conjunto de objetos que almacenan informacin y se
comunican para implementar un comportamiento. La informacin que almacenan
se modela con atributos y el comportamiento con operaciones.
- Si las clases comparten informacin se puede modelar con la generalizacin.
- Las relaciones objeto a objeto se pueden modelar con asociaciones,
dependencias.
La vista esttica del modelo se expresa con diagramas de clases y pueden usarse
para generar la mayora de las declaraciones de estructuras de datos en un
programa.

12

Comportamiento dinmico
Hay dos formas de modelar el comportamiento. Una es mediante la historia de la
vida de un objeto y otra son los patrones de comunicacin de un conjunto de
objetos, que muestra como interactan para implementar un comportamiento.
-

La visin de un objeto aislado es una maquina de estados como responde

a los eventos en funcin de su estado actual- , esto se representa mediante
un diagrama de estados.
La visin de interaccin de los objetos de un sistema es una colaboracin,
que se realiza mediante el flujo de mensajes entre stos; esto se representa
mediante los diagramas de secuencia y colaboracin.

Construcciones de implementacin
UML ofrece modelos que tiene significado para el anlisis lgico y para la
implementacin fsica. Un nodo es un recurso computacional que define una
localizacin durante la ejecucin del sistema, pueden contener componentes y
objetos. La vista de despliegue describe la configuracin de los nodos de un sistema
en ejecucin y la organizacin de los componentes y objetos en l.

Organizacin del modelo

Cuando los modelos son muy grandes, la organizacin del modelo debe ser
dividida en piezas coherentes, en UML se puede desarrollar un modelo de
paquetes de tamao modesto; donde los paquetes son unidades organizativas,
jerrquicas y de propsito general, que pueden usarse para el almacenamiento,
control de acceso, gestin de la configuracin y construccin de bibliotecas.
Incluso puede modelarse la dependencia entre paquetes.

Mecanismos de extensin
No importa que tan basto sea un lenguaje, siempre se querrn hacer extensiones;
dichas extensiones en UML se realizan mediante los estereotipos, sin que haya un
cambio en el leguaje bsico. Un estereotipo es una nueva clase de elemento de
modelado con la misma estructura de un elemento existente pero con restricciones
adicionales.

13

Conceptos de UML
rea
Estructural

Dinmica

Gestin de
modelo
Extensin de
UML

Vista
Vista esttica

Diagramas
diagramas de clases

Vista de casos de uso

diagramas de casos de
uso

Vista de
implementacin
Vista de despliegue

diagramas de
comportamiento
diagrama de despliegue

Vista de maquina de
estados
Vista de actividad

diagrama de estados

Vista de interaccin

diagrama de secuencia

Vista de gestin de
modelos
Todas

diagrama de actividad

diagrama de
colaboracin
diagrama de clases
Todos

Conceptos Principales
Clase, asociacin,
generalizacin, realizacin,
interfaz.
Caso de uso, actor,
asociacin, extensin,
inclusin, generalizacin de
casos de uso.
Componente, interfaz,
dependencia, realizacin.
Nodo, componente,
dependencia, localizacin.
Estado, evento, transicin,
accin.
Estado, actividad, transicin
de terminacin, divisin,
unin.
Interaccin, objeto, mensajes,
activacin.
Colaboracin, interaccin, rol
de colaboracin, mensaje.
Paquete, subsistema, modelo
Restriccin, estereotipo,
valores etiquetados.

Una vista es simplemente un subconjunto de UML que modela construcciones que

representan un aspecto de un sistema; uno o dos clases de diagramas
proporcionan una notacin visual para los conceptos de cada vista.
Vista esttica
La vista esttica modela los conceptos del dominio de la aplicacin, as como los
conceptos internos inventados como parte de la implementacin de la aplicacin.
Esta visin es esttica porque no describe el comportamiento del sistema a travs
del tiempo, los componentes principales de esta vista son las clases y sus
relaciones; la visin esttica se exhibe en los diagramas de clases.
Vista de casos de uso
Esta vista modela la funcionalidad del sistema segn lo perciben los usuarios
externos, llamados actores. Un caso de uso es una unidad coherente de
funcionalidad, expresada como transaccin entre actores y el sistema. Su propsito

14

es enumerar a los actores y los casos de uso, y demostrar qu actores participan

en cada caso de uso.
Vista de interaccin
Esta vista describe secuencias de intercambios de mensajes entre los roles que
implementan en comportamiento del sistema. El rol es la descripcin de un objeto,
que desempea un determinado papel dentro de una interaccin. Esta vista se
exhibe en dos diagramas: Secuencias y Colaboracin.
Vista de maquina de estados
Esta vista modela las posibles historias de vida de un objeto de una clase. Una
maquina de estado contiene los estados conectados por transiciones. Cada estado
modela un periodo de tiempo, durante la vida del objeto, en el que satisface
ciertas condiciones. Cuando ocurre un evento se puede desencadenar una
transicin que lleve al objeto a un nuevo estado. Esta vista se exhibe con el
diagrama de estados.
Vista de actividades
Es una variante de una maquina de estados, que muestra las actividades de
computacin implicadas en la ejecucin de un clculo. Un estado de actividad
representa una actividad: un paso en el flujo de trabajo o la ejecucin de una
operacin. Esta vista se muestra con el diagrama de actividades.
Vista fsica
Esta vista modela la estructura de la implementacin de la aplicacin por si misma,
su organizacin en componentes, y su despliegue en nodos de ejecucin. Hay dos
visitas fsicas: Vista de implementacin y Vista de despliegue.
La primera modela los componentes de un sistema a partir de los cuales se
construye la aplicacin as como las dependencias de los componentes, para
poder determinar el impacto de un cambio propuesto; esta vista de presenta con
el diagrama de componentes.
La segunda representa la disposicin de las instancias de los componentes de
ejecucin en instancias de nodos. Un nodo es un recurso de ejecucin tal como
una computadora, un dispositivo, una memoria. Esta vista permite determinar las
consecuencias de la distribucin y la asignacin de recursos; esta vista se
representa con el diagrama de despliegue.

15

Vista de gestin del modelo

Esta vista modela la organizacin del modelo en si mismo, un modelo abarca un
conjunto de paquetes que contienen las elementos del modelo, tales como clases,
maquinas de estado y casos de uso. Los paquetes son unidades para manipular el
contenido de un modelo.
Construccin de extensiones
UML tiene tres construcciones bsicas de extensin: restricciones, estereotipos y
valores etiquetados. Un restriccin es una declaracin textual de una relacin
semntica expresada en un cierto lenguaje formal o en lenguaje natural. Un
estereotipo es una nueva clase de elemento del modelo, ideada por el modelador,
y basada en un tipo existente de elemento modelo. Un valor etiquetado es una
porcin de informacin con nombre, unida a cualquier elemento del modelo.
Pueden ser utilizadas para crear versiones adaptadas en un rea particular de
aplicacin.
Ahora que conoce la importancia que tiene el A/DOO en la construccin de
software, lo que motivo y dio origen al UML, que sabe un poco de sus creadores,
los conceptos principales que maneja y las vistas que considera para realizar el
modelado de un sistema, comenzaremos a estudiar su notacin; y a comprender la
importancia que tiene el UML cuando se realizar la difcil tarea de A/DOO.

Diagramas de UML
La siguiente seccin muestra una descripcin general de los diversos diagramas de
UML; incluyendo los 3 diagramas de la versin 2.0; en las sesiones siguientes
abordaremos los diagramas ms usados y conoceremos su notacin; para que
mediante diversos ejemplos prcticos veamos su uso.
Estructura
1. Diagrama de Paquetes: En un diagrama que muestra como un sistema
est dividido en agrupaciones lgicas mostrando las dependencias entre
esas agrupaciones.
2. Diagrama de Clases: Describe la estructura de un sistema mostrando sus
clases, atributos y las relaciones entre ellos. Los diagramas de clases son
utilizados durante el proceso de anlisis y diseo de los sistemas
informticos, donde se crea el diseo conceptual de la informacin que se
manejar en el sistema, y la relacin entre uno y otro.

16

3. Diagrama de Objetos: Son 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 no muestran la
multiplicidad ni los roles, aunque su notacin es similar a los diagramas de
clase.
4. Diagrama de estructura compuesta (2.0): Muestra la estructura
interna de un clasificador, incluyendo sus puntos de la interaccin a otras
partes del sistema. Los elementos de la clase se han descrito en detalle en
la seccin en diagramas de la clase. Esta seccin describe la manera en que
las clases se pueden exhibir como elementos compuestos que exponen
interfaces y contienen puertos y piezas.
5. Diagrama de componentes: Muestra las piezas de software,
controladores embebidos, etc., que compondrn un sistema. Un diagrama
de componentes muestra un nivel de abstraccin mas alto que un diagrama
de la clase usualmente un componente es implementado por unas o ms
clases (u objetos) en tiempo de ejecucin-.
6. Diagrama de despliegue: Muestra la configuracin de los elementos del
hardware (nodos) y muestras como los elementos de software son
mapeados en esos nodos.
Comportamiento
7. Diagrama de casos de uso: El modelo del caso del uso captura los
requisitos de un sistema. Los casos del uso son un medio que comunica a
los usuarios y otros stakehoolders lo que el sistema intenta hacer.
8. Diagrama de actividad: Muestra un flujo de trabajo (mediante una
secuencia de actividades) desde un punto de inicio hasta un punto final,
detallando las trayectorias de decisin que existen. Son tiles para el
modelado del negocio, donde se detallan los procesos involucrados en las
actividades del negocio.
9. Diagrama de maquina de estados: Modela el comportamiento de un
solo objeto, especificando la secuencia de estados que un objeto tiene en su
tiempo de vida, en respuesta a eventos.
Interaccin
10. Diagrama de colaboracin: Es un diagrama colaboracin que muestra
informacin similar al diagrama de secuencia, pero su enfoque primario es
mostrar las relaciones de los objetos, si considerar el tiempo. Tambin es
conocido como diagrama de comunicacin.
11. Diagrama de secuencias: El diagrama de secuencia es uno de los
diagramas ms efectivos para modelar interaccin entre objetos en un
sistema. Un diagrama de secuencia muestra la interaccin de un conjunto

17

de objetos en una aplicacin a travs del tiempo y se modela para cada

caso de uso.
12. Diagrama de tiempos (2.0): Muestran los cambios en el estado o valor
de uno o ms elementos en el tiempo. Tambin, pueden mostrar la
interaccin para la sincronizacin de eventos. su duracin contra las
restricciones de tiempo .
13. Diagrama de interaccin (2.0): Es un tipo de diagrama de actividad, en
la cual los nodos representan diagramas de interaccin. Los diagramas de
interaccin, pueden incluir diagramas secuencia, de colaboracin, de
interaccin y de tiempo. Los diagramas de interaccin introducen dos
nuevos elementos: ocurrencias en la interaccin y elementos de la
interaccin.

18

Bibliografa
1. Shari Lawrence Pfleeger, Joanne M. Atlee Software Engineering ,Theory and
Practice, Thrid Edition, Pearson, Prentice Hall
2. Craig Larman, UML y Patrones, Una introduccin al anlisis y diseo orientado a
objetos y al proceso unificado, Segunda Edicin, Pearson, Prentice Hall.
3. Eric j. Fraude, Ingeniera de Software, Una perspectiva orientada a objetos,
Alfaomega.
4. James Rumbaugh, Ivar Jacobson y Grady Booch, El lenguaje Unificado de
Modelado, Manual de Referencia, Addison Wesley
5. Martin Flower con Kendall, UML gota a gota, Pearson Addison Wesley
6. Ian Sommerville, Ingeniera de Software, Sexta Edicin, Addison Wesley, 2002,
ISBN:970-26-0206-8.
7. Joseph Schmuller, Apendiendo UML en 24 horas, Prentice may

Nota
El contenido de este documento fue recopilado por el catedrtico de las diversas
fuentes bibliogrficas detalladas en la seccin anterior; si detecta que algn contenido
no esta referenciado en las fuentes sealadas, mucho le agradecer enve la
observacin a josejuan.avina@gmail.com (An se sigue trabajando en la
especificacin puntual de cada referencia)

19