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 encadeamentos 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 Diretriz: Diagrama de Estados. Em sistemas de tempo real, o comportamento do Produto de Trabalho: Cápsulas também será descrito utilizando máquinas de estado.No subsistema, talvez haja encadeamentos de execução independentes, representados por classes ativas.

Em sistemas de tempo real, o Produto de Trabalho: Cápsulas será utilizado para encapsular esses encadeamentos.

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 Tarefa: 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 informações adicionais sobre a realização e especificação do Subsistema de Design, consulte Diretriz do Produto de Trabalho: Subsistema de Design, Realização e Especificação 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 Conceito: Classe Estruturada, para obter informações adicionais).

Exemplo de um diagrama de estrutura composta para o Subsistema Pedido

A descrição das classes contidas no próprio subsistema é abordada na Tarefa: Design de Classe.

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 contido nele.

São dois os motivos:

• Queremos ser capazes de substituir um elemento de modelo (incluindo os subsistemas) por outro, contanto que eles ofereçam o mesmo comportamento. Especificamos o comportamento necessário em termos de interface, a fim de que qualquer requisito comportamental que um elemento de modelo tenha sobre outro seja expresso em termos de interfaces.
• Queremos dar ao designer total liberdade para projetar o comportamento interno do subsistema, contanto que forneça o comportamento externo correto. Se um elemento de modelo em um subsistema fizer referência a um elemento de modelo de outro subsistema, o designer não terá mais liberdade para remover esse elemento ou redistribuir o comportamento desse elemento para outros elementos. Conseqüentemente, o sistema será mais frágil.

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 Interfacerealizada 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 estruturas flexíveis sejam projetadas através de elementos de design substituíveis.

Exemplo de Camadas de Subsistemas utilizando dependências de Interface