Atividade:
| ||||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Uma Vez por Subsistema de Design | |
| Papel: Designer | |
| Diretrizes: | |
| Mentores de Ferramentas: | |
| Mais Informações: | |
| Detalhamentos do Fluxo de Trabalho: |
Finalidade
|
| Mentor de Ferramentas: Gerenciamento de Subsistemas Usando o Rational Rose |
Os comportamentos externos do subsistema são definidos pelas interfaces que ele realiza. Quando um subsistema realiza uma interface, ele se compromete a oferecer suporte a todas as operações definidas por essa interface. A operação pode ser, por sua vez, realizada através de:
As colaborações dos elementos de modelo dentro do subsistema devem ser documentadas através de diagramas de seqüência que mostram como é o comportamento do subsistema. Cada operação em uma interface realizada pelo subsistema deve conter um ou mais diagramas de seqüência de documentação. Esse diagrama pertence ao subsistema e é usado para projetar o comportamento interno do subsistema.
Se o comportamento do subsistema for altamente dependente de estado e representar um ou mais threads de controle, as máquinas de estado geralmente serão mais úteis na descrição desse comportamento. As máquinas de estado nesse contexto são geralmente usadas junto com as classes ativas para representar uma decomposição de threads de controle do sistema (ou subsistema, neste caso) e são descritas nos diagramas de estados. Consulte Diretrizes: Diagrama de Estados.
Nos sistemas em tempo real, o comportamento de Artefato: Cápsulas também será descrito através das máquinas de estado.
No subsistema, talvez haja threads de execução independentes, representados por classes ativas.
Nos sistemas em tempo real, Artefato: Cápsulas será usado para encapsular esses threads.
Exemplo:
A colaboração dos subsistemas para executar algum comportamento necessário do sistema pode ser expressa através dos diagramas de seqüência:
Este diagrama mostra como as interfaces dos subsistemas são usadas para executar um cenário. Especificamente, no caso do subsistema Network Handling, vemos as interfaces específicas (ICoordinator neste caso) e as operações às quais o subsistema oferece suporte. Também observamos que os subsistemas NetworkHandling dependem das interfaces IBHandler e IAHandler.
Observando o subsistema, percebemos como a interface ICoordinator é realizada:
A classe Coordinator atua como "proxy" da interface ICoordinator, manipulando as operações da interface e coordenando o comportamento da interface.
Esse diagrama de seqüência "interno" mostra exatamente quais classes fornecem a interface, o que precisa acontecer internamente para que a funcionalidade do subsistema seja fornecida e quais classes enviam mensagens a partir do subsistema. O diagrama esclarece o design interno e é essencial para subsistemas com designs internos complexos. Ele também permite que o comportamento do subsistema seja facilmente compreendido, tornando-o reutilizável entre os vários contextos.
Criando esses diagramas de "realização de interface", talvez seja necessário criar novas classes e subsistemas para executar o comportamento necessário. O processo é similar ao definido em Análise de Caso de Uso, mas, em vez de Casos de Uso, estamos trabalhando com operações de interface. Para cada operação de interface, identifique as classes (ou, em alguns casos em que o comportamento necessário seja complexo, um subsistema armazenado) do subsistema atual que são necessárias para executar a operação. Crie novas classes/subsistemas quando as classes/subsistemas existentes não puderem fornecer o comportamento necessário (mas tente reutilizá-los primeiro).
A criação de novas classes, de classes ativas e de subsistemas exigirá que você reconsidere o conteúdo e a fronteira do subsistema. Tenha cuidado para não ter uma mesma classe em dois subsistemas diferentes. A existência de uma classe desse tipo fará, talvez, com que as fronteiras do subsistema não sejam bem delimitadas. Faça consultas periódicas à Atividade: Identificar Elementos de Design para balancear novamente as responsabilidades do subsistema.
Finalidade
|
| Mentor de Ferramentas: Gerenciamento de Subsistemas Usando o Rational Rose |
Para documentar a estrutura interna do subsistema, crie um ou mais diagramas de classes mostrando os elementos armazenados no subsistema e seus relacionamentos. Um diagrama de classes deve ser suficiente, mas uma quantidade maior pode ser utilizada para reduzir a complexidade e melhorar a legibilidade.
Um exemplo de diagrama de classes é mostrado a seguir:
Exemplo de Diagrama de Classes para um Sistema de Entrada de Pedidos.
Além disso, um diagrama de estados pode ser necessário para documentar os estados que o subsistema pode assumir. Consulte Diretrizes: Diagrama de Estados.
A descrição das classes contidas no próprio subsistema é abordada na Atividade: Design da Classe.
Finalidade
|
| Mentor de Ferramentas: Gerenciamento de Subsistemas Usando o Rational Rose |
Quando um elemento armazenado em um subsistema utiliza algum comportamento de um elemento armazenado em outro subsistema, uma dependência é criada entre os subsistemas envolvidos. Para melhorar as dependências de manutenção de reutilização e redução, optamos por expressar isso em termos de dependência de uma interface específica do subsistema, e não do próprio subsistema nem do elemento armazenado no subsistema.
São dois os motivos:
Ao criar dependências, certifique-se de que não há dependências ou associações diretas entre os elementos de modelo armazenados no subsistema e os elementos de modelo armazenados em outros subsistemas. Além disso, assegure-se de que não haja dependências circulares entre subsistemas e interfaces. Um subsistema não pode realizar uma interface e, ao mesmo tempo, ser dependente dela.
As dependências entre subsistemas e as dependências entre subsistemas e pacotes podem ser induzidas diretamente como mostrado a seguir. Nessa ilustração, a dependência declara que um subsistema (Invoice Management, por exemplo) é diretamente dependente de outro subsistema (Payment Scheduling Management).
Exemplo de Camadas de Subsistema Usando Dependências Diretas
Quando existe uma possibilidade de substituição de um subsistema por outro (quando eles têm interfaces iguais), a dependência pode ser levada para uma interface realizada pelo subsistema, e não para o próprio subsistema. Isso permite que qualquer outro elemento de modelo (subsistema ou classe) que realiza a mesma interface seja utilizado. O uso de dependências de interface permite que frameworks flexíveis sejam projetados através de elementos de design substituíveis.
Exemplo de Camadas de Subsistema Usando Dependências de Interface
|
Rational Unified Process
|
