Ing. Elmer Arturo Carballo Ruiz. Tecnología Orientada a Objetos

TOO115

Historia del Proceso Unificado Método Ericcson El lenguaje de Descripción y Especificación Proyecto Objectory El método Rational El lenguaje de Modelado Unificado ( UML) El Proceso Unificado de Rational

Proporcionar una visión general del RUP y UML como apoyo para el desarrollo de software de calidad.

Un proceso define quien está haciendo que, cuando lo hace, y como hacerle para alcanzar un objetivo

El proceso unificado posee raíces profundas en palabras de Peter F. Drucker, es una “ innovación basada en el conocimiento”.

Alumbramiento del Desarrollo del PU en 1967, se esbozan los logros de Ericsson. ◦ El sistema entero se modela como un conjunto de bloques

interconectados(En UML se conoce como “subsistemas” y se implementa mediante “ componentes”).

◦ Ensambla los bloques de más bajo nivel en subsistemas de más alto nivel. Identificaban los bloques estudiando los casos de negocio-hoy conocidos como “casos de uso”-previamente especificados.

◦ Actividades de diseño producían conjunto de diagramas de bloques estáticos con sus interfaces, agrupados en subsistemas, corresponden en versión simplificada diagramas de clases o paquetes de UML.( simplificado en que sólo mostraban las asociaciones que se utilizaban para comunicaciones).

Producto del trabajo de las actividades de diseño era una descripción de arquitectura de software y la biblioteca de mensajes. ◦ Ingenieros preparaban Diagramas de Secuencia o bien

un Diagrama de Colaboración . Estos mostraban como los bloques se comunicaban dinámicamente para llevar acabo los casos de uso.

◦ Preparaban un grafo de transición de estados ( versión simplifacada de los diagramas de actividad de UML).

En esencia el método que utilizaban era el que hoy conocemos como desarrollo basado en componentes . Ivar Jacobson fue el creador de este método de desarrollo. Él dirigió su evolución hacia un proceso de desarrollo de software durante muchos años en el período anterior a Objectory.

En 1976, por parte del CCITT( Organismo Internacional para la estandarización en el área de las telecomunicaciones). Se publico el Lenguaje de Especificación y Descripción, SDL). Un conjunto de bloques que se comunicaban unos con otros a través de “mensajes” llamados señales en el estándar.

Un proceso(denominado clase) poseía instancias de manera muy parecida a las que se hacen en las clases en términos de orientación de objetos. Las instancias de los procesos interactuaban mediante mensajes.

SDL proponía diagramas que eran especializaciones de lo que hoy UML llama diagramas de clases , diagramas de actividad, diagramas de colaboración y diagramas de secuencia.

En 1987, Ivar Jacobson dejo Ericsson y fundo Objectory AB en Estocolmo. Objectory abreviatura de “Object Factory” .

Se había desarrollado una técnica de representación Caso de Uso.

Los flujos de trabajo sucesivos se representaron en una serie de modelos: requisitos –casos de uso, análisis, diseño, implementación y prueba.

El proceso de desarrollo de software Objectory era un producto de ingeniería era una característica única.

Rational Software compró Objectory AB en 1995. 1981, James E. Archer Junior y Michael T. Devlin, se

dispuso crear un entorno interactivo que mejoraría la productividad en el desarrollo de grandes sistemas de software. “ el diseño orientado a objetos, la abstracción, la ocultación de la información, la reutilización y el prototipado”.

La contribución más importante al proceso fueron el énfasis a la arquitectura y el desarrollo iterativo.

Representación de una arquitectura con cuatro vistas : la vista lógica, la vista de procesos, la vista física y la vista de desarrollo.Adicionalmente una vista que agrupaba mediantes casos de uso o escenarios.

El método de cuatro fases:

1996, Principios fundamentales de Booch : ◦ “Un estilo de desarrollo dirigido por la arquitectura

es normalmente la aproximación para la creación de la mayoría de los proyectos complejos muy basados en el software”. ◦ “Para que un proyecto orientado a objetos tenga

éxito, debe aplicarse un proceso iterativo e incremental”.

Estaba desarrollado correctamente en áreas como el modelado de casos de uso, análisis y diseño, aunque en otras áreas- gestión de requisitos, aparte de los casos de uso-, implementación y pruebas- no estaba bien desarrollados.

Poco sobre gestión del proyecto, gestión de la configuración , distribución, y sobre la preparación del entorno de desarrollo( obtención del proceso y las herramientas).

Se representa la arquitectura como vistas arquitectónicas de los modelos. Se amplia el modelo iterativo

El lenguaje de modelado Proceso incorporado fue el lenguaje de modelado del Proceso Objectory de Rational ( Rational Objectory Process, ROP).

Grady Booch autor del método Booch, James Rumbaugh era el desarrollador principal de OMT( Object Modelling Technique) creado en el centro de Investigación y Desarrollo de General Electric. Ambos publicaron la versión 0.8 del Método Unificado en Oct. 1995.con la incorporación de Ivar Jacobson a Rational.

Los tres publicaron 0.9 del Lenguaje Unificado de Modelado. En 1997 después de pasar por el proceso de estandarización , el Object Management Group público como estándar la versión 1.1. de UML.

El proceso se amplio con un nuevo flujo de trabajo para el modelado de negocio, basado en que se utiliza para obtener los requisitos a partir de los procesos de negocio.

En junio, Rational publico una versión del producto, El proceso Unificado de Rational 5.0.

1.Proporcionar una guía del orden de las actividades de los equipos.

2. Especificar cuales artefactos deben ser desarrollados y cuando estos deben ser desarrollados.

3. Dirigir las tareas de desarrolladores individuales y equipos como una sola.

4. Ofrecer criterios para monitorear y medir los productos y actividades del proyecto.

1. Desarrollo iterativo. 2. Administración de requerimientos. 3. Arquitectura basada en componentes. 4. Modelado Visual. 5. Verificación de la calidad. 6. Control de cambios

El desarrollo iterativo propone una planeación inicial y posteriormente entrar a un ciclo en las etapas de desarrollo. Donde para cada iteración resulte une versión ejecutable del sistema.

1. Tolerable a cambios en los requerimientos. 2. Los elementos son integrados progresivamente. 3. Los riesgos son mitigados en etapas tempranas. 4. Permite a la organización aprender e improvisar. 5. Facilita el reuso, porque es fácil identificar partes comunes

diseñadas o implementadas. 6. Resulta un producto más robusto, ya que los errores se van

corrigiendo en cada iteración. 7. El proceso puede ser improvisado y refinado en el desarrollo.

• Un requerimiento es una condición o capacidad con el que un sistema debe conformarse.

• La administración de requerimientos es una aproximación

sistemática para la búsqueda, documentación, organización y seguimiento de los cambios en los requerimientos de un sistema.

• El manejo de los requerimientos de software debe de ser

dinámico: debe esperarse que estos cambien durante la vida de un proyecto de software.

Uno de los principales objetivos de las primeras iteraciones es obtener una arquitectura de software válida, donde en ciclos iniciales de desarrollo formen un prototipo ejecutable de la arquitectura que gradualmente se vaya conviertiendo en el sistema final en las últimas iteraciones.

Permite una arquitectura modular. Diseño de componentes reusables. Aprovechamiento de infraestructuras comer ciales (COM, CORBA, JavaBeans).

Un modelo es una simplificación de la realidad que describe completamente un sistema desde una perspectiva particular.

El modelado es importante porque ayuda al

equipo a visualizar, especificar, construir y documentar la estructura y el comportamiento de la arquitectura del sistema.

Un Modelo, correctamente diseñado usando tecnología de objetos: • Es fácil de entender. Claramente corresponde a la realidad. • Fácil de modificar. Cambios en un aspecto en particular concierne únicamente al objeto que representa ese aspecto. Se implementa a través de UML

• Los problemas del software son de 100 a 1000 veces más difíciles de encontrar y reparar (y por tanto más caros) después del desarrollo.

• La verificación y administración de la calidad durante el ciclo de vida del proyecto es esencial para lograr mantener los objetivos y el tiempo estimado de desarrollo

• Si no existe una disciplina de control, el proceso de desarrollo rápidamente degenera en caos.

• La coordinación de las actividades y artefactos de los desarrolladores y equipos, involucra establecer flujos repetibles para administración de cambios al software. Esta coordinación permite una mejor identificación de los recursos básicos en las prioridades y riesgos del proyecto.

• El control de cambios es más que revisar entradas y salidas en los

archivos. Este incluye administrar los flujos, el desarrollo paralelo, la integración y la construcción del software

El RUP organiza a los proyectos en términos de flujos de trabajo y fases, las cuales consisten de una o más iteraciones. En cada iteración, el énfasis en cada flujo de trabajo variará a lo largo del ciclo de vida.

• Es un esqueleto del proceso a desarrollar. • Iterativo e incremental. • Maneja Casos de Uso. • Es diseñado para ser flexible y extensible • Permite una variedad de estrategias de ciclos de vida. • Elegir que "artefactos" producir. • Define actividades y trabajadores. • No es un Proceso Universal.