Tarefa: Design de Operação
Esta tarefa refina os resultados da Análise de Operações em Realizações de Operação detalhadas.
Disciplinas: Análise e Design
Objetivo
  • Refinar as interações preliminares de subsistema em Realizações de Operação no Modelo de Design.
  • Refinar e especificar as Operações de Subsistema.
Relacionamentos
Etapas
Criar Realizações de Operações

Na Tarefa: Análise de Operações, o Designer criou interações de subsistema (sem muitos detalhes) no Modelo de Análise. Lembre-se de que você organizou a granularidade dessas interações para que elas fossem agrupadas por Operação do Sistema, ou seja, você capturou as interações que realizam cada Operação do Sistema. Agora, trabalhando com as descrições de caso de uso do sistema (caixa branca) expandidas, os detalhes de mensagens, entidades trocadas, elaboração de seqüências, fluxo de controle e dados associados são incluídos, e as Realizações de Operações resultantes são capturadas no Modelo de Design, novamente organizado por Operação do Sistema. À medida que esses detalhes são incluídos, o Designer avalia a qualidade das colaborações emergentes, procurando oportunidades de refatorar o design. Anote as Realizações de Operações com descrições do que o subsistema faz ao processar uma mensagem (extraídas da descrição de etapas de caixa branca e refinadas, se necessário). Essas descrições auxiliam na etapa seguinte, para desenvolver especificações para cada Operação de Subsistema.

Agregar Etapas de Caixa Branca de Subsistema Semelhantes e Especificar Operações de Subsistema

O Designer produziu o sinalizador de substituição de Relatório Sintético de Operação de Subsistema durante a tarefa de Análise da Operação. A tabela de relatórios sintéticos também mostra (com um fundo cinza) a rastreabilidade retrocedida às etapas de caixa preta de caso de uso do sistema, indicando (na tabela) que o <id 1> e o <id 2> das etapas de caixa preta de caso de uso do sistema são ambos desempenhados por chamadas do <nome da operação de sistema 1>.

Nome do <subsistema>
Operação do Sistema Identificador da Etapa de Caixa Preta de Caso de Uso do Sistema Localidade Processo Trabalhador Descrição da Etapa de Caixa Branca de Subsistema Operação do Subsistema

<operação do sistema nome1>

<id 1> Identificador de localidade Identificador de processo Identificador de organização ou trabalhador do sistema (identificador de etapa de caixa branca): descrição de uma ação desempenhada por um subsistema (desempenhando parte da etapa de caixa preta) no formato de entrada, processamento e saída (identificador de operação do subsistema): nome da operação do subsistema que é chamada para essa etapa, por exemplo, "«operação de subsistema» Iniciar uma Lista de Vendas" (para o subsistema de Processamento de Ordens)
... ...   (identificador de etapa de caixa branca):...  
... ...   ...  
<id 2> ... ...   ...  
<nome2 da operação do sistema> <id 3> ... ...   ...  
<id 4> ... ...   ...  
... ... ... ...   ...  

Exemplo de Relatório Sintético de Operação do Subsistema.

Em seguida, trabalhando a partir das etapas de caixa branca e das Realizações de Operações, as Operações de Subsistema são identificadas e seu comportamento é especificado. Como ocorre com a identificação de operações do sistema, talvez não haja uma operação de subsistema exclusiva para cada etapa de caixa branca, ou seja, à medida que você examina o conjunto de etapas de caixa branca e sua troca de mensagens associadas, entidades de entrada e saída e assim por diante, poderá constatar que é possível definir um conjunto menor de Operações de Subsistema para atender às suas necessidades.

Observe que a tabela de relatórios sintéticos também pode ser reclassificada por localidade ou por processo, mostrando assim a associação de um conjunto de Operações de Subsistema com cada localidade ou com cada processo. A classificação por localidade dá uma identificação da carga de cálculo em uma localidade (e, portanto, é útil para considerar a capacidade dos componentes físicos que oferecem suporte à localidade). Dessa forma, o relatório sintético classificado por localidade torna-se propriedade do Modelo de Implementação.

Quando uma Operação de Subsistema é hospedada em várias localidades, isso indica que pelo menos parte do subsistema é replicado. Não há implicação de que essas partes replicadas necessariamente compartilhem dados ou sejam mantidas em sincronização. Essas são as opções de design que dependem do aplicativo e do motivo de replicação; por exemplo, o processamento necessário pode ser idêntico, mas ocorre para um segmento de negócios diferente. No extremo, todas as operações de um subsistema podem ser hospedadas em várias localidades, significando que, de fato, o próprio sistema é replicado. A necessidade de identificar exclusivamente as instâncias replicadas também depende dos motivos da replicação.

A classificação de processos permite que o Designer considere problemas de simultaneidade: se você tivesse que visualizar uma Operação de Subsistema como uma parte distinta da funcionalidade disponível aos agentes, como primeiro indicador, as operações associadas ao mesmo processo não poderiam ser desempenhadas em paralelo. Isso pode fazer com que o Designer reconsidere a alocação do processo, considere a replicação do processo ou examine o problema de latência percebido com um nível menor de detalhes, por exemplo, por meio do exame de opções de divisão de tempo e compartilhamento do processo quando uma operação for bloqueada (para fazer a entrada e a saída, por exemplo). Essas técnicas podem proporcionar uma reação aceitável, enquanto o atraso do início de uma operação (operações estritas de serialização) pode ser intolerável. Dessa forma, o relatório sintético classificado por processo torna-se propriedade do Modelo de Design.

Anotar os Resultados Obtidos em uma Nota de Rodapé

Para cada subsistema, você:

  • definiu suas operações
  • definiu as interfaces que espera serem suportadas pelo subsistema
  • descreveu como o subsistema colabora com outros subsistemas para realizar os casos de uso do sistema
  • definiu o contexto do subsistema: seus agentes, suas interfaces e suas entidades de E/S

Portanto, você está bem posicionado para poder transferir esse conjunto de produtos de trabalho para desenvolvimento independente (se preferir) ou para rechamar as tarefas do RUP na disciplina de Requisitos, de forma a desempenhar a decomposição adicional de maneira recursiva.

Informações Adicionais