Vous êtes sur la page 1sur 33

Ing. Elmer Arturo Carballo Ruiz.

Tecnologa Orientada a Objetos


TOO115

Historia del Proceso Unificado


Mtodo Ericcson
El lenguaje de Descripcin y Especificacin
Proyecto Objectory
El mtodo Rational
El lenguaje de Modelado Unificado ( UML)
El Proceso Unificado de Rational

Proporcionar una visin 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 races profundas en palabras


de Peter F. Drucker, es una innovacin 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 ms bajo nivel en subsistemas de
ms alto nivel. Identificaban los bloques estudiando los
casos de negocio-hoy conocidos como casos de usopreviamente especificados.
Actividades de diseo producan conjunto de diagramas de
bloques estticos con sus interfaces, agrupados en
subsistemas, corresponden en versin simplificada
diagramas de clases o paquetes de UML.( simplificado en
que slo mostraban las asociaciones que se utilizaban para
comunicaciones).

Producto del trabajo de las actividades de diseo


era una descripcin de arquitectura de software y

la biblioteca de mensajes.

Ingenieros preparaban Diagramas de Secuencia o bien


un Diagrama de Colaboracin . Estos mostraban como
los bloques se comunicaban dinmicamente para llevar
acabo los casos de uso.
Preparaban un grafo de transicin de estados ( versin
simplifacada de los diagramas de actividad de UML).

En esencia el mtodo que utilizaban era el que hoy


conocemos como desarrollo basado en componentes
. Ivar Jacobson fue el creador de este mtodo de
desarrollo. l dirigi su evolucin hacia un proceso de
desarrollo de software durante muchos aos en el
perodo anterior a Objectory.

En 1976, por parte del CCITT( Organismo


Internacional para la estandarizacin en el rea de las
telecomunicaciones). Se publico el Lenguaje de
Especificacin y Descripcin, SDL). Un conjunto de
bloques que se comunicaban unos con otros a travs
de mensajes llamados seales en el estndar.
Un proceso(denominado clase) posea instancias de
manera muy parecida a las que se hacen en las clases
en trminos de orientacin de objetos. Las instancias
de los procesos interactuaban mediante mensajes.
SDL propona diagramas que eran especializaciones
de lo que hoy UML llama diagramas de clases ,
diagramas de actividad, diagramas de colaboracin y
diagramas de secuencia.

En 1987, Ivar Jacobson dejo Ericsson y fundo


Objectory AB en Estocolmo. Objectory abreviatura de
Object Factory .
Se haba desarrollado una tcnica de representacin
Caso de Uso.
Los flujos de trabajo sucesivos se representaron en
una serie de modelos: requisitos casos de uso,
anlisis, diseo, implementacin y prueba.

El proceso de desarrollo de software


Objectory era un producto de ingeniera era
una caracterstica nica.

Rational Software compr Objectory AB en 1995.


1981, James E. Archer Junior y Michael T. Devlin, se
dispuso crear un entorno interactivo que mejorara la
productividad en el desarrollo de grandes sistemas
de software. el diseo orientado a objetos, la
abstraccin, la ocultacin de la informacin, la
reutilizacin y el prototipado.
La contribucin ms importante al proceso fueron el
nfasis a la arquitectura y el desarrollo iterativo.

Representacin de una arquitectura con cuatro vistas


: la vista lgica, la vista de procesos, la vista fsica y
la vista de desarrollo.Adicionalmente una vista que
agrupaba mediantes casos de uso o escenarios.

El mtodo de cuatro fases:

1996, Principios fundamentales de Booch :

Un estilo de desarrollo dirigido por la arquitectura


es normalmente la aproximacin para la creacin
de la mayora 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, anlisis y diseo, aunque en
otras reas- gestin de requisitos, aparte de los casos de
uso-, implementacin y pruebas- no estaba bien
desarrollados.
Poco sobre gestin del proyecto, gestin de la
configuracin , distribucin, y sobre la preparacin del
entorno de desarrollo( obtencin del proceso y las
herramientas).
Se representa la arquitectura como vistas arquitectnicas
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 mtodo Booch, James


Rumbaugh era el desarrollador principal de OMT(
Object Modelling Technique) creado en el centro
de Investigacin y Desarrollo de General Electric.
Ambos publicaron la versin 0.8 del Mtodo
Unificado en Oct. 1995.con la incorporacin de
Ivar Jacobson a Rational.
Los tres publicaron 0.9 del Lenguaje Unificado de
Modelado. En 1997 despus de pasar por el
proceso de estandarizacin , el Object
Management Group pblico como estndar la
versin 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 versin del
producto, El proceso Unificado de Rational
5.0.

1.Proporcionar una gua 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.
2.
3.
4.
5.
6.

Desarrollo iterativo.
Administracin de requerimientos.
Arquitectura basada en componentes.
Modelado Visual.
Verificacin de la calidad.
Control de cambios

El desarrollo iterativo propone una planeacin


inicial y posteriormente entrar a un ciclo en las
etapas de desarrollo. Donde para cada
iteracin resulte une versin ejecutable del
sistema.

1.
2.
3.
4.
5.

Tolerable a cambios en los requerimientos.


Los elementos son integrados progresivamente.
Los riesgos son mitigados en etapas tempranas.
Permite a la organizacin aprender e improvisar.
Facilita el reuso, porque es fcil identificar partes comunes
diseadas o implementadas.
6. Resulta un producto ms robusto, ya que los errores se van
corrigiendo en cada iteracin.
7. El proceso puede ser improvisado y refinado en el desarrollo.

Un requerimiento es una condicin o capacidad con el que un


sistema debe conformarse.
La administracin de requerimientos es una aproximacin
sistemtica para la bsqueda, documentacin, organizacin y
seguimiento de los cambios en los requerimientos de un
sistema.
El manejo de los requerimientos de software debe de ser
dinmico: 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 vlida, 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.


Diseo de componentes reusables.
Aprovechamiento de infraestructuras comer
ciales (COM, CORBA, JavaBeans).

Un modelo es una simplificacin 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 diseado usando tecnologa de objetos:

Es fcil de entender. Claramente


corresponde a la realidad.

Fcil de modificar. Cambios en un aspecto


en particular concierne
nicamente al objeto que representa ese
aspecto.
Se implementa a travs de UML

Los problemas del software son de 100 a 1000 veces ms difciles de


encontrar y reparar (y por tanto ms caros) despus del desarrollo.
La verificacin y administracin 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


rpidamente degenera en caos.
La coordinacin de las actividades y artefactos de los desarrolladores
y equipos, involucra establecer flujos repetibles para administracin
de cambios al software. Esta coordinacin permite una mejor
identificacin de los recursos bsicos en las prioridades y riesgos del
proyecto.
El control de cambios es ms que revisar entradas y salidas en los
archivos. Este incluye administrar los flujos, el desarrollo paralelo, la
integracin y la construccin del software

El RUP organiza a los proyectos en trminos


de flujos de trabajo y fases, las cuales
consisten de una o ms iteraciones. En cada
iteracin, 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 diseado 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.

Vous aimerez peut-être aussi