Metodología RUP y Metodología UML

Metodología RUP:

El proceso de desarrollo RUP (Rational Unified Process) aplica varias de las mejores practicas en el desarrollo moderno de software en una forma que se adapta a un amplio rango de proyectos y organizaciones. Provee a cada miembro del equipo, un fácil acceso a una base de conocimiento con guías., plantillas y herramientas para todas las actividades criticas del desarrollo de software. Esta metodología permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cómo desarrollar el software utilizando un lenguaje modelado común: UML.

El RUP es un proceso de desarrollo de software:

Provee un enfoque estructurado para realizar tareas y responsabilidades en una organización de desarrollo. Su principal objetivo es asegurar la producción de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible.

El RUP es un producto:

IBM comercializa un producto que permite instanciar al RUP según las características del proyecto, siendo una referencia en la metodología que sirve como repositorio único de información.

El RUP es un marco de trabajo (Framework):

Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organización que lo utilice seleccionando las fases y interacciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos (artifacts) que se van a construir. Es importante conocer como esta organizado y estructurado el proceso para poder seleccionar el frame work, los elementos del proceso que mas valor darán al proyecto.

El RUP incorpora muchas de las conocidas como “buenas practicas” en el desarrollo de software moderno, lasa cuáles se deben tener presentes en el desarrollo de aplicaciones empresariales para garantizar el éxito del proyecto, tales como: Desarrollo iterativo, Gestión de Requerimientos, Arquitectura basada en componentes, Modelo Visual, Verificación de la calidad en forma continua y control de cambios.

El RUP presenta 3 características que constituyen la esencia de todo el proceso de desarrollo:

1. Dirigido por los casos de uso.
2. Centrado en la arquitectura.
3. Ciclo de vida iterativo.

Otras características o ventajas de la aplicación de esta metodología son las siguientes:

• Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio
• Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema
• Reduce el costo del riesgo a los costos de un solo incremento
• Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo
• Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración.
• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño

El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos y un conjunto de “artefactos” definidos que deben alcanzarse. La duración de cada fase depende del equipo y del producto a generar.
A su vez, cada fase puede tener una o más iteraciones y cada iteración sigue el modelo en cascada pasando por las distintas disciplinas. Cada iteración termina con una liberación del producto.

Las fases son las siguientes:

1) Inicio
2) Elaboración
3) Construcción
4) transición

Metodología UML:

La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST (Modeling and Analysis Suite for Real-Time Applications), que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Arquitectura bajo capas

Link Arquitectura bajo capas:

http://docs.google.com/Presentation?id=dgvxhrnv_113hh7qgxcg

Taller 4 junio UML

Link esquema de 3 capas:

http://docs.google.com/Presentation?id=dgvxhrnv_945pvjw6cq

Link de la Exposicion de UML en ppt

Link Exposicion:

http://docs.google.com/Presentation?id=dgvxhrnv_65d4xv8fg6

Abstract

Introducción:

The following diagram will discuss components that is a component of its features, will have pictures and videos related to this type of diagram, so that from this, and know better how to deploy the system development software.

Definición, Características y Palabras Claves

Definición:

Explicación del Tema:

Un diagrama de componentes es un diagrama tipo del lenguaje unificado .Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, librerías compartidas, módulo, ejecutables, paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura del software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Aquí tenemos un componente del sistema de Windows. En el diagrama de componenetes de Windows debe salir este componente, ya que sin el sistema no funcionaría.

}

En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representación anterior es incorrecta, pero no es así solo corresponde a un nivel diferente de detalle. Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standard que define UML son:

• Executable
• Library
• Table
• File
• Document

Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensión).
Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas.

• Ejecutables y bibliotecas.
• Tablas.
• API
• Código fuente.
• Hojas HTML.

Ejecutables:

Nos facilita la districución de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable que solo se necesita a el mismo para funcionar no necesitaremos el diagrama d ecomponentes. Los pasos a seguir para modelar, a priori no a porteriori, son:

• Indentificar los componentes, las participaciones del sistema, cuales son factibles de ser reutilizadas. Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar.
• Identificar cada componente con su estereotipo correspondiente.
• Considerar las relaciones entre componentes.

En este gráfico se muestra un ejecutable que utiliza dos librerías, estas dos librerías disoponen de su interface con el que ofrecen el acceso a sus servicios. Se pueden ver que estas librerías son coponentes que pueden ser reutilizados en otras partes del sistema.

Código fuente:

Se utiliza para documentar las dependencias de los diferentes ficheros de código fuente. Un ejecutable, o librería es una combinación de estos ficheros, y al mostrar la dependencia entre ellos obtenemos una visión de las partes necesarias para la creación del ejecutable o librería.
Al tener documentadas las relaciones se pueden realizar cambios en el código de un archivo teniendo en cuenta donde se utiliza, y que otros ficheros pueden verse afectados por su modificación.

Aquí tenemos la relación entre los diferentes ficheros de un sistema. Cada fichero Cpp utiliza su fichero .h correspondiente, y MiServicio.h utiliza NTService.h u Stdio.h.

Características:

1. Un componente debe tener un nombre por ejemplo (cliente o camino).
2. Un componente tiene características similares a una clase (nombre, tiene interfaces, puede participar en relaciones.
3. Representa un elemento físico en bits.
4. Representa nodos físicos.
5. Las operaciones de los componentes se alcanzan por la interface.

Palabras Claves:

• Nodos
• Componentes
• Dependencias
• Ejecutables
  

Video y Imagenes