Resumen Del Libro UML (hasta Capitulo 6)

Resumen Libro:

Un proceso se define quien esta haciendo que, cuando y como alcanzar un determinado objetivo. Un proceso deberia ser capaz de evolucionar durante muchos años y durante esta evolucion deberia limitar su alcance, en un momento del tiempo dado a las realidades que permitan las tecnologías, herramientas, personas y patrones de organización.

Tecnologías: El proceso debe contruirse dobre las tecnologías disponibles en el momento en que se va a emplear el proceso.

Herramientas: Los procesos y las herramientas deben desarrollarse en paralelo. Un proceso ampliamente utilizado puede soportyar la inversion necesaria para crear herramientas que lo soporten.

Personas: un creador del proceso debe limitar el conjunto de habilidades necesarias para trabajar en el proceso a las habilidades de los desarrolladores actuales poseen, o apuntar a aquellas que los desarrolladores puedan obtener rapidamente.

Patrones de organización: el creador del proceso debe adaptar el proceso a las realidades del momento.

Historia del proceso unificado:

El proceso unificado esta equilibrado por ser el producto final de tres decadas de desarrollo y uso practico. Su desarrollo como producto sigue un camino desde el proceso Objectory pasando por el Proceso Objectory de Racional hasta el proceso unificado de Rational. Su desarrollo ha recibido influencias de muchas fuentes.

El metodo racional:

Rational Software Corporation compro Objectory AB a finales de 1995 y la tarea de unificar los principios basicos en los procesos de desarrollo existentes adquirio una urgencia especial. En 1981 rational se dispuso a crear un entorno interactivo que mejoraria la productividad en el desarrollo de grandes sistemas de software. A continuación dijeron que en este esfuerzo, eran importantes el diseño orientado a objetos, la abstracción, la ocultación de la información, la reutilización y el prototipazo.

Make Devlin escribio un articulo introductoria sobre un proseso de desarrollo iterativo dirigido por la arquitectura. Un articulo sobre una representación de la arquitectura con cuatro vistas: la vista logica, la vista de procesos, la vista fisica, y la vista de desarrollo, mas una vista adicional que ilustraba cuatro vistas mediante casos de uso o escenarios. La idea de tener un conjunto de vistas, en lugar de tratar de meter todo en un unico tipo de diagrama, nacio de la experiencia de Kruchten en varios proyectos grandes.

Booch estaba presente desde los principios de Rational, y en 1996 en uno de sus libros menciono dos “principios fundamentales” sobre la arquitectura y la iteración:

* ”Un estilo de desarrollo dirigido por la arquitectura es normalmente la mejor aproximación para la creación de la mayoria de los proyectos complejos muy basados en el soft”

* “Para que un proyecto orientado a objetos tenga éxito, debe aplicarse un proceso iterativo e incremental”

Capitulo 1:

El proceso unificado en pocas palabras:

El proceso unificado es un proceso de desarrollo de software. Un PROCESO de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. El proceso unificado es un marco de trabajo generico que puede especializarce para una gran variedad de sistemas de soft.

El UP esta basado en componentes, el sistema de soft en construccion esta formado por componentes de software interconectados atraves de interfaces bien definidas.

Los verdaderos aspectos definitorios del PU se resumen en tres frases clave: Dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental.

El proceso unificado esta dirigidos por casos de uso:

El termino de usuario no solo hace referencia a los usuarios humanos sino a otros sistemas que interactuan con el sistema que estamos desarrollando.

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad total del sistema. Los casos de uso ademas guian el proceso de desarrollo. Basandose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso.

El proceso unificado esta centrado en la arquitectura:

La arquitectura en un sistema de software se describe mediante diferentes vistas del sistema en construcción.

El concepto de arquitectura de soft incluye los aspectos estáticos y dinámicos más significativos del sistema.

La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende en parte de una valoración que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de las personas que se hayan responsabilizado de su creación. No obstante, el proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad de la adaptación al cambio, y la reutilización.

Cada producto tiene tanto una función como una forma. En esta situación la función corresponde a los casos de uso y la forma a la arquitectura. Debe haber interacción entre los casos de uso y la arquitectura. Por un lado los casos de uso deben encajar en la arquitectura pero por otro lado la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. En realidad tanto la arquitectura como los casos de uso deben evolucionar en paralelo.

De manera resumida podemos decir que el arquitecto:

• crea un esquema en borrador de la arquitectura, comenzando por la parte de la arquitectura que no es especificada de los casos de uso. Aunque esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe poseer una comprensión gral de los casos de uso antes de comenzar con la creación del esquema arquitectonico.

• A continuación, el arquitecto trabaja con un subconjunto de los casos de uso especificados, con ellos representa las funciones clave del sistema en desarrollo. Cada caso de uso seleccionado se especifica y se realiza en terminos de subsistemas, clases, y componentes.

• A medida que los casos de uso se especifican y maduran, se descrubre mas de la arquitectura.

Este proceso continua hasta que se considere que la arquitectura es estable.

El UP es iterativo e incremental:

Es practico dividir el trabajo en partes mas pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las

...