Actividad: Componentes de diseño
Esta actividad perfecciona el diseño del sistema.
Amplía: Componentes de diseño
DescripciónEstructura de desglose de trabajoAsignación de equiposUtilización del producto de trabajo
Relaciones
Descripción

Esta actividad tiene los objetivos siguientes:

  • Perfeccionar las definiciones de los elementos de diseño resolviendo los 'detalles' de cómo los elementos de diseño se comportan como deben
  • Perfeccionar y actualizar las realizaciones de casos de uso basadas en nuevos elementos de diseño identificados (es decir, mantener actualizadas las realizaciones de casos de uso )
  • Revisar el diseño
Propiedades
Condicionado por sucesos
Varias apariciones
Continuo
Opcional
Planeado
Se puede repetir
Personal

Normalmente, una persona o un pequeño equipo es responsable de un conjunto de elementos de diseño, normalmente uno o más paquetes o subsistemas que contienen otros elementos de diseño. Esta persona o equipo es responsable de sustanciar los detalles de diseño de los elementos contenidos en el paquete o subsistema: completar todas las definiciones de operaciones y la definición de las relaciones con otros elementos de diseño. La Tarea: diseño de cápsulas se centra en la descomposición recursiva de la funcionalidad del sistema en términos de cápsulas y de clases (pasivas o de datos). La Tarea: diseño de clases se centra en perfeccionar el diseño de los elementos de diseño de clases pasivas y la Tarea: diseño de subsistemas se centra en la ubicación de comportamiento correlacionado con el propio subsistema con los elementos de diseño contenidos (sean clases y cápsulas contenidas o subsistemas). Normalmente, los subsistemas se utilizan fundamentalmente como estructuras organizativas con un modelo de mayor granularidad, mientras que las cápsulas se utilizan para el grueso del trabajo y las clases "normales" se relegan en su mayoría a almacenamientos pasivos de información.

Los individuos o equipos responsables del diseño de cápsulas deben conocer el lenguaje de implementación y ser especialistas en las cuestiones de concurrencia en general. Los responsables del diseño de clases pasivas también deben conocer el lenguaje de implementación y los algoritmos o tecnologías que va a emplear la clase. Los individuos o los equipos responsables de los subsistemas deben ser más generalistas y poder tomar decisiones las particiones adecuadas de la funcionalidad entre los elementos de diseño, y poder comprender las renuncias inherentes a las distintas alternativas de diseño.

Mientras se perfeccionan los elementos de diseño, las realizaciones de casos de uso deben perfeccionarse para reflejar la evolución de las responsabilidades de los elementos de diseño. Normalmente, una persona o un equipo pequeño es responsable de perfeccionar uno o más realizaciones de casos de uso relacionadas. A medida que se van añadiendo o perfeccionando elementos de diseño, las realizaciones de casos de uso deben reconsiderarse y deben evolucionar cuando se queden obsoletas, o bien en la medida en que las mejoras en el modelo de diseño permitan simplificaciones en las realizaciones de casos de uso . Los individuos o equipos responsables de las realizaciones de casos de uso deben disponer de un conocimiento más amplio del comportamiento que necesitan los casos de uso y de las renuncias que implican los distintos enfoques en cuanto a la asignación de este comportamiento entre los elementos de diseño. Además, como son responsables de la selección de elementos que llevarán a cabo los casos de uso , deben contar con un profundo conocimiento de los comportamientos externos (públicos) de los propios elementos de diseño.

Utilización
Instrucciones de utilización

Normalmente, éste trabajo se realiza de forma individual o en pequeños equipos, con interacciones informales entre los grupos cuando es necesario comunicar los cambios entre los grupos. A medida que se perfeccionan los elementos de diseño, las responsabilidades a menudo cambian entre ellos, siendo necesario realizar cambios simultáneos a un número de elementos de diseño y realizaciones de casos de uso . Debido a la interacción de responsabilidades, es casi imposible que los miembros del equipo de diseño de forma totalmente aislada. Para que el esfuerzo de diseño se mantenga centrado en el comportamiento necesario del sistema (como se expresa en las realizaciones de casos de uso ), emerge un patrón de interacción típico:

  • las personas o equipos responsables perfeccionan los elementos de diseño
  • un pequeño grupo (quizás de 2 a 5 personas) se reúne informalmente para calcular el impacto de los nuevos elementos de diseño en un conjunto de realizaciones de casos de uso existentes
  • se identifican los cambios tanto en la realización de casos de uso como en los elementos de diseño participantes
  • el ciclo se repite hasta que se diseña todo el comportamiento necesario para la iteración

Como el propio proceso es iterativo, el criterio para definir "todo el comportamiento necesario para la iteración" dependerá de la posición en el ciclo vital.

  • Céntrese en los comportamientos significativos en cuanto a arquitectura durante la fase de elaboración. Ignore el resto de "detalles".
  • En la fase de construcción, hay un cambio de objetivo hacia la integridad y coherencia del diseño, para que al final de la fase de construcción no haya temas de diseño sin resolver.

Observe que no es necesario que el diseño de una iteración esté completo antes de iniciar las actividades de implementación y de prueba. Implementar y probar parcialmente un diseño a medida que va evolucionando puede ser un modo eficaz de validar y perfeccionar el diseño, incluso dentro de una iteración.