Desarrollo e implementacin de Sistemas de Informacin 1.

UML y el proceso unificado

Qu es UML? El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesin de una serie de mtodos de anlisis y diseo orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros mtodos de anlisis y diseo orientados a objetos. Los autores de UML apuntaron tambin al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios. El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo. La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los agentes involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo. EL PROCESO UNIFICADO Es un marco de desarrollo de Software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura por ser interactivo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado Rational o simplemente RUP. El proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes.El proceso Unificado es un marco de trabajo extensible que puede ser adoptado a organizaciones o proyectos especficos; Este tambin es un marco de trabajo extensible. CARACTERSTICAS 1.- Interactivo e Incremental: Esta compuesto de cuatro fases denominadas: Inicio, Elaboracin, Construccin y Transicin; cada una de estas fases es a su vez divididas en una serie de interacciones. La de inicio slo consta de varias interacciones en proyectos grandes, estas ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas interacciones se divide a su vez en una serie de disciplina que recuerdan a las definidas en el ciclo de vida clsico o en cascada, Se basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden de una etapa a la siguiente slo tras finalizar con xito las tareas de verificacin y vacilacin propias de la etapa. Si resulta necesario, nicamente se da marcha atrs hasta la fase inmediatamente anterior. 2.-Dirigido por casos de Uso: Se utilizan para capturar los requisitos funcionales y para definir los contenidos de las interacciones: Diseo, Implementacin, prueba, etc. 3.- Centrado en la Arquitectura: Asume que no existe un modelo nico que cubra todos los aspectos del sistema; ya que existe mltiples modelos y visitas que definen la arquitectura del Software de un sistema.

4.- Enfocado a los Riesgos: Se refiere a que el equipo del proyecto se encuentre en identificar los riesgos crticos en una etapa temprana de ciclo de vida; Los resultados de cada interaccin, en especial los de la fase de elaboracin, debe ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. En resumidas Cuentas el RUP, es un proceso de desarrollo de Software y junto con el Lenguaje Unificado Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos y adaptables al contexto y necesidades de cada organizacin. El RUP, est basado en seis principios claves que son: Adaptar el Proceso: El proceso se debe adaptar a las necesidades del cliente ya que es muy importante interactuar con el; el tamao, el tipo las regulaciones, alcance del proyecto, influirn en el diseo especifico. Equilibrar propiedades: Los requisitos de los participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. As se podr corregir desacuerdos que surjanen el futuro. Demostrar Valor Interactivamente : Los proyectos se entregan de un modo interno, en etapas iteradas, en cada iteracin se analiza la opinin de los inversores, la estabilidad y la calidad del producto, posteriormente se refina la direccin del proyecto as como tambin los riesgos involucrados. Colaboracin entre Equipos: El desarrollo del Software no lo hace una persona sino mltiples equipos debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evoluciones, planes, resultados, etc. Elevar el Nivel de Abstraccin: Este principio dominante motiva el uso de conceptos reutilizables tales como el patrn del Software, lenguajes 4GL o marcos de referencias (Frameworks). Esto evita que los Ingenieros de Software vayan directamente de los requisitos a la codificacin del Software a la medida del cliente sin saber con certeza que codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde el principio. 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 calidad forma parte del proceso de desarrollo y no de un grupo independiente. LENGUAJE UNIFICADO Surgi en los aos 1980 y principios de los siguientes. El UML, unifica obre todo, los mtodos de Booch Rumbaugh, Bruhi (OMT) y Jacobson, pero su alcance llegara ser muchos ms amplio, en estos momentos el UML, esta en pleno proceso de estandarizacin con el OMG (Object Management Group) Grupo de Administracin de Objetos. La cuestin fundamental del desarrollo del Software es la escritura del cdigo. Despus de todo, los diagramas son solo imgenes, ningn usuario va a agradecer la belleza de los dibujos, lo que el usuario quiere es que el Software funcione, por lo tanto cuando se considere usar el UML, es importante preguntarse por qu lo har?, Cmo ayudara cuando llegue a escribir el cdigo? No existe evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas.

Lenguajes de Descripcin: Son lenguajes cuya funcin principal no es hacer programas, sino describir como se representan los datos, como por ejemplo, pginas Web (HTML), ecuaciones (MathML, LaTex, CML), representacione4s geogrficas (GML), puntos geogrficos (Waypoints), subttulos (VobSub), OMG), animaciones (SMIL), imgenes vectoriales (SVG), representaciones 3D (X3D), etc. LDP: Page Description Language (Idioma descriptivo De la Pgina), describe el formato de las pginas, la colocacin del texto y los elementos grficos como mapas de bits o como objetos vectoriales para obtener una calidad de impresin optima. Los LDP son completos y podran utilizarse para crear programas, no se usan como este propsito pues son interpretados y consecuentemente lentos. Hacen que el computador enve a la impresora un fichero con la descripcin de las pginas a ser impresas por un programa o plataforma independiente. Algunas impresoras pueden interpretar directamente este lenguaje, finalmentela impresora recibe el fichero, lo procesa y genera el mapa bits que ser impreso. Lenguaje de Descripcin de Pginas: AFP (Advanced Funtion Presentation) Funcin Avanzada de Presentacin.

1.1. Conceptualizacin de UML. El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

Diagramas de Casos de Uso para modelar los procesos 'business'. Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema. Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementacin para modelar la distribucin del sistema.

UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares. En 1996, el Object Management Group (OMG), un pilar estndar para la comunidad del diseo orientado a objetos, public una peticin con propsito de un metamodelo orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versin 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versin 1.1. El OMG est actualmente en proceso de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1 de abril de 1999 1.1.2. Surgimiento 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 Jacob son y su compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE. De las tres metodologas de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde el OMG, que es tambin el origen de CORBA, el estndar lder en la industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo orientado a objetos. UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera ser capaz de modelarse a s mismo). 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 coste bajo. Proporcionar mecanismos de extensin de forma que aproximaciones de modelado futuras podran desarrollarse encima del UML. Permitir el intercambio del modelos entre una gran variedad de herramientas. Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas para la comparicin 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 maquina 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 perdida de informacin, lo mismo ocurren en sentido opuesto. Diagramas de Estados Muestran una maquina 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.