Introdução

O flowdown de casos de uso é a técnica de derivar requisitos funcionais para os elementos de análise (e, por conseguinte, design).Os resultados da atividade são:

• relatório sintético de operações de subsistema
• relatório sintético de operações de subsistema hospedadas para localidades
• relatório sintético de operações de subsistema executadas para processos
• relatório sintético de casos de uso para subsistemas (opcional)

A técnica utiliza a atividade RUP padrão de escolher um conjunto arquiteturalmente significativo dos casos de uso. Para cada caso de uso escolhido, o fluxo de eventos é desenvolvido. Esta é a descrição das interações entre os agentes do sistema e o sistema. As respostas do sistema são a caixa preta; as descrições não fazem referência aos elementos arquiteturais. Em seguida, uma etapa de caixa preta (que será desempenhada por uma operação de sistema) é expandida para uma ou mais etapas de caixa branca, cada uma delas é desempenhada por um subsistema designado. As etapas de caixa preta também são associadas às localidades que as hospedam e aos processos que as executam. Cada etapa de caixa branca que se estende a localidades ou processos (ou seja, que requer mais de um para ser concluída) é dividida até que possa ser concluída em uma única localidade, por um único processo. Uma etapa de caixa branca pode ser replicada em várias localidades, mas são instâncias independentes. Essas etapas de caixa branca são candidatas a tornarem-se operações de subsistema, que são equivalentes às operações de sistema neste nível inferior de decomposição lógica.

As composições de seqüências exclusivas de operações de subsistema para um subsistema individual, participando da realização de operações de sistema, produzem os casos de uso do subsistema (etapa opcional).

Mapeamento de Localidades de Subsistema

No início do flowdown de casos de uso, você lida com um sistema que geralmente se estende (e até mesmo pode encapsular) a várias localidades; a profundidade em que a decomposição é desempenhada nos subsistemas (e subsistemas subordinados) é uma questão de decisão arquitetural e depende, entre outras coisas, do domínio e da complexidade do sistema. Entretanto, para os propósitos da análise de desempenho, é importante compreender a carga computacional a ser imposta em uma localidade; isso é feito sob o ponto de vista das operações de subsistema hospedadas nessa localidade. Portanto, considere a seguinte prescrição para decomposição: a decomposição deve produzir um conjunto de operações de subsistema que seja particionado limpamente entre as localidades; ou seja, uma operação de subsistema não se estende a localidades, mas se uma operação de subsistema (por exemplo, subsistema A) precisar, para seu desempenho, utilizar recursos de uma localidade diferente, os próprios recursos deverão ser disponibilizados através de uma operação de subsistema, que pode ser fornecida pelo próprio subsistema dessa localidade ou um outro subsistema.

Essa condição será obviamente suspensa se um subsistema não se estender a localidades, mas se puder se estender a localidades se suas operações puderem ser particionadas conforme descrito—caso contrário, o subsistema deverá ser decomposto ainda mais. A discussão aqui diz respeito a instâncias únicas de um subsistema que se estende a localidades; um subsistema sempre pode ser replicado em várias localidades, porém são instâncias separadas.