La presente, es una antologa compuesta por materiales de

diferentes autores que nos servirn para ir viendo los temas de la

unidad 1, se complementarn con lo visto en clase y con ejercicios
y tareas que se encontrarn en la plataforma de Mooddle.
Tecnologa orientada a objetos
Hoy en da la tecnologa orientada a objetos ya no se aplica
solamente a los lenguajes de programacin, adems se viene
aplicando en el anlisis y diseo con mucho xito, al igual que en las
bases de datos. Es que para hacer una buena programacin
orientada a objetos hay que desarrollar todo el sistema aplicando
esta tecnologa, de ah la importancia del anlisis y el diseo
orientado a objetos.
La programacin orientada a objetos es una de las formas ms
populares de programar y viene teniendo gran acogida en el
desarrollo de proyectos de software desde los ltimos aos. Esta
acogida se debe a sus grandes capacidades y ventajas frente a las
antiguas formas de programar.
Una Perspectiva Histrica
Tradicionalmente, la programacin fue hecha en una manera
secuencial o lineal, es decir una serie de pasos consecutivos con
estructuras consecutivas y bifurcaciones.

Los lenguajes basados en esta forma de programacin ofrecan

ventajas al principio, pero el problema ocurre cuando los sistemas
se vuelven complejos. Estos programas escritos al estilo
espaguetti no ofrecen flexibilidad y el mantener una gran
cantidad de lneas de cdigo en slo bloque se vuelve una tarea
complicada.
Frente a esta dificultad aparecieron los lenguajes basados en la
programacin estructurada. La idea principal de esta forma de
programacin es separar las partes complejas del programa en
mdulos o segmentos que sean ejecutados conforme se requieran.
De esta manera tenemos un diseo modular, compuesto por
mdulos independientes que puedan comunicarse entre s. Poco a
poco este estilo de programacin fue reemplazando al estilo
espaguetti impuesto por la programacin lineal.
Entonces, vemos que la evolucin que se fue dando en la
programacin se orientaba siempre a ir descomponiendo ms el
programa. Este tipo de descomposicin conduce directamente a la
programacin orientada a objetos.

Pues la creciente tendencia de crear programas cada vez ms

grandes y complejos llev a los desarrolladores a crear una nueva
forma de programar que les permita crear sistemas de niveles
empresariales y con reglas de negocios muy complejas. Para estas
necesidades ya no bastaba la programacin estructurada ni mucho
menos la programacin lineal. Es as como aparece la programacin
orientada a objetos (POO). La POO viene de la evolucin de la
programacin estructurada; bsicamente la POO simplifica la
programacin con la nueva filosofa y nuevos conceptos que tiene.
La POO se basa en la dividir el programa en pequeas unidades
lgicas de cdigo. A estas pequeas unidades lgicas de cdigo se
les llama objetos. Los objetos son unidades independientes que se
comunican entre ellos mediante mensajes. Veamos con mayor
detenimiento este tema.
Cules son las ventajas de un lenguaje orientado a objetos?
Fomenta la reutilizacin y extensin del cdigo.
Permite crear sistemas ms complejos.
Relacionar el sistema al mundo real.
Facilita la creacin de programas visuales.
Construccin de prototipos
Agiliza el desarrollo de software
Facilita el trabajo en equipo
Facilita el mantenimiento del software
Lo interesante de la POO es que proporciona conceptos y
herramientas con las cuales se modela y representa el mundo real
tan fielmente como sea posible.
El modelo Orientado a Objetos
Para entender este modelo vamos a revisar 4 conceptos bsicos:

Objetos
Clases
Herencia
Envo de mensajes

1. Objetos
Entender que es un objeto es la clave para entender cualquier
lenguaje orientado a objetos.
Existen muchas definiciones que se le ha dado al Objeto. Primero
empecemos entendiendo que es un objeto del mundo real. Un
objeto del mundo real es cualquier cosa que vemos a nuestro
alrededor. Digamos que para leer este artculo lo hacemos a travs
del monitor y una computadora, ambos son objetos, al igual que
nuestro telfono celular, un rbol o un automvil.
Analicemos un poco ms a un objeto del mundo real, como la
computadora. No necesitamos ser expertos en hardware para
saber que una computadora est compuesta internamente por
varios componentes: la tarjeta madre, el chip del procesador, un
disco duro, una tarjeta de video, y otras partes ms. El trabajo en
conjunto de todos estos componentes hace operar a una
computadora.
Internamente, cada uno de estos componentes puede ser
sumamente complicado y puede ser fabricado por diversas
compaas con diversos mtodos de diseo. Pero nosotros no
necesitamos saber cmo trabajan cada uno de estos componentes,
como saber que hace cada uno de los chips de la tarjeta madre, o
cmo funciona internamente el procesador. Cada componente es

una unidad autnoma, y todo lo que necesitamos saber de adentro

es cmo interactan entre s los componentes, saber por ejemplo si
el procesador y las memorias son compatibles con la tarjeta madre,
o conocer donde se coloca la tarjeta de video. Cuando conocemos
como interaccionan los componentes entre s, podremos armar
fcilmente una computadora.
Que tiene que ver esto con la programacin? La programacin
orientada a objetos trabaja de esta manera. Todo el programa est
construido en base a diferentes componentes (Objetos), cada uno
tiene un rol especfico en el programa y todos los componentes
pueden comunicarse entre ellos de formas predefinidas.
Todo objeto del mundo real tiene 2 componentes: caractersticas y
comportamiento.
Por ejemplo, los automviles tienen caractersticas (marca, modelo,
color, velocidad mxima, etc.) y comportamiento (frenar, acelerar,
retroceder, llenar combustible, cambiar llantas, etc.).
Los Objetos de Software, al igual que los objetos del mundo real,
tambin tienen caractersticas y comportamientos. Un objeto de
software mantiene sus caractersticas en una o ms "variables", e
implementa su comportamiento con "mtodos". Un mtodo es una
funcin o subrutina asociada a un objeto.

Para redondear estas ideas, imaginemos que tenemos estacionado

en nuestra cochera un Ford Focus color azul que corre hasta 260
km/h. Si pasamos ese objeto del mundo real al mundo del
software, tendremos un objeto Automvil con sus caractersticas
predeterminadas:
Marca
Modelo
Color
Velocidad Mxima = 260 km/h

=
=
=

Ford
Focus
Azul

Cuando a las caractersticas del objeto le ponemos valores decimos

que el objeto tiene estados. Las variables almacenan los estados de
un objeto en un determinado momento.
Definicin terica: Un objeto es una unidad de cdigo compuesto
de variables y mtodos relacionados.
2. Las Clases
En el mundo real, normalmente tenemos muchos objetos del
mismo tipo. Por ejemplo, nuestro telfono celular es slo uno de
los miles que hay en el mundo. Si hablamos en trminos de la
programacin orientada a objetos, podemos decir que nuestro
objeto celular es una instancia de una clase conocida como
"celular". Los celulares tienen caractersticas (marca, modelo,
sistema operativo, pantalla, teclado, etc.) y comportamientos
(hacer y recibir llamadas, enviar mensajes multimedia, transmisin
de datos, etc.).

Cuando se fabrican los celulares, los fabricantes aprovechan el

hecho de que los celulares comparten esas caractersticas comunes
y construyen modelos o plantillas comunes, para que a partir de
esas se puedan crear muchos equipos celulares del mismo modelo.
A ese modelo o plantilla le llamamos CLASE, y a los equipos que
sacamos a partir de ella la llamamos OBJETOS.

Esto mismo se aplica a los objetos de software, se puede tener

muchos objetos del mismo tipo y mismas caractersticas.
Definicin terica: La clase es un modelo o prototipo que define las
variables y mtodos comunes a todos los objetos de cierta clase.
Tambin se puede decir que una clase es una plantilla genrica para
un conjunto de objetos de similares caractersticas.
Por otro lado, una instancia de una clase es otra forma de llamar a
un objeto. En realidad no existe diferencia entre un objeto y una

instancia. Slo que el objeto es un trmino ms general, pero los

objetos y las instancias son ambas representacin de una clase.
Definicin Terica: Una instancia es un objeto de una clase en
particular.
3. Herencia
La herencia es uno de los conceptos ms cruciales en la POO. La
herencia bsicamente consiste en que una clase puede heredar sus
variables y mtodos a varias subclases (la clase que hereda es
llamada superclase o clase padre). Esto significa que una subclase,
aparte de los atributos y mtodos propios, tiene incorporados los
atributos y mtodos heredados de la superclase. De esta manera se
crea una jerarqua de herencia.
Por ejemplo, imaginemos que estamos haciendo el anlisis de un
Sistema para una tienda que vende y repara equipos celulares.

En el grfico vemos 2 Clases ms que posiblemente necesitemos

para crear nuestro Sistema. Esas 2 Clases nuevas se construirn a

partir de la Clase Celular existente. De esa forma utilizamos el

comportamiento de la SuperClase.
En general, podemos tener una gran jerarqua de Clases tal y como
vemos en el siguiente grfico:

4. Envo de Mensajes
Un objeto es intil si est aislado. El medio empleado para que un
objeto interacte con otro son los mensajes. Hablando en trminos
un poco ms tcnicos, los mensajes son invocaciones a los mtodos
de los objetos.
Caractersticas asociadas al POO
Abstraccin
La abstraccin consiste en captar las caractersticas esenciales de
un objeto, as como su comportamiento. Por ejemplo, volvamos al
ejemplo de los automviles, Qu caractersticas podemos abstraer
de los automviles? O lo que es lo mismo Qu caractersticas
semejantes tienen todos los automviles? Todos tendrn una
marca, un modelo, nmero de chasis, peso, llantas, puertas,

ventanas, etc. Y en cuanto a su comportamiento todos los

automviles podrn acelerar, frenar, retroceder, etc.
En los lenguajes de programacin orientada a objetos, el concepto
de Clase es la representacin y el mecanismo por el cual se
gestionan las abstracciones.
Por ejemplo, en Java tenemos:
public class Automovil {
//
//
}

variables
mtodos

Encapsulamiento
El encapsulamiento consiste en unir en la Clase las caractersticas y
comportamientos, esto es, las variables y mtodos. Es tener todo
esto es una sola entidad. En los lenguajes estructurados esto era
imposible. Es evidente que el encapsulamiento se logra gracias a la
abstraccin y el ocultamiento que veremos a continuacin.
La utilidad del encapsulamiento va por la facilidad para manejar la
complejidad, ya que tendremos a las Clases como cajas negras
donde slo se conoce el comportamiento pero no los detalles
internos, y esto es conveniente porque nos interesar ser conocer
qu hace la Clase pero no ser necesario saber cmo lo hace.
Ocultamiento

Es la capacidad de ocultar los detalles internos del comportamiento

de una Clase y exponer slo los detalles que sean necesarios para el
resto del sistema.
El ocultamiento permite 2 cosas: restringir y controlar el uso de la
Clase. Restringir porque habr cierto comportamiento privado de la
Clase que no podr ser accedido por otras Clases. Y controlar
porque daremos ciertos mecanismos para modificar el estado de
nuestra Clase y es en estos mecanismos dnde se validarn que
algunas condiciones se cumplan. En Java el ocultamiento se logra
usando las palabras reservadas: public, private y protected delante
de las variables y mtodos.
Lenguajes de Programacin Orientado a Objetos
En 1985, E. Stroustrup extendi el lenguaje de programacin C a
C++, es decir C con conceptos de clases y objetos, tambin por esas
fechas se cre desde sus bases el lenguaje EIFFEL.
En 1995 apareci el ms reciente lenguaje OO, Java desarrollado
por SUN, que hereda conceptos de C++.
El lenguaje de desarrollo ms extendido para aplicaciones Web, el
PHP 5, trae todas las caractersticas necesarias para desarrollar
software orientado a objetos.
Adems de otros lenguajes que fueron evolucionando, como el
Pascal a Delphi.
Finalmente tambin otros lenguajes script como el ActionScript que
si bien no es totalmente orientado a objetos pero s posee las
caractersticas.

Anlisis y diseo Orientado a Objetos

Para el desarrollo de software orientado a objetos no basta usar un
lenguaje orientado a objetos. Tambin se necesitar realizar un
anlisis y diseo orientado a objetos.
El modelamiento visual es la clave para realizar el anlisis OO.
Desde los inicios del desarrollo de software OO han existido
diferentes metodologas para hacer esto del modelamiento, pero
sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML)
puso fin a la guerra de metodologas.
Segn los mismos diseadores del lenguaje UML, ste tiene como
fin modelar cualquier tipo de sistemas (no solamente de software)
usando los conceptos de la orientacin a objetos. Y adems, este
lenguaje debe ser entendible para los humanos y mquinas.
Actualmente en la industria del desarrollo de software tenemos al
UML como un estndar para el modelamiento de sistemas OO. Fue
la empresa Racional que cre estas definiciones y especificaciones
del estndar UML, y lo abri al mercado. La misma empresa cre
uno de los programas ms conocidos hoy en da para este fin; el
Racional Rose, pero tambin existen otros programas como el
Poseidon que trae licencias del tipo community edition que
permiten su uso libremente.
El UML consta de todos los elementos y diagramas que permiten
modelar los sistemas en base al paradigma orientado a objetos. Los
modelos orientados a objetos cuando se construyen en forma
correcta, son fciles de comunicar, cambiar, expandir, validar y
verificar. Este modelamiento en UML es flexible al cambio y
permite crear componentes plenamente reutilizables.

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.
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 en 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 Jacobson
y su compaa Objectory se incorporaron a Rational en su
unificacin,
aportando
el
mtodo
OOSE.
De las tres metodologas de partida, las de Booch 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 al
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).
Objetivos
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 costo 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.
Imponer un estndar mundial.
Mediante el fomento del uso de UML OMG pretende alcanzar los
siguientes objetivos:
Proporcionar a los usuarios un lenguaje de modelado visual
expresivo y utilizable para el desarrollo e intercambio de
modelos significativos.
Proporcionar mecanismos de extensin y especializacin.
Ser independiente del proceso de desarrollo y de los
lenguajes de programacin.
Proporcionar una base formal para entender el lenguaje de
modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden
ser colaboraciones, frameworks, patterns, y componentes.
Integrar las mejores prcticas utilizadas hasta el momento.
El UML debe entenderse como un estndar para modelado y no
como un estndar de proceso software. Aunque UML debe ser
aplicado en el contexto de un proceso, la experiencia ha mostrado
que organizaciones diferentes y dominios del problema diferentes
requieren diferentes procesos. Por ello se han centrado los
esfuerzos en un meta-modelo comn (que unifica las semnticas) y
una notacin comn que proporcione una representacin de esas
semnticas. De todas formas, los autores de UML fomentan un
proceso guiado por casos de uso, centrado en la arquitectura,
iterativo e incremental. Bajo estas lneas genricas proponen el
proceso software definido en una de las extensiones del UML
(Objectory Extension for Software Enginnering) , pero en general el

proceso software es fuertemente dependiente de la organizacin y

del dominio de aplicacin.
Los conceptos y modelos de UML pueden agruparse en las
siguientes
reas
conceptuales:
Estructura esttica:
Cualquier modelo preciso debe primero definir su universo, esto es,
los conceptos clave de la aplicacin, sus propiedades internas, y las
relaciones entre cada una de ellas. Este conjunto de construcciones
es la estructura esttica. Los conceptos de la aplicacin son
modelados como clases, cada una de las cuales describe un
conjunto de objetos que almacenan informacin y se comunican
para implementar un comportamiento. La informacin que
almacena es modelada como atributos; La estructura esttica se
expresa con diagramas de clases y puede usarse para generar la
mayora de las declaraciones de estructuras de datos en un
programa.
Comportamiento dinmico:
Hay dos formas de modelar el comportamiento, una es la historia
de la vida de un objeto y la forma como interacta con el resto del
mundo y la otra es por los patrones de comunicacin de un
conjunto de objetos conectados, es decir la forma en que
interactan entre s. La visin de un objeto aislado es una mquina
de estados, muestra la forma en que el objeto responde a los
eventos en funcin de su estado actual. La visin de la interaccin
de los objetos se representa con los enlaces entre objetos junto con
el flujo de mensajes y los enlaces entre ellos. Este punto de vista
unifica la estructura de los datos, el control de flujo y el flujo de
datos.

Construcciones de implementacin:
Los modelos UML tienen significado para el anlisis lgico y para la
implementacin fsica. Un componente es una parte fsica
reemplazable de un sistema y es capaz de responder a las
peticiones descritas por un conjunto de interfaces. Un nodo es un
recurso computacional que define una localizacin durante la
ejecucin de un sistema. Puede contener componentes y objetos.
Mecanismos de extensin:
UML tiene una limitada capacidad de extensin pero que es
suficiente para la mayora de las extensiones que requiere el da a
da sin la necesidad de un cambio en el lenguaje bsico. Un
estereotipo es una nueva clase de elemento de modelado con la
misma estructura que un elemento existente pero con restricciones
adicionales.
Organizacin del modelo:
La informacin del modelo debe ser dividida en piezas coherentes,
para que los equipos puedan trabajar en las diferentes partes de
forma concurrente. El conocimiento humano requiere que se
organice el contenido del modelo en paquetes de tamao modesto.
Los paquetes son unidades organizativas, jerrquicas y de propsito
general de los modelos de UML. Pueden usarse para
almacenamiento, control de acceso, gestin de la configuracin y
construccin de bibliotecas que contengan fragmentos de cdigo
reutilizable.
Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los
modelos UML. Son comentarios que se pueden aplicar para
describir, clasificar y hacer observaciones sobre cualquier elemento

de
un
modelo.
El tipo principal de anotacin es la nota que simplemente es un
smbolo para mostrar restricciones y comentarios junto a un
elemento
o
un
conjunto
de
elementos
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un
modelo UML. Dependencia, asociacin, generalizacin y
realizacin,
estas
se
describen
a
continuacin
Dependencia
Es una relacin semntica entre dos elementos en la cual un
cambio a un elemento (el elemento independiente) puede afectar a
la semntica del otro elemento (elemento dependiente). Se
representa como una lnea discontinua, posiblemente dirigida, que
a
veces
incluye
una
etiqueta.
Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los
cuales son conexiones entre objetos. La agregacin es un tipo
especial de asociacin y representa una relacin estructural entre
un todo y sus partes. La asociacin se representa con una lnea
continua, posiblemente dirigida, que a veces incluye una etiqueta.
A menudo se incluyen otros adornos para indicar la multiplicidad y
roles
de
los
objetos
involucrados
Generalizacin
Es una relacin de especializacin / generalizacin en la cual los
objetos del elemento especializado (el hijo) pueden sustituir a los
objetos del elemento general (el padre). De esta forma, el hijo
comparte la estructura y el comportamiento del padre.
Grficamente, la generalizacin se representa con una lnea con

punta de flecha vaca.

Realizacin
Es una relacin semntica entre clasificadores, donde un
clasificador especifica un contrato que otro clasificador garantiza
que cumplir. Se pueden encontrar relaciones de realizacin en dos
sitios: entre interfaces y las clases y componentes que las realizan, y
entre los casos de uso y las colaboraciones que los realizan. La
realizacin se representa como una mezcla entre la generalizacin y
la dependencia, esto es, una lnea discontinua con una punta de
flecha vaca.

Diagramas
Los diagramas se utilizan para representar diferentes perspectivas
de un sistema de forma que un diagrama es una proyeccin del
mismo. UML proporciona un amplio conjunto de diagramas que
normalmente se usan en pequeos subconjuntos para poder
representar las cinco vistas principales de la arquitectura de un
sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as
como sus relaciones. Estos diagramas son los ms comunes en el
modelado de sistemas orientados a objetos y cubren la vista de
diseo esttica o la vista de procesos esttica (s incluyen clases
activas).
Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos
instantneas de los diagramas de clases y cubren la vista de diseo

esttica o la vista de procesos esttica desde la perspectiva de

casos
reales
o
prototpicos.
Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de
clases) y sus relaciones. Cubren la vista esttica de los casos de uso
y son especialmente importantes para el modelado y organizacin
del
comportamiento.
Diagramas de Secuencia y de Colaboracin
Tanto los diagramas de secuencia como los diagramas de
colaboracin son un tipo de diagramas de interaccin. Constan de
un conjunto de objetos y sus relaciones, incluyendo los mensajes
que se pueden enviar unos objetos a otros. Cubren la vista
dinmica del sistema. Los diagramas de secuencia enfatizan el
ordenamiento temporal de los mensajes mientras que los
diagramas de colaboracin muestran la organizacin estructural de
los objetos que envan y reciben mensajes. Los diagramas de
secuencia se pueden convertir en diagramas de colaboracin sin
prdida de informacin, lo mismo ocurren en sentido opuesto.

Diagramas de Estados
Muestran una mquina de estados compuesta por estados,
transiciones, eventos y actividades. Estos diagramas cubren la vista
dinmica de un sistema y son muy importantes a la hora de
modelar el comportamiento de una interfaz, clase o colaboracin.

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en

mostrar el flujo de actividades dentro de un sistema. Los diagramas

de actividades cubren la parte dinmica de un sistema y se utilizan
para modelar el funcionamiento de un sistema resaltando el flujo
de
control
entre
objetos.
Diagramas 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
Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en
tiempo de ejecucin y 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.

http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/
Proceso Unificado de Rational
El Proceso Unificado de Rational (Rational Unified Process en
ingls, habitualmente resumido como RUP) es un proceso de
desarrollo de software desarrollado por la empresa Rational
Software, actualmente propiedad de IBM. Junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar
ms utilizada para el anlisis, diseo, implementacin y
documentacin de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino

un conjunto de metodologas adaptables al contexto y necesidades
de cada organizacin.
Tambin se conoce por este nombre al software, tambin
desarrollado por Rational, que incluye informacin entrelazada de
diversos artefactos y descripciones de las diversas actividades. Est
incluido en el Rational Method Composer (RMC), que permite la
personalizacin de acuerdo con las necesidades.
Originalmente se dise un proceso genrico y de dominio pblico,
el Proceso Unificado, y una especificacin ms detallada, el
Rational Unified Process, que se vendiera como producto
independiente...
Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:

Adaptar el proceso
El proceso deber adaptarse a las necesidades del cliente ya que es
muy importante interactuar con l. Las caractersticas propias del
proyecto u organizacin, el tamao del mismo, as como su tipo o
las regulaciones que lo condicionen, influirn en su diseo
especfico. Tambin se deber tener en cuenta el alcance del
proyecto en un rea subformal para hacer un proceso de
satisfaccin del software.
Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes,

contradictorios o disputarse recursos limitados. Debe encontrarse
un equilibrio que satisfaga los deseos de todos. Gracias a este
equilibrio se podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en
etapas iteradas. En cada iteracin se analiza la opinin de los
inversores, la estabilidad y calidad del producto, y se refina la
direccin del proyecto as como tambin los riesgos involucrados.
Colaboracin entre equipos
El desarrollo de software no lo hace una nica persona sino
mltiples equipos. Debe haber una comunicacin fluida para
coordinar requisitos, desarrollo, evaluaciones, planes, resultados,
etc.
Elevar el nivel de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables
tales como patrn del software, lenguajes 4GL o marcos de
referencia (frameworks) por nombrar algunos. Esto evita que los
ingenieros de software vayan directamente de los requisitos a la
codificacin de software a la medida del cliente, sin saber con
certeza qu codificar para satisfacer de la mejor manera los
requisitos y sin comenzar desde un principio pensando en la
reutilizacin del cdigo. Un alto nivel de abstraccin tambin
permite discusiones sobre diversos niveles y soluciones
arquitectnicas. stas se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con el
lenguaje UML.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin,
sino en todos los aspectos de la produccin. El aseguramiento de la
calidad forma parte del proceso de desarrollo y no de un grupo
independiente.
Ciclo de vida

Esfuerzo en actividades segn fase del proyecto.

El ciclo de vida RUP es una implementacin del Desarrollo en

espiral. Fue creado ensamblando los elementos en secuencias
semi-ordenadas. El ciclo de vida organiza las tareas en fases e
iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se
realizan varias iteraciones en nmero variable segn el proyecto y
en las que se hace un mayor o menor hincapi en las distintas
actividades. En la Figura muestra cmo vara el esfuerzo asociado a
las disciplinas segn la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se
enfocan hacia la comprensin del problema y la tecnologa, la
delimitacin del mbito del proyecto, la eliminacin de los riesgos
crticos, y al establecimiento de una baseline (Lnea Base) de la
arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en
actividades de modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo
de la baseline de la arquitectura, abarcan ms los flujos de trabajo
de requisitos, modelo de negocios (refinamiento), anlisis, diseo y
una parte de implementacin orientado a la baseline de la
arquitectura.
En la fase de construccin, se lleva a cabo la construccin del
producto por medio de una serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se refinan
su anlisis y diseo y se procede a su implementacin y pruebas. Se
realiza una pequea cascada para cada ciclo. Se realizan iteraciones

hasta que se termine la implementacin de la nueva versin del

producto.
En la fase de transicin se pretende garantizar que se tiene un
producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las
disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una
disciplina vara.
Principales caractersticas
Forma disciplinada de asignar tareas y responsabilidades
(quin hace qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de
Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser
iterativo e incremental, estar centrado en la arquitectura y guiado
por los casos de uso. Incluye artefactos (que son los productos
tangibles del proceso como por ejemplo, el modelo de casos de
uso, el cdigo fuente, etc.) y roles (papel que desempea una
persona en un determinado momento, una persona puede
desempear distintos roles a lo largo del proceso).

Fases
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se
establecen las disciplinas:
'Proceso': Las etapas de esta seccin son: (Revise nuevamente la
grfica)
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte nos encontramos con las siguientes etapas:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno
La estructura dinmica de RUP es la que permite que ste sea un
proceso de desarrollo fundamentalmente iterativo, y en esta parte
se ven inmersas las 4 fases descritas anteriormente:
Inicio (tambin llamado Incepcin o Concepcin).
Elaboracin.
Desarrollo (tambin llamado Implementacin, Construccin).
Cierre (tambin llamado Transicin).

Fase de Inicio: Esta fase tiene como propsito definir y acordar el

alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
Fase de elaboracin: En la fase de elaboracin se seleccionan los
casos de uso que permiten definir la arquitectura base del sistema y
se desarrollaran en esta fase, se realiza la especificacin de los
casos de uso seleccionados y el primer anlisis del dominio del
problema, se disea la solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los requisitos
pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el
proyecto.
Fase de Cierre: (debe decir FASE DE TRANSICION) El propsito de
esta fase es asegurar que el software est disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las
pruebas de aceptacin, capacitar a los usuarios y proveer el soporte
tcnico necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el
proyecto.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura
dinmica) realiza una serie de artefactos que sirven para
comprender mejor tanto el anlisis como el diseo del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:
Documento Visin
Especificacin de Requisitos
Elaboracin:
Diagramas de caso de uso
Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lgica
o
o

Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)

Vista de Implementacin
o
o
o

Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin

Vista Conceptual
o

Modelo de dominio

Vista fsica
o

Mapa de comportamiento a nivel de hardware.

Un poco de historia
Los orgenes de RUP se remontan al modelo espiral original de
Barry Boehm. Ken Hartman, uno de los contribuidores claves de
RUP colabor con Boehm en la investigacin. En 1995 Rational
Software compr una compaa sueca llamada Objectory AB,
fundada por Ivar Jacobson, famoso por haber incorporado los casos
de uso a los mtodos de desarrollo orientados a objetos. El Rational
Unified Process fue el resultado de una convergencia de Rational
Approach y Objectory (el proceso de la empresa Objectory AB). El
primer resultado de esta fusin fue el Rational Objectory Process, la
primera versin de RUP, fue puesta en el mercado en 1998, siendo
el arquitecto en jefe Philippe Kruchten.
Comentarios sobre Alcance del RUP
La metodologa RUP es ms apropiada para proyectos grandes
(Aunque tambin pequeos), dado que requiere un equipo de
trabajo capaz de administrar un proceso complejo en varias etapas.
En proyectos pequeos, es posible que no se puedan cubrir los
costos de dedicacin del equipo de profesionales necesarios.
Comentarios sobre Metodologa
Por otro lado, en lo que se refiere a la metodologa esta comprende
tres fases claves: Dirigido por los casos de uso, centrado en la
arquitectura, iterativo e incremental.
En lo referente a dirigido por los casos de uso, est enfocado hacia
el cliente y se utilizan con algunas modificaciones tal vez, hasta la
disciplina de pruebas, en la cual, un caso de uso puede a su vez
tener uno o ms casos de prueba.