RUP Y UML

nstituto Tecnolgico Superior de Fresnillo

Academia de Informtica

CURSO DE TITULACIONUNIDAD 1: EL MODELO DEL PROCESO DEL SOFTWARE OBJETIVO O COMPETENCIA A DESARROLLAR:Analizar y modelar proyectos de sistemas de informacin aplicando el paradigma orientado a objetos. Competencias especficas: Conocer el modelo de proceso de software. Identificar reas de oportunidad en una organizacin, para la propuesta y diseo de sistemas de informacin. Analizar diversas alternativas de solucin a partir de la identificacin y definicin de requerimientos especificados por el cliente. Establecer una propuesta para el anlisis y diseo de un proyecto de software de acuerdo a la alternativa de solucin planteada o establecida. Planificar y gestionar proyectos de sistemas de informacin con base en una metodologa de desarrollo. Aplicar principios de ingeniera del software en las etapas de anlisis y diseo de un sistema de informacin. Modelar casos de uso acorde a los requerimientos del proyecto. Documentar el proyecto.

TEMARIO:1.1 1.2 1.3 1.4 1.5 Conceptualizacin de tecnologa orientada a objetos. Metodologas emergentes de desarrollo de software. Mtodos de desarrollo de software orientado a objetos. El proceso de desarrollo unificado RUP. El lenguaje de modelado unificado UML.

ACTIVIDADES DE APRENDIZAJE:Conocer el modelo de proceso de software: Analizar las caractersticas de los modelos de desarrollo de sistemas de informacin, as como de mtodos de desarrollo de software orientado a objetos. Buscar en artculos, y libros especializadosconceptos y ejemplos de mtodos de desarrollo de software orientado a objetos, y realizar una tabla comparativa. Buscar en artculos, y libros especializados conceptos, ejemplos y tendencias de UML y RUP, y realizar una tabla comparativa. contenido de la unidad

TEMA 1.1: CONCEPTUALIZACIN DE TECNOLOGA ORIENTADA A OBJETOSTecnologa orientada a objetos

Analisis y Modelado de Sistemas de Informacin

Unidad 1

1

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica 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 elmantener 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 Analisis y Modelado de Sistemas de Informacin Unidad 1 2

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica 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 lgicasde 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 partesms. 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 Analisis y Modelado de Sistemas de Informacin Unidad 1 3

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica 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 ycomportamientos. 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 = Ford Modelo = Focus Color = Azul Velocidad Mxima = 260 km/h 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.).


Unidad 1

4

Instituto Tecnolgico Superior de Fresnillo


Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que los celularescomparten 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.

Analisis y Modelado de Sistemas de InformacinUnidad 1

5



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 Analisis y Modelado de Sistemas de Informacin Unidad 1 6

Instituto Tecnolgico Superior de Fresnillo // mtodos } Encapsulamiento


El encapsulamientoconsiste 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. 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 modelado visual es la clave para realizar el anlisis OO. Desde los inicios del desarrollo de software OO han existidodiferentes metodologas para hacer esto del modelado, pero sin lugar a duda, el Lenguaje de Modelado 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 modelado 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 modelado en UML es flexible al cambio y permite crear componentes plenamente reutilizables. Analisis y Modelado de Sistemas de Informacin Unidad 1 7



TEMA 1.2: METODOLOGAS EMERGENTES DE DESARROLLO DE SOFTWAREUna metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. Alo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad. El framework para metodologa de desarrollo de software consiste en: Una filosofa de desarrollo de programas de computacin con el enfoque del proceso de desarrollo de software. Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo documentada en algn tipo de documentacin formal. Historia El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas. Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como complemento sedescribirn las metodologas de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

Metodologas de desarrollo de software 1970s Analisis y Modelado de Sistemas de Informacin Unidad 1 8

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Programacin estructurada sol desde 1969 Programacin estructurada Jackson desde 1975 1980s Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniera de la informacin (IE/IEM) desde 1981 1990s Rapid application development (RAD) desde 1991. Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's Virtual finite state machine (VFSM) desde 1990s Dynamic Systems Development Method desarrollado en UK desde 1995. Scrum (desarrollo), en la ltima parte de los 90's Rational Unified Process (RUP) desde 1999. Nuevo milenio Extreme Programming(XP) desde 1999 Enterprise Unified Process (EUP) extensiones RUP desde 2002 Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler Enfoques de desarrollo de software Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologasespecficas. Estos enfoques son los siguientes: Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

Modelo en cascada Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el diseo, implementacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo. Los principios bsicos del modelo de cascada son los siguientes: El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases. Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases antes de comenzar la prxima fase.


Unidad 1

9

Instituto Tecnolgico Superior de Fresnillo Prototipado


El prototipado es el framework de actividades dedicada aldesarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar. Incremental Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro. Los principios bsicos son: Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental Se definen los requisitos antes de proceder con lo evolutivo, se realiza un miniCascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final.

Espiral Los principios bsicos son: La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de la continuacin del proyecto durante todo el ciclo de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la prxima iteracin. Cada ciclocomienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.

Rapid Application Development (RAD) El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo interativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. Principios bsicos: Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin.


Unidad 1

10

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y tcnicas orientada a objetos. Hace especial hincapi en el cumplimiento de la necesidadcomercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica. La participacin activa de los usuarios es imprescindible. Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

Otros enfoques de desarrollo de software Metodologas de desarrollo Orientado a objetos, Diseo orientado a objetos (OOD) de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin, mdulo, y el proceso. Top-down programming, evolucionado en la dcada de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. Proceso Unificado, es una metodologa de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de una o ms iteraciones de desarrollo de software: creacin, elaboracin, construccin, y las directrices. Hay una serie de herramientas y productos diseados para facilitar la aplicacin. Unade las versiones ms populares es la de Rational Unified Process.

TEMA 1.3: MTODOS DE DESARROLLO DE SOFTWARE ORIENTADO A OBJETOSEl desarrollo de software no es sin dudas una tarea fcil. Como resultado a este problema ha surgido una alternativa desde hace mucho: la Metodologa. Las metodologas imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo ms predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte nfasis en planificar inspirado por otras disciplinas de la ingeniera. Las metodologas ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. An menos por su popularidad. La crtica ms Analisis y Modelado de Sistemas de Informacin Unidad 1 11

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica frecuente a estas metodologas es que son burocrticas. Hay tanto que hacer para seguir la metodologa que el ritmo entero del desarrollo se retarda. Hoy en da existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas especficamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, sobre todo aquellos proyectos de gran tamao (respecto a tiempo y recursos). Sin embargo la experiencia ha demostrado que las metodologas tradicionales no ofrecen una buena solucin para proyectos donde el entorno es voltil y donde los requisitos no se conocen con exactitud, porque no estnpensadas para trabajar con incertidumbre. Aplicar metodologas tradicionales nos obliga a forzar a nuestro cliente a que tome la mayora de las decisiones al principio. Luego el coste de cambio de una decisin tomada puede llegar a ser muy elevado si aplicamos metodologas tradicionales. Es por ello que varios problemas como los que a continuacin mencionamos han sido detectados: Retrasos en la planificacin: llegada la fecha de entregar el software ste no est disponible. Sistemas deteriorados: el software se ha creado pero despus de un par de aos el coste de su mantenimiento es tan complicado que definitivamente se abandona su produccin. Tasa de defectos: el software se pone en produccin pero los defectos son tantos que nadie lo usa. Requisitos mal comprendidos: el software no resuelve los requisitos planificados inicialmente. Cambios de negocio: el problema que resolva nuestro software ha cambiado y nuestro software no se ha adaptado. Falsa riqueza: el software hace muchas cosas tcnicamente muy interesantes y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que ste gane ms dinero. Cambios de personal: despus de unos aos de trabajo los programadores comienzan a odiar el proyecto y lo abandonan. Como respuesta a los problemas aplicando metodologas tradicionales surgieron otras metodologas que tratan de adaptarse a la realidad del desarrollo de software. El encanto de estas metodologas giles es su reaccin ante la burocracia de las metodologas monumentales. Estos nuevos mtodos buscan un justo medio entre ningn proceso y demasiado proceso,proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena. El resultado de todo esto es que los mtodos giles cambian significativamente algunos de los nfasis de los mtodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad ms pequea de documentacin para una tarea dada. De muchas maneras son ms bien orientados al cdigo: siguiendo un camino que dice que la parte importante de la documentacin es el cdigo fuente. Una metodologa de desarrollo de software Orientado a Objetos consta de

Conceptos y diagramas Unidad 1 12


Instituto Tecnolgico Superior de Fresnillo Etapas y definicin de entregas en cada una de ellas Actividades y recomendaciones


Una metodologa de desarrollo de software Orientada a Objetos basada en UML Se presenta a continuacin un resumen de las principales etapas y actividades basadas en UML. Esta metodologa es extractada de las metodologas existentes, en particular

Object Oriented Design

Objectory

Object Modeling Technique

Anlisis de Requerimientos Grady Booch Anlisis de Dominio Diseo Anlisis de Object-Oriented Software Requerimientos Enginnering Anlisis de Robustez Ivar Jacobson A Use Case Driven Approach Diseo Addison-Wesley Implementacin 1992 Pruebas Object Oriented Modeling Anlisis James Rumbaugh and Design Diseo del Sistema et. al. Prentice Hall Diseo de Objetos 1991 Implementacin

Object Oriented Design with Applications Benjamming Cummings 1991Estas tres metodologas van a ser fusionadas a finales de 1997 en una sola, basada en la notacin UML

TEMA 1.4: EL PROCESO DE DESARROLLO UNIFICADO RUPEl proceso unificado de desarrollo (RUP) es una metodologa para la ingeniera de software que va ms all del mero anlisis y diseo orientado a objetos para proporcionar una familia de tcnicas que soportan el ciclo completo de desarrollo de software. El resultado es un proceso basado en componentes, dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. Caractersticas principales de RUP Centrado en los modelos: Los diagramas son un vehculo de comunicacin ms expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de descripciones y especificaciones textuales del sistema. Guiado por los Casos de Uso: Los Casos de Uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba. Centrado en la arquitectura: Los modelos son proyecciones del anlisis y el diseo constituye la arquitectura del producto a desarrollar. Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones incrementales (que se acercan al producto terminado) del producto en desarrollo.


Unidad 1

13

Instituto Tecnolgico Superior de Fresnillo Beneficios que aporta RUP


Permite desarrollar aplicaciones sacando el mximo provecho de las nuevas tecnologas, mejorando la calidad, le rendimiento, la reutilizacin, la seguridad y el mantenimiento delsoftware mediante una gestin sistemtica de los riesgos. Permite la produccin de software que cumpla con las necesidades de los usuarios, a travs de la especificacin de los requisitos, con una agenda y costo predecible. Enriquece la productividad en equipo y proporciona prcticas ptimas de software a todos sus miembros. Permite llevar a cabo el proceso de desarrollo prctico, brindando amplias guas, plantillas y ejemplos para todas las actividades crticas. Proporciona guas explicitas para reas tales como modelado de negocios, arquitectura Web, pruebas y calidad. Tambin se proporciona guas para desarrollar en plataformas IBM WebSphere y Microsoft Web Solution para acelerar el desarrollo de los proyectos. Se integra estrechamente con herramientas Rational, permitiendo a los equipos de desarrollo aprovechar todas las ventajas de las caractersticas de los productos Rational, el Lenguaje de Modelado Unificado (UML) y otras prcticas ptimas de la industria. Unifica todo el equipo de desarrollo de software y mejora la comunicacin al brindar a cada miembro del mismo una base de conocimientos, un lenguaje de modelado y un punto de vista de cmo desarrollar software. Optimiza la productividad de cada miembro del equipo al poner al alcance la experiencia derivada de miles de proyectos y muchos lderes de la industria. No solo garantiza que los proyectos abordados sern ejecutados ntegramente sino que adems evita desviaciones importantes respecto a los plazos. Permite una definicin acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parcialesposteriores.

TEMA 1.5: EL LENGUAJE DE MODELADO UNIFICADO UMLUML es un lenguaje para modelar y comunicar informacin sobre sistemas, para lo cual se usan diagramas y texto. Por ejemplo la Figura 1-5 comunica lo siguiente: Un administrador dirige un equipo que trabaja en un proyecto. Cada administrador tiene un nombre y un nmero de telfono, adems puede iniciar o terminar un proyecto. Cada proyecto tiene un nombre, una fecha de inicio y una fecha de fin. Cada equipo tiene una descripcin, y eso es todo lo que nos interesa con respecto al equipo. Figura 1-5. Administradores, proyectos y equipos.


Unidad 1

14

Instituto Tecnolgico Superior de FresnilloAdministrador Nombre Telefono IniciarProyecto() TerminarProyecto() Dirige Equipo Descripcion Proyecto Nombre FerchaDeInicio FichaDeFin Administra


Ejecuta

Fuente: O`Reilly 2003

Los tres aspectos de UML UML es una abreviacin de Unified Modeling Language (Lenguaje de Modelado Unificado). Cada una de estas tres palabras habla de un aspecto importante de UML, las prximas secciones hablaran de estos tres aspectos. Language (Lenguaje) Un lenguaje nos permite la comunicacin sobre un tema o concepto determinado. En el desarrollo de un sistema, los temas que se incluyen son los requerimientos y el sistema. Sin un lenguaje seria difcil para los miembros de un equipo comunicase y colaborar para el desarrollo exitoso de un sistema. Los lenguajes, no siempre se componen de palabras escritas. Por ejemplo, comnmente usamos lenguajes de conteo paraensear a los nios a contar en las clases de aritmtica. Los nios usan entonces objetos como son, peras o manzanas, para representar algn nmero. Ahora considere estos dos lenguajes para comunicar algn nmero en especfico o das que dura un proyecto. Para representar el nmero cinco, un lenguaje de conteo utiliza cinco objetos, mientras que un lenguaje aritmtico se utiliza la cadena "5". Figura 1-6. La cantidad cinco en dos lenguajes

Fuente: O`Reilly 2003

UML es un lenguaje para especificar, visualizar construir y documentar los artifacts del sistema intensivo de procesos. UML en si no es un proceso, un proceso implica un conjunto de pasos descritos por una metodologa para resolver un problema y desarrollar un sistema que satisfaga los requerimientos de un usuario. Modelo Un modelo es una representacin de un tema, ste captura un conjunto de ideas conocidas como abstracciones. Sin un modelo, es muy difcil para los miembros del equipo tener un


Unidad 1

15

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica entendimiento comn de los requerimientos del sistema, as como del impacto de los cambios mientras se desarrolla el sistema. Cuando se crea el modelo, si tratamos de representar todo al mismo tiempo, fcilmente tendremos una sobrecarga de informacin, es por eso que hay que concentrarse en capturar solo la informacin relevante para entender el problema, resolverlo, e implementar la solucin, mientras se excluye cualquier informacin que sea irrelevante que pudieradificultar el progreso del desarrollo. Unificado Este trmino se refiere al hecho de que el Grupo de Administracin de Objetos (Object Management Group - OMG) y el Rational Software Corporation, crearon UML para traer las mejores prcticas de ingeniera a la industria de tecnologa y de los sistemas de informacin. Sin un lenguaje en comn, es difcil para los nuevos miembros de un equipo volverse productivo rpidamente y contribuir en el desarrollo de un sistema. Metas y Alcances Para entender las metas y los alcances de la OMG para UML, es mejor empezar por las motivaciones detrs de UML. Las metas de los OMGs que hicieron UML son: Listo para usarse Expresivo Simple Preciso Extensible Independiente de la implementacin Independiente del proceso

Estando listo para usarse, siendo expresivo, simple y preciso, UML puede inmediatamente ser aplicado para el desarrollo de proyectos. Para habilitar el desarrollo de modelos precisos, la OMG presenta el Lenguaje de Restricciones de Objetos (Object Constraint Language - OCL), un sublenguaje para adherir condiciones que los elementos del modelo deben satisfacer para que el mismo modelo sea considerado correcto. En cuanto a los alcances de la OMG al momento de la creacin de UML fue incluir un lenguaje de modelado que combina tres de los ms importantes mtodos de desarrollo de sistemas: El Mtodo Booch `93 de Grady Booch. La Tcnica de Modelado de Objetos (Object Modeling Technique - OMT) de James Rumbaugh. El mtodo de Ingeniera de Software Orientado a Objetos (Object-Oriented Software Engineering - OOSE) de and IvarJacobson.

En conjunto con las mejores prcticas de la industria de tecnologa y de sistemas de informacin. De manera separada son slo eso, mtodos, pero al unirlos conforman una metodologa. Historia


Unidad 1

16

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica La historia de UML consiste de cinco Perodos distintos. Al entender esos Perodos se puede entender como surgi UML y como esta evolucionando en estos momentos. El Perodo de Fragmentacin Entre la mitad de 1970 y la mitad de 1990, las organizaciones comenzaron a entender el valor del software para los negocios, pero solo tena una coleccin fragmentada de tcnicas para desarrollar y dar mantenimiento al software. Tres mtodos sobresalieron: El Mtodo Booch `93 de Grady Booch, que hace nfasis en el diseo y construccin de sistemas de software. La Tcnica de Modelado de Objetos (Object Modeling Technique - OMT) de James Rumbaugh, que hace nfasis en el anlisis de los sistemas de software. El mtodo de Ingeniera de Software Orientado a Objetos (Object-Oriented Software Engineering - OOSE) de and Ivar Jacobson, que hace nfasis en la ingeniera del negocio y el anlisis de los requerimientos. Conforme los mtodos orientados a objetos comenzaron a evolucionar desde los mtodos estructurales, la industria se fue fragmentando principalmente alrededor de estos tres mtodos. Los practicantes de un mtodo no podan fcilmente entender los artifacts producidos por un mtodo diferente. Adems estas personas tenan problemas al pasar de unaorganizacin hacia la siguiente debido a que dicho movimiento implicaba el aprendizaje de un nuevo mtodo. El Perodo de Unificacin Entre la mitad de 1990 y la mitad de 1997, surgi la versin 1.0 de UML. James Rumbaugh y posteriormente Ivar Jacobson, se unieron a Grady Booch en la Corporacin Rational Software para unificar sus mtodos. Por sus esfuerzos de unin, se les empezo a llamar Los Tres Amigos. Conforme las organizaciones comenzaron a ver el valor de UML, el grupo de trabajo de de Diseo y Anlisis de Objetos de la OMG elaboro una Solicitud para una Propuesta (Request for Proposal - RFP) para establecer un estndar que definiera el significado de los conceptos de la tecnologa orientada a objetos para las herramientas que soportaran el diseo y el anlisis orientado a objetos. En conjunto con varias organizaciones, la Corporacin Rational Software forma un Consorcio de Socios de UML, y estos socios son los que envan la versin 1.0 de UML a la OMG en respuesta a uno de los varios RFP iniciales. El Perodo de Estandarizacin Hacia finales de 1997 se libera la versin 1.1 de UML, todas las replicas a los RFP fueron combinadas en la versin 1.1 de UML. La OMG adopto UML y asumi la responsabilidad del desarrollo de la estandarizacin en noviembre de 1997. El Perodo de Revisin Despus de la adopcin de UML en 1997, varias versiones surgieron. La OMG realizo un diagrama de las revisiones del grupo de trabajo (revision task force - RTF) para aceptar comentarios pblicos de UML y realizar la menor cantidad de trabajo editorial y de actualizaciones tcnicas al estndar.Varios vendedores empezaron a dar soporte y promocin


Unidad 1

17

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica de UML con herramientas, consultora y libros. La versin actual de UML es la 1.4 y la OMG esta actualmente trabajando en versin 2.0 de UML. El Perodo de Industrializacin A la par del perodo de revisin, los OMG estn proponiendo que el estndar de UML se convierta en una estandarizacin internacional a travs de una Especificacin de Disposicin Pblica (Publicly Available Specification - PAS) a travs de la Organizacin Internacional de Estndares(Organization for Standardization - ISO). UML y los Procesos Aunque UML es independiente del proceso, sus creadores promueven un proceso que sea dirigido por Casos de Uso (use-case driven), iterativo e incremental. Para entender como UML esta relacionado con los procesos y los tipos de procesos que sus creadores proponen, se debe tener un mejor entendimiento acerca de cul es la mejor tcnica para aprender UML. Sin embargo cualquier tipo de proceso incluso aquellos que no tienen estas caractersticaspueden utilizar UML. Generalmente cada proceso de ciclo de vida en el desarrollo de un sistema, involucra los siguientes tipos de actividades: Requerimientos. Actividades de anlisis para entender los requerimientos. Actividades de diseo para determinar como el sistema va a satisfacer los requerimientos. Actividades de Implementacin para la construccin del sistema. Actividades de Prueba para verificar que el sistema satisface losrequerimientos. Actividades de Deployment para hacer que el sistema sea accesible para sus usuarios.

Aplicando un Ciclo de Vida en Cascada Cuando se aplica el ciclo de vida de cascada, las actividades son realizadas de una manera simple y linear para todos los requerimientos. Esto a veces resulta en el descubrimiento de problemas relacionados con la calidad, estos problemas se mantienen escondidos durante las actividades de diseo e implementacin. Aplicando un Ciclo de Vida Iterativo Cuando se aplica el Ciclo de Vida Iterativo, cada una de las actividades del ciclo de vida son realizadas varias veces para un mejor entendimiento de los requerimientos y desarrollar gradualmente un sistema ms robusto. Casos de Uso Un caso de uso es un requerimiento funcional descrito desde la perspectiva del usuario del sistema. Por ejemplo, un requerimiento funcional para la mayora de los sistemas incluye una funcionabilidad de seguridad que les permita a los usuarios entrar y salir del sistema, agregar datos, procesar datos, generar reportes, etc. Arquitectura


Unidad 1

18

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica La arquitectura abarca los elementos que se necesitan para elaborar un sistema y la manera en que estos trabajan juntos para proveer de funcionabilidad del sistema. Los elementos y sus relaciones son conocidos como la estructura del sistema. El modelado de la estructura del sistema se conoce como Modelado de la Estructura. Los elementos y la manera en que estos interactan y colaboran sonconocidos como el comportamiento del sistema. El modelado del comportamiento del sistema es conocido como Modelado del Comportamiento. Los distintos tipos de elementos que constituyen la arquitectura del sistema, estructura y comportamiento estn determinados por el paradigma orientado a objetos. Riesgo Un riesgo es cualquier obstculo o incgnita que puede impedir nuestro xito. Para determinar que casos de uso deben ser tomados en cuenta para la realizacin de una iteracin y en que partes de la arquitectura nos tenemos que concentrar en una iteracin en particular, lo primero que se tiene que hacer es identificar los riesgos del proyecto. Una vez hecho esto se relacionan los riesgos ms importantes con los casos de uso y los elementos de arquitectura que resolveran dichos riesgos. Aprendiendo UML Aprender UML puede ser un poco abrumador, debido a la amplitud y profundidad del lenguaje as como a la ausencia de un proceso, si no se sabe sobre que partes de UML enfocarse. Para poder entender como UML se relaciona con los procesos, uno se debe concentrar en: El paradigma orientado a objetos, porque este establece las bases para UML. El Modelado de la Estructural y el Modelado del Comportamiento, porque ellos permiten entender los requerimientos y la arquitectura. Otras capacidades de UML. Cuando se aprende UML es importante concentrarse en lo esencial y entender cmo aplicar UML de manera efectiva y exitosa al modelado de sistemas, en vez de atascarse en tratar de aprender cada aspecto del lenguaje. Para lo que resta de los captulos, se utilizar un caso de uso de un sistema deadministracin de proyectos para ayudar a aprender como leer, entender, escribir y poder aplicar efectiva y exitosamente UML. El objetivo no es crear un modelo completo o demasiado extenso para la implementacin de un sistema, pero si explorar ese caso de uso y aprender como aplicar efectiva y exitosamente UML para comunicar en el desarrollo de un sistema del mundo real. Generalmente, en el caso de estudio un sistema de administracin de proyectos provee funcionalidad para manejar proyectos, recursos y administrar el sistema, se definen los siguientes roles: Administrador del Proyecto (Project Manager) Es el responsable de asegurar la entrega de un proyecto con calidad, dentro del tiempo especificado, costo y recursos. Administrador de Recursos (Resource Manager)


Unidad 1

19

Instituto Tecnolgico Superior de Fresnillo Academia de Informtica Es el responsable de asegurar que el personal disponible en el proyecto este entrenado y con las habilidades necesarias. Recursos Humanos (Human Resource) Es el responsable de asegurar que la calidad de un proyecto esta siempre disponible. Administrador del Sistema (System Administrator) Es el responsable de asegurar que un sistema de administracin de proyectos esta disponible para un proyecto. Conforme se vaya avanzando en los captulos se ir proveyendo de ms detalle sobre el caso de estudio donde sea necesario.

PRACTICAS:Seleccionar una propuesta para el anlisis y modelado de un proyecto de software y con l: Seleccionar una metodologa de desarrollo para abordarla propuesta de proyecto de desarrollo de software con base al anlisis comparativo de metodologas. Identificar y definir requisitos. Realizar la planeacin, estudio de factibilidad y anlisis costo/beneficio para un sistema de informacin. Elaborar la planificacin del desarrollo del proyecto con base en la metodologa seleccionada y en el modelo de requisitos. Modelar un sistema de informacin con base en los requisitos, aplicando paradigma orientado a objetos con UML.

EVALUACION DE LA UNIDAD:Tabla con informacin sobre los aspectos y porcentajes de evaluacin

REFERENCIAS:1. Bernd Bruegge, Allen H. Dutoit. Ingeniera de Software Orientado a Objetos. Prentice Hall. 2. Ian Sommerville; Ingenieria de Software, Edit. Addison Wesley; 2005. 3. James Rumbaugh, Ivar Jacobson, Graby Booch. El Lenguaje Unificado de Modelado Manual de Referencia. Addison Wesley. 4. Kenneth C. Lawden, Jane P. Lawden. Administracin de Los Sistemas de Informacin, Organizacin y Tcnicas. 5. Laudon, K.; Laudon, J.; Sistemas de Informacin Gerencial. Administracin de la Empresa Digital; 10 Edicin; Edit. Pearson Prentice Hall. 2008. 6. Roger S. Pressman; Ingenieria de software un Enfoque practico; Edit. Mc. Graw Hill; 2007. 7. Senn A. James. Analisis y Diseo de Sistemas de Informacin. Addison Wesley. 8. Shari Lawrence Pfleeger. Ingeniera de Software Teora y Prctica. Prentice Hall. 9. Alfredo Weitzenfeld. Ingeniera de Software Orientada a Objetos con UML, Java e Internet. Edit. Thomson. 2007


Unidad 1

20

RUP Y UML

Documents

Transcript of RUP Y UML