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.