Detalhamento do Fluxo de Trabalho: Projetar Componentes

Disciplinas > Análise e Design > Fluxo de Trabalho > Projetar Componentes

Tópicos

Finalidade

A finalidade deste detalhamento de fluxo de trabalho é:

Refinar as definições dos elementos de design (incluindo cápsulas e protocolos) por meio da elaboração de 'detalhamentos' de como os elementos de design implementam o comportamento exigido deles.
Refinar e atualizar as realizações de casos de uso baseadas no novo elemento de design identificado (isto é, manter atualizadas as realizações de casos de uso)
Revisar o design à medida que ele evolui
Implementar os elementos de design como componentes
Testar os componentes implementados para verificar a funcionalidade e o cumprimento dos requisitos no nível do componente/unidade

De modo geral, uma pessoa ou uma equipe pequena é responsável por um conjunto de elementos de design, usualmente um ou mais pacotes, subsistemas ou cápsulas contendo outros elementos de design. Essa pessoa/equipe é responsável pelos detalhamentos do design para os elementos contidos no pacote, subsistema ou cápsula: completar todas as definições de operações e de relacionamentos com outros elementos de design. A Atividade: Encapsular Design focaliza a decomposição recursiva de funcionalidades do sistema em termos de cápsulas e classes (passivas ou de dados). A Atividade: Design da Classe focaliza o refinamento dos elementos de design de classes passivas, enquanto a Atividade: Design do Subsistema focaliza a alocação do comportamento mapeado para o próprio subsistema nos elementos de design contidos (cápsulas contidas e classes ou subsistemas). Normalmente, os subsistemas são usados principalmente como estruturas de organização de modelos de baixa granularidade; as cápsulas são usadas para a maior parte do trabalho e as classes "normais", são relegadas a armazenamentos passivos de informações.

As pessoas ou as equipes responsáveis pelo design das cápsulas devem ter domínio da linguagem de implementação e também devem ser especialistas nas questões relativas à simultaneidade. Os profissionais responsáveis pelo design das classes passivas também devem ter domínio da linguagem de implementação, assim como dos algoritmos ou tecnologias que a classe utilizará. As pessoas e as equipes responsáveis por subsistemas devem ser mais generalistas, capazes de tomar decisões quanto ao particionamento adequado da funcionalidade entre os elementos de design e de entender as permutas inerentes às várias alternativas de design.

À medida que cada elemento de design for refinado, as realizações de casos de uso precisarão ser refinadas para refletir a evolução das responsabilidades desses elementos. Em geral, uma pessoa ou uma pequena equipe é responsável pelo refinamento de uma ou mais realizações de casos de uso relacionadas. Ao adicionar ou refinar elementos de design, é preciso reconsiderar as realizações de casos de uso e fazê-las evoluir à medida que ficam desatualizadas ou que as melhorias no modelo de design permitam simplificá-las. As pessoas ou equipes responsáveis pelas realizações de casos de uso precisam ter amplo conhecimento do comportamento exigido pelos casos de uso e dos ajustes das diferentes abordagens para alocar esse comportamento nos elementos de design. Além disso, como são responsáveis pela seleção dos elementos que executarão os casos de uso, elas precisam ter um profundo conhecimento dos comportamentos externos (públicos) dos próprios elementos de design.

Orientações de Trabalho

Geralmente, aqui o trabalho é executado individualmente ou por pequenas equipes, com interações informais entre os grupos quando for necessário comunicar mudanças entre as equipes. À medida que se refinam os elementos de design, eles freqüentemente transferem responsabilidades entre si, o que requer mudanças simultâneas em muitos deles e em várias realizações de casos de uso. Por causa dessa interação de responsabilidades, é quase impossível que os membros da equipe de design trabalhem totalmente isolados. Para manter o esforço de design focado no comportamento exigido do sistema (conforme descrito nas realizações de casos de uso), surge um padrão característico de interação:

os elementos de design são refinados pelas pessoas ou equipes responsáveis
um pequeno grupo (talvez 2-5 pessoas) se reúne informalmente para calcular o impacto dos novos elementos de design em um conjunto de realizações de casos de uso existentes
no decorrer da discussão, identificam-se mudanças na realização dos casos de uso e nos elementos de design participantes
o ciclo se repete até que todo o comportamento exigido seja suportado e que todos os elementos de design sejam considerados suficientemente completos para serem implementados.

Sendo o próprio processo iterativo, os critérios de "suficientemente completo para ser implementado" variam, dependendo da posição no ciclo de vida:

Na fase de elaboração, o foco deve ser nos comportamentos significativos do ponto de vista da arquitetura, sendo todos os outros 'detalhamentos' totalmente ignorados (ou mais provavelmente 'apagados')
Na fase de construção, há um deslocamento em direção à abrangência e consistência do design, de modo que, ao final dessa fase, não exista nenhuma questão de design não solucionada.

Rational Unified Process