Concepto: Desarrollo de soluciones de componente
El desarrollo basado en componentes es una variación del desarrollo general de aplicaciones. En esta directriz, se utiliza el término "componente" para hacer referencia a componentes desplegables y desarrollados independientemente.
Descripción principal
Actividades a lo largo del ciclo vital:
  1. Introducción
  2. Actividades de la fase inicial
  3. Actividades de la fase de elaboración
  4. Actividades de la fase de construcción
  5. Actividades de la fase de transición
Temas adicionales:

Introducción

El desarrollo basado en componentes es una variación del desarrollo general de aplicaciones en el que:

  • La aplicación se ensambla a partir de componentes ejecutables discretos que se desarrollan y despliegan de forma relativamente independiente, potencialmente por equipos diferentes.
  • La aplicación se puede actualizar en incrementos más pequeños mediante la actualización de únicamente los componentes que componen la aplicación.
  • Los componentes se pueden compartir entre aplicaciones mediante la creación de oportunidades de reutilización, y también mediante la creación de dependencias entre proyectos.
  • Aunque no está estrictamente relacionado con el hecho de estar basado en componentes, las aplicaciones basadas en componentes suelen ser distribuidas.

En esta página, se utiliza el término "componente" para hacer referencia a componentes desplegables y desarrollados independientemente. En el resto de RUP, sin embargo, se utiliza en un sentido más general que se describe en Concepto: Componente y se califica como necesario.

La adaptación de Rational Unified Process (RUP) para manejar los retos del desarrollo basado en componentes se trata más abajo.

Actividades de la fase inicial

Se aplica el flujo de trabajo básico para la fase inicial, con las siguientes ampliaciones o variaciones:

Gestión de proyectos

  • Actividad: Concebir un proyecto nuevo
  • El foco de la Tarea: Desarrollar caso de negocio se ajusta para que tenga en cuenta que la utilización de componentes cambia la estructura de costes del desarrollo. Específicamente, el coste de desarrollar componentes disminuye, pero se necesita más esfuerzo para identificar componentes y comprobar que los componentes seleccionados satisfacen los requisitos.

  • Actividad: Evaluar el riesgo y el ámbito del proyecto
  • Al tomar el enfoque de un componente, cambia la naturaleza de determinados riesgos y se introducen riesgos nuevos. Específicamente:

    • los componentes de origen externo aumentan el riesgo porque introducen elementos críticos que no están bajo el control directo del equipo del proyecto
    • los componentes de origen externo pueden reducir el tiempo de desarrollo y, de este modo, reducir el riesgo de recursos
    • los componentes de origen externo pueden distorsionar la arquitectura del sistema si imponen restricciones arquitectónicas propias
  • Actividad: Planificar el proyecto
  • En la Tarea: Planear fases e iteraciones, el plan de la fase de construcción tiene el potencial para mostrar la división del proyecto en dos seguimientos diferentes pero paralelos: uno que desarrolla componentes específicos del dominio y específicos de la aplicación (organizado en las capas superiores de la arquitectura; consulte el apartado Concepto: Creación de capas) y otro que desarrolla los componentes que no son específicos del dominio ni de la aplicación y que se organizan en las capas inferiores. En algunos casos, los equipos de desarrollo gestionados independientemente desarrollarán componentes reutilizables. La decisión de introducir seguimientos paralelos es un aspecto de personal y recursos conducido por un deseo de gestionar componentes reutilizables como activos independientes de las aplicaciones en que se despliegan.

Requisitos

  • Actividad: Perfeccionar la definición del sistema
  • Cuando se perfeccionan los requisitos del sistema, deben capturarse las restricciones que impone la infraestructura del componente seleccionado. Las infraestructuras de componentes aumentan la productividad de desarrollo, en parte restringiendo los grados de libertad que se ofrecen al arquitecto y el diseñador de software. La Tarea: Detallar los requisitos de software debe centrarse en documentar estas restricciones.

Prueba

Entorno

  • Actividad: Preparar el entorno para el proyecto
  • Cuando recopile y prepare directrices para el proyecto, consulte la Tarea: Preparar directrices para el proyecto para obtener detalles, tenga en cuenta la infraestructura de componentes específica y las restricciones que impone. Las directrices deben incluir cómo diseñar y codificar utilizando la infraestructura. También deberían proporcionar instrucciones de prueba sobre cómo comprobar la conformidad con la infraestructura de componentes y las interfaces definidas entre componentes.

Actividades de la fase de elaboración

Se aplica el flujo de trabajo básico para la fase de elaboración, con las siguientes ampliaciones o variaciones:

Requisitos

  • Actividad: Perfeccionar la definición del sistema
  • La Tarea: Detallar los requisitos de software también se centra en las restricciones y los requisitos técnicos y no funcionales que imponen los componentes construidos o adquiridos. Los requisitos no funcionales específicos que se deben considerar son el tamaño, el rendimiento, la impresión en la memoria o el disco, los aspectos de la licencia de tiempo de ejecución y otras restricciones similares que influirán en la construcción o la selección del componente.

Análisis y diseño

  • Actividad: Diseñar componentes
  • La Tarea: Diseño del subsistema perfecciona aún más el diseño de los componentes, identificando las clases del componente que proporcionan el comportamiento real del componente. Al principio de la fase de elaboración, es probable que haya una sola clase, un tipo de 'proxy de componente/subsistema' que actúa como un fragmento para simular el comportamiento del componente para crear prototipos arquitectónicos. Más adelante, el comportamiento de esta clase se distribuye en una colaboración de clases contenidas en el subsistema. Estas clases contenidas se perfeccionan en la Tarea: Diseño de clase.

  • Actividad: Diseñar la base de datos
  • El aspecto más importante de la elaboración es garantizar que la estrategia de permanencia es escalable y que el mecanismo de permanencia y el diseño de bases de datos soportarán los requisitos de rendimiento del sistema. Las clases permanentes se identifican y se correlacionan con el mecanismo de permanencia. Los casos de uso de datos intensivos se analizan para garantizar que los mecanismos serán escalables. Junto con las actividades de prueba, se valora y se valida el mecanismo de permanencia y el diseño de bases de datos.

Implementación

Prueba

  • Actividades: Definir la misión de evaluación, Verificar el enfoque de prueba, Probar y evaluar, Conseguir una misión aceptable, Aumentar los activos de prueba

    Las actividades de prueba de la fase elaboración se centran en validar la arquitectura. Para un sistema basado en componentes, se centran en:

    • ejercitar las interfaces entre componentes para garantizar que los límites del componente son adecuados
    • una atención mayor en la prueba de rendimiento, especialmente en las pruebas de escala de rendimiento, para garantizar que se pueden sostener los volúmenes de transacción anticipados

    También es necesario valorar las suposiciones inherentes de la infraestructura de componentes. Estas suposiciones suelen ser la escalabilidad y el rendimiento de los mecanismos de gestión de la transacción y la permanencia, donde el diseñador de mecanismos efectúa suposiciones ocultas que a menudo socavan eficazmente la arquitectura de la aplicación si no conoce la suposición.

Gestión de proyectos

  • Actividad: Planear la siguiente iteración

    Si se utilizan los subsistemas de implementación como 'unidades lógicas de responsabilidad', el trabajo de construcción se puede particionar en dos o más "seguimientos" paralelos: uno que se centra en las funciones específicas de la aplicación y uno o varios que se centran en componentes genéricos reutilizables. Por supuesto, esto depende de si se tienen los recursos humanos suficientes para esfuerzos de desarrollo paralelo. La capacidad de dividir los equipos de desarrollo y trabajar en paralelo depende totalmente de la estabilidad de la arquitectura y, más específicamente, de la calidad y la estabilidad de las interfaces entre los componentes. Esta división será posible si se realiza un esfuerzo enorme en la fase de elaboración.

Actividades de la fase de construcción

Se aplica el flujo de trabajo básico para la fase de construcción, con las siguientes ampliaciones o variaciones:

Gestión de proyectos

  • Actividad: Planear la siguiente iteración

    Anteriormente se describió la planificación de la primera iteración de construcción, igual que sucede hacia el final de la elaboración. Igual que la planificación de la iteración, la capacidad de dividir los equipos de desarrollo y trabajar en paralelo sigue dependiendo de la estabilidad de la arquitectura y la calidad y la estabilidad de las interfaces entre los componentes.

Análisis y diseño

  • La Actividad: Perfeccionar la arquitectura y la Actividad: Diseñar componentes

    El aspecto principal de la construcción es el análisis del recordatorio de los casos de uso y la identificación de las colaboraciones de componentes y los componentes adecuados que realizan los casos de uso . La arquitectura existente se amplía y se completa y los "comportamientos internos" del componente se diseñan y se implementan completamente.

  • Actividad: Diseñar la base de datos

    El aspecto principal de la construcción es terminar el diseño de la base de datos y asegurarse de que todas las clases permanentes son soportadas tanto por la base de datos como por el mecanismo de permanencia. Este trabajo se realiza en paralelo y de forma repetitiva con el trabajo que se realiza en la Actividad: Perfeccionar la arquitectura y la Actividad: Diseñar componentes. La organización ideal consiste en contar con equipos de componentes integrados, y con coordinación entre equipos de los asuntos de permanencia para garantizar un buen diseño de base de datos.

Implementación

Prueba

Las pruebas de rendimiento siguen siendo importantes, aunque cada vez se presta más atención a las pruebas funcionales. Deben tenerse en cuenta la completitud de la funcionalidad, las pruebas de revisión de la funcionalidad existente y la satisfacción de las expectativas de rendimiento.

Actividades de la fase de transición

  • El release del producto en el entorno web suele ser incremental y continuo, y se centra menos en la distribución tradicional de medios de soporte. La planificación del release debe ajustarse en consecuencia.
  • El soporte de producción es cada vez más importante en la fase.
  • Se realizan actividades de conversión de datos.