METODOLOGÍA RUP

Rational Unified Process (RUP)

La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software:

• Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
• Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
• Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
• Transmisión, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.

Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:

Disciplina de Desarrollo

• Ingeniería de Negocios: Entendiendo las necesidades del negocio.

• Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.

• Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.

• Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.

• Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente.

Disciplina de Soporte

• Configuración y administración del cambio: Guardando todas las versiones del proyecto.

• Administrando el proyecto: Administrando horarios y recursos.

• Ambiente: Administrando el ambiente de desarrollo.

• Distribución: Hacer todo lo necesario para la salida del proyecto

  Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración.
  
  Los elementos del RUP son:
  
  

  • Actividades, Son los procesos que se llegan a determinar en cada iteración.

  • Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.

  • Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

  
  

  Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.
  
  
  

  Extreme Programing (XP)
  
  Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.
  

  MSF tiene las siguientes características:
  
  

  • Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.

  • Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.

  • Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

  • Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.

  MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y finalmente el modelo de Aplicación.
  
  
  

  • Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones.
    
    

  • Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.
    
    

  • Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberación de versiones y explicando su relación con el Modelo de equipo.
    
    

  • Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar.
    
    

  • Modelo de Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores.
    
    

  • Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores.

  
  

  
  

METODOLOGÍA OMT

La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric.

OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácterde abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.

Las fases que conforman a la metodología OMT son:

• Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos.
• Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
• Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.).
• Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad.

La metodología OMT emplea tres clases de modelos para describir el sistema:

• Modelo de objetos. Describe la estructura estática de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicación. Se representa mediante diagramas de onjetos.
• Modelo dinámico. Describe los aspectos de un sistema que tratan de la temporización y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organización de sucesos y estados. Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que están implementadas. Se representa gráficamente mediante diagramas de estado.
• Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos

Modelo de Objetos

Esta es la parte principal de la Técnica para modelado ya que se fundamenta en la teoría de OO. La definición clara de las entidades que intervienen en el sistema es un paso inicial necesario para poder definir qué transformaciones ocurren en ellas y cuándo se producen estas transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su jerarquía determinan el sistema.

Los diagramas de objetos permiten representar gráficamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y que permitirán la creación de casos concretos, los diagramas de casos concretos describen la manera en que los objetos del sistema se relacionan y los casos concretos que existen en el sistema de cada clase. En los diagramas que componen este modelo se pueden representar los siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o asociaciones.

Clases y Objetos

Los objetos y sus componentes se representan gráficamente en OMT de forma que es posible obtener una idea de los elementos que intervienen en el sistema estudiando el modelo. Los elementos y sus características con representación gráfica son los siguientes:

• Objetos. Un objeto es, sencillamente, algo que tiene sentido en el contexto de la aplicación. Se definirá un objeto como un concepto, abstracción o cosa con límites bien definidos y con significado a efectos del problema que se tenga entre manos.
• Clases. Describe un grupo de objetos con propiedades (atributos) similares, con relaciones comunes con otros y con una semántica común.
• Diagramas de objetos. Proporcionan un anotación gráfica formal para el modelado de objetos, clases y sus relaciones entre sí, son útiles, tanto para el modelado abstracto como, para diseñar programas reales. Hay dos tipos de diagramas de objetos

-Diagrama de clases. Esquema, patrón o plantilla para describir muchas instancias de datos posibles.

-Diagrama de instancias. Describe la forma en que un cierto conjunto de objetos se relacionan entre sí.

• Atributos. Los objetos pertenecientes a una clase presentan características que en OMT se denominan atributos. Sin embargo, no se deben de confundir los atributos, que son características que todos los objetos de una clase comparten, con otros objetos que pueden formar parte del objeto que estamos tratando.
• Operaciones y métodos. Del mismo modo que los objetos en OMT se pueden representar las operaciones que se realizan sobre ellos o que éstos realizan sobre otros objetos del sistema. Los objetos realizan acciones sobre otros objetos y definen acciones que se realizan sobre ellos mismos. Los objetos de una misma clase comparten estas operaciones, aunque también pueden añadir otras nuevas que no se definan en su clase a medida que se especializa el objeto en otras subclases. También pueden redefinir las operaciones en estas especializaciones ignorando las definiciones realizadas en las superclases. Las operaciones pueden llevar implícito el objeto sobre el que se realizan o que realiza la acción, de forma que es posible tener una misma operación que se efectúe de manera distinta según el objeto sobre el que se aplique. La implementación de las operaciones para cada uno de los objetos diferentes (o subclases) se denomina método. Los métodos implementan en cada una de las clases de forma específica para los objetos que representa.

• Enlaces y Asociaciones

  Las relaciones entre clases determinan el comportamiento del sistema y constituyen una parte muy importante del mismo ya que mediante las relaciones definimos la forma en que los objetos se comunican, lo que también se conoce como comportamiento.

  Además las relaciones tienen una serie de características que son de interés para el modelado del sistema.

  • Relaciones. En OMT se identifican a través de enlaces: conexiones físicas o conceptuales entre casos concretos de objetos. Una asociación en OMT abstrae un conjunto de enlaces con una estructura y un significado comunes. Desde el punto de vista de la implementación, una asociación es un puntero que apunta desde un objeto a otro.
  • Multiplicidad. Este término se encuentra relacionado con las asociaciones e indica el número de casos concretos de una clase que puede relacionarse con otro caso concreto. Las relaciones más frecuentes son las binarias, aunque pueden darse de cualquier orden.

  Conceptos Avanzados de Enlaces y Asociaciones

  • Atributos de los enlaces. Los enlaces así como los objetos pueden tener atributos, que son propiedades de los enlaces de una asociación.
  • Modelado de una asociación en forma de clase. A veces resulta conveniente modelar las asociaciones como clases en lugar de cómo relaciones, cuando los enlaces pueden participar en asociaciones con otros objetos o están sometidos a operaciones.
  • Clasificación. También podemos encontrar en una asociación de objetos que pertenecen a una clase con multiplicidad "muchos" que deben estar ordenados. Esta característica de los objetos es una restricción, ya que implica una condición que deben cumplir los elementos de la clase.
  • Nombre de rol. Las asociaciones conectan clases u objetos que pertenecen a dichas clases, pero en ocasiones necesitamos restringir el conjunto de los objetos que se relacionan dentro de la clase. Mediante estas restricciones podemos especificar qué objetos se relacionan. Podemos conseguir este objetivo mediante los llamados nombres de rol. Un nombre de rol es un atributo derivado de una clase cuyo valor es un conjunto de objetos relacionados. Los nombres de rol se utilizan cuando las asociaciones se producen entre objetos de la misma clase ya que suelen producirse entre subconjuntos de esas clases. Una asociación binaria puede tener dos roles, uno por cada extremo de la asociación que son identificados por sus nombres.
  • Cualificación. Las asociaciones muchos a muchos y uno a muchos pueden ser calificadas mediante un elemento calificador que reduce el conjunto de objetos relacionados, indicando un subconjunto de la clase que se califica en la asociación. Las asociaciones que se pueden calificar son las de multiplicidad uno a muchos y muchos a muchos.
  • Agregación. Las relaciones de agregación son para OMT formas de asociación del tipo "es parte de", como tales se definen entre una clase agregado y una clase componente y se indican con un rombo en la parte de la clase que actúa como continente. Las relaciones de agregación se establecen en los llamados objetos compuestos que contienen otros objetos y éstos pueden ser de dos tipos: aquellos que tienen existencia físicamás allá del objeto agregado, y los que no pueden existir sin el objeto agregado.

  Generalización y Herencia

  En el paradigma de la orientación a objetos uno de los elementos más importantes es la herencia. La cualidad que permite que los objetos hereden las características (atributos) y las operaciones (métodos) dentro de una estructura jerárquica conlleva una serie de consecuencias de máxima relevancia a la hora de diseñar un sistema informático. Los objetos heredan un comportamiento que puede ser modificado y unas estructuras de datos de forma que se permite y se facilita la reutilización de las clases y del código que implementa sus funcionalidades.

  Ambos conceptos van unidos: herencia y estructura jerárquica, de forma que la herencia se produce por la existencia de una estructura entre los componentes del sistema y la estructura se consigue en la implementación del código a través de la herencia en los lenguajes OO.

  La herencia está íntimamente relacionada con la forma concreta en que un lenguaje implementa la generalización, que es un término más abstracto.

  • La generalización es la relación que existe entre una clase y las subclases que se derivan de la misma. A partir de una versión "en bruto" se generan versiones más especializadas de la misma que añaden características y operaciones. La superclase es la versión general y las subclases son especializaciones de la superclase. Las generalizaciones pueden tener discriminadores que indican qué aspecto de la superclase está siendo utilizado para obtener subclases más concretas.
  • Anulación. Al implementar la herencia nos encontramos en numerosas ocasiones que las subclases redefinen operaciones que ya han sido definidas en las superclases. Las razones para esta nueva implementación de operaciones que existen en las superclases son variadas, a veces simplemente se le añaden nuevas acciones que van en consonancia con las nuevas características que añade la subclase; otras, se consigue optimizar las operaciones debido a que las subclases tienen características nuevas que lo permiten, y a veces se produce por una mala práctica de análisis donde no se prevén las operaciones de manera óptima.

  Se han propuesto una serie de reglas a la hora de implementar la herencia para minimizar los errores y maximizar la reutilización de código:

  1. Las operaciones de consulta, aquellas que no modifican valores de atributos, se heredan por todas las subclases.
  2. Las operaciones de actualización, que modifican valores de atributos, se heredan por todas las subclases y se añaden las nuevas operaciones para aquellas que añadan atributos.
  3. Las operaciones de actualización que se realizan sobre atributos que tengan algún tipo de restricción o asociación, se bloquean para nuevas subclases.
  4. Las operaciones no pueden volver a definirse para hacer que se comporten de distinta manera de cara al exterior, es decir; todos los métodos concretos de una operación deben tener el mismo protocolo.
  5. Las operaciones se pueden refinar añadiendo comportamientos en las subclases.

  Agrupación de entidades

  Los elementos que hemos estudiado en el Modelo de Objetos se pueden agrupar para construir el modelo completo, así, las clases, las asociaciones y las generalizaciones forman lo que se denomina módulo y varios módulos forman el modelo de objetos. En un módulo no se deben repetir los nombres de las clases y de las asociaciones, aunque se puede hacer referencia a la misma clase dentro de distintos módulos. También se definen las denominadas hojas que se utilizan para descompones un Modelo de Objetos en unidades que podemos manejar. Una hoja es una parte de un módulo que podemos manejar con facilidad, sea en el formato que sea.

  Modelo Avanzado de Datos

  • Clases abstractas. En ocasiones puede ser de utilidad tener clases que definan propiedades y operaciones de forma general, dejando para sucesivos refinamientos la implementación concreta de las mismas. Una clase abstracta es precisamente una clase donde se introducen métodos y datos que se definirán en las subclases de la misma. Las clases abstractas siempre tienen que tener clases derivadas donde se especificarán las operaciones que no se hayan definido en la clase abstracta, nunca podrán tener objetos, se utilizan como clases bases o superclases de otras clases. La existencia de este tipo de clases facilita aún más la posibilidad de abstracción del modelo, dejando para posteriores refinamientos del problema la definición más exhaustiva de operaciones y datos. La implementación concreta de las clases abstractas depende del lenguaje OO. En OMT una clase abstracta se identifica cuando no tiene casos concretos (instancias) pero una subclase suya sí los tiene. Por ejemplo, una clase abstracta números podría definir una operación multiplicar que no se implementara hasta la definición de las subclases números enteros, números reales y números complejos, teniendo la información precisa en cada una de las subclases de la forma en que se multiplican los números.
  • Herencia múltiple. La herencia múltiple es una característica que algunos sistemas OO poseen, mediante la cual es posible que una clase herede de varias superclases al mismo tiempo. Sin embargo, la herencia múltiple aumenta radicalmente la complejidad de los sistemas que la implementan ya que la búsqueda de las operaciones se dificulta cuando no se define en la clase derivada y hay que realizarla en las superclases.
  • Clave candidata. No es más que un conjunto mínimo de atributos que define de forma única un objeto o enlace. Es decir, mediante una clave candidata tenemos definido el objeto o el enlace con una serie de atributos de forma que se distingue del resto de objetos o enlaces. Las claves candidatas son restricciones y, por tanto, se representan como tales en OMT. Para encontrar una clave candidata en una asociación donde intervienen más de dos clases, debemos definir qué combinaciones de clases o enlaces en la asociación de los elementos definen la tercera clase o enlace de forma única.
  • Restricciones. El modelo de objetos contiene diferentes entidades como son los objetos, las clases, los atributos, los enlaces y las asociaciones. Cada una de estas entidades tiene una serie de características inherentes a su naturaleza dentro del sistema que estamos modelando. Las características definen su significado dentro del sistema y también sus limitaciones. Estas limitaciones se denominan en el Análisis restricciones. Las restricciones pueden ser muy complejas y en este caso no pueden estudiarse en el modelo de objetos, sino que se especificarán en el modelo funcional. Las que intervienen en el modelo de objetos se representan mediante llaves junto a la entidad a que se refieran. Cuando la restricción implica más de una clase, se indica mediante una flecha discontinua que une los elementos que se vean implicados en la restricción. Las asociaciones también pueden tener restricciones.

  Construcción de un modelo de objetos

  • Identificar las clases de objetos.
  • Iniciar un diccionario de datos que contenga descripciones de clases, atributos y asociaciones.
  • Agregar asociaciones entre clases.
  • Agregar atributos a objetos y ligas.
  • Organizar y simplificar las clases de objetos usando herencia.
  • Probar las rutas de acceso usando escenarios e iterar los pasos anteriores según sea necesario.
  • Agrupar las clases en módulos, basándose en "acoplamiento cercano" y función relacionada.

METODOLOGÍA UML

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas desoftware 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.

CASO DE USO

http://cid-f5a877f77726c407.skydrive.live.com/browse.aspx/TRABAJOSUML?uc=1