Tarea: Diseño de la operación
En esta tarea se perfeccionan los resultados del análisis de la operación en realizaciones detalladas de la operación.
Objetivo
  • Perfeccionar las interacciones preliminares del subsistema en realizaciones de la operación en el modelo de diseño.
  • Perfeccionar y especificar las operaciones del subsistema.
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional:
  • Ninguno
Externa:
  • Ninguno
Salidas
Pasos
Crear realizaciones de la operación

En la Tarea: Análisis de la operación, el diseñador ha creado interacciones del subsistema (sin mucho detalle) en el modelo de análisis. Recuerde que había organizado la granularidad de estas interacciones de modo que éstas se agruparon por operación del sistema; es decir, capturó las interacciones que realizan cada operación del sistema.. Ahora, al trabajar con las descripciones de los casos de uso del sistema (caja blanca) ampliadas, se añaden los detalles de los mensajes, entidades intercambiadas, secuencias, flujo de control y datos asociados, y las realizaciones de la operación resultantes se capturan en el modelo de diseño, organizadas de nuevo por operación del sistema. A medida que se añaden estos detalles, el diseñador evalúa la calidad de las colaboraciones emergentes, buscando oportunidades para refactorizar el diseño. Anote las realizaciones de la operación con descripciones de lo que hace cada subsistema al procesar un mensaje (extraídas de la descripción del paso de caja blanca y perfeccionadas si es necesario). Estas descripciones son útiles en el paso siguiente cuando se desarrollan especificaciones para cada operación del subsistema.

Agregar pasos de caja blanca similares del subsistema y especificar operaciones del subsistema

El diseñador ha producido el marcador Inspección de la operación del subsistema durante la tarea Análisis de la operación. La tabla de inspección también muestra (con un fondo gris) la rastreabilidad hasta los pasos de caja negra de los casos de uso del sistema, indicando (en la tabla) que los pasos de caja negra de casos de uso del sistema <id 1> e <id 2> se realizan mediante invocaciones del <nombre 1 de la operación del sistema>.

Subsistema <nombre>
Operación del sistema Identificador de paso de caja negra de casos de uso del sistema Localidad Proceso Trabajador Descripción del paso de caja blanca del subsistema Operación del subsistema

<nombre1 de la operación del sistema>

<id 1> Identificador de localidad Identificador de proceso Identificador del trabajador del sistema u organización (identificador de paso de caja blanca): descripción de una acción realizada por un subsistema (parte de realización del paso de caja negra) en forma de entrada, proceso, salida (identificador de operación del subsistema): nombre de la operación del subsistema que se invoca para este paso; por ejemplo, "«operación del subsistema» Iniciar una lista de ventas" (para el subsistema Proceso de pedidos)
... ...   (identificador de paso de caja blanca):...  
... ...   ...  
<id 2> ... ...   ...  
<nombre2 de la operación del sistema> <id 3> ... ...   ...  
<id 4> ... ...   ...  
... ... ... ...   ...  

Ejemplo de inspección de operaciones del subsistema.

A continuación, trabajando desde los pasos de caja blanca y las realizaciones de la operación, se identifican las operaciones del subsistema y se especifica su comportamiento. Al igual que con la identificación de operaciones del sistema, podría no haber una única operación del subsistema para cada paso de caja blanca; es decir, cuando examine el conjunto de pasos de caja blanca y su intercambio asociado de mensajes, entidades de entrada-salida, etc., podría encontrar que es posible definir un conjunto más pequeño de operaciones del subsistema que satisfagan sus necesidades.

Tenga en cuenta que la tabla de inspección también se puede reordenar por localidad o por proceso, mostrando de esta manera la asociación de un conjunto de operaciones del subsistema con cada localidad o con cada proceso. La ordenación por localidad proporciona una indicación de la carga informática de la localidad (y por tanto es útil para el razonamiento sobre la capacidad de los componentes físicos que dan soporte a la localidad). De esta forma, la inspección ordenada por localidad pasa a ser una propiedad del modelo de despliegue.

Una operación del subsistema que está alojada en varias localidades indica que al menos parte del subsistema está replicado. No hay ninguna implicación de que estas partes replicadas comparten necesariamente datos o que se mantienen sincronizadas. Se trata de opciones de diseño que dependen de la aplicación y del motivo de la réplica; por ejemplo, el proceso necesario podría ser idéntico, pero podría tener lugar para un segmento empresarial distinto. En el caso extremo, todas las operaciones de un subsistema pueden alojarse en varias localidades, lo que significa que, efectivamente, el propio subsistema está replicado. La necesidad de identificar instancias replicadas también depende de forma exclusiva de los motivos de la réplica.

La ordenación por proceso permite al diseñador razonar sobre los temas de concurrencia: si una operación del subsistema debe verse como una parte discreta de la funcionalidad que está disponible a los actores, entonces, como primera aproximación, las operaciones asociadas con el mismo proceso no pueden realizarse en paralelo. Esto podría llevar al diseñador a reconsiderar la asignación del proceso, a considerar la réplica del proceso, o a examinar los problemas de latencia percibidos a un nivel más bajo de detalle, por ejemplo, examinando las opciones de división de tiempo, y el compartimiento del proceso cuando se bloquea una operación (para realizar operaciones de entrada-salida, por ejemplo). Estas técnicas pueden ofrecer una capacidad de respuesta aceptable, mientras que un retardo en el inicio de una operación (operaciones estrictamente de serialización) podría ser intolerable. De esta forma, la inspección ordenada por proceso se convierte en una propiedad del modelo de diseño.

Nota a pie de página Qué ha conseguido

Para cada subsistema, ha realizado lo siguiente:

  • ha definido sus operaciones
  • ha definido las interfaces que espera que el subsistema dé soporte
  • ha descrito cómo el subsistema colabora con otros subsistemas para realizar los casos de uso del sistema
  • ha definido el contexto del subsistema: sus actores, interfaces y entidades de E/S

Por tanto, está en una buena posición para poder distribuir este conjunto de productos de trabajo para un desarrollo independiente, en caso de que decida hacerlo, o bien para volver a invocar las tareas de RUP en la disciplina de requisitos, para realizar más descomposición de forma recursiva.

Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información