Atividade:
|
Finalidade
|
|
Função: Designer | |
Freqüência: Uma vez por subsistema de design. | |
Etapas | |
Artefatos de Entrada: | Artefatos Resultantes: |
Mentores de Ferramentas: | |
Informações Adicionais: | |
Detalhes de Detalhamento do Fluxo de Trabalho:: |
Finalidade | Especificar o comportamento interno do subsistema. Identificar novas classes de design ou subsistemas de design necessários para satisfazer os requisitos comportamentais do subsistema. |
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 é utilizado 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 geralmente são utilizadas em conjunto com as classes ativas para representar uma decomposição dos encadeamentos de controle do sistema (ou subsistema, nesse caso) e são descritas nos diagramas de estados; consulte }Diretrizes: Diagrama de Estados.
No subsistema, talvez haja threads de execução independentes, representados por classes ativas.
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 seu comportamento.
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 novos elementos de design deve impor a reconsideração do limite e do conteúdo 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. Revisite periodicamente a Atividade: Identificar Elementos de Design para reequilibrar as responsabilidades do subsistema.
Às vezes, é útil criar dois modelos internos separados do subsistema - uma especificação direcionada para o cliente do subsistema e uma realização direcionada aos implementadores. A especificação deve incluir colaborações e classes "ideais" para descrever o comportamento do subsistema em termos de colaborações e classes ideais. A realização, por outro lado, corresponde mais estreitamente à implementação e pode evoluir para a implementação. Para obter mais informações sobre a realização e especificação do Subsistema de Design, consulte Diretrizes: Subsistema de Design, Realização e Especificação do Subsistema.
Finalidade | Documentar a estrutura interna do subsistema. |
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.
Modelado como um componente, o conteúdo interno de um subsistema pode ser representado alternativamente na parte interna do retângulo do componente em um diagrama de componentes. Essa representação permite incluir os pontos de interação desse subsistema em outras partes do sistema, o que é feito através de suas interfaces.
O exemplo de um diagrama de componentes é mostrado a seguir, ilustrando o subsistema Pedido, seu conteúdo interno, bem como suas interfaces fornecidas e exigidas.
Exemplo de um diagrama de componentes para o Subsistema Pedido
Como um componente é uma
classe estruturada, ele pode ser
encapsulado, forçando a passagem das comunicações pelo lado externo
através de portas que obedecem a interfaces declaradas, o que gera precisão adicional na
especificação e interconexão desse componente.Essa representação permite
"ligar" as instâncias das partes através de conectores a fim de desempenhar
uma função específica na implementação do componente (consulte
Conceitos: Classe Estruturada para
obter informações adicionais).
Exemplo de um diagrama de estrutura composta para o Subsistema Pedido
Além disso, um diagrama de estados pode ser necessário para documentar os possíveis 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 de Classe.
Finalidade | Documentar as interfaces das quais o subsistema depende. |
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 aprimorar a reaproveitamento e reduzir as dependências de manutençã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 nele.
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 Subsistemas utilizando dependências de Interface
Exemplo de Camadas de Subsistema Usando Dependências Diretas
Exemplo de Camadas de Subsistemas utilizando dependências de Interface
Consulte Diferenças entre UML 1.x e UML 2.0 para obter informações adicionais.
Rational Unified Process
|