Se o sistema se comunicar com outro sistema, haverá uma ou mais classes de limite identificadas em Atividade: Análise de Caso de Uso para descrever o protocolo de comunicação. O outro sistema pode ser qualquer elemento desde software a unidades de hardware que o sistema atual usará, como impressoras, terminais, dispositivos de alarme e sensores. Em cada um dos casos, uma classe de fronteira será identificada. A finalidade disso é mediar a comunicação com o outro sistema.

Exemplo

Um caixa eletrônico deve se comunicar com a rede de caixas eletrônicos para verificar se o número do banco e a senha do cliente estão corretos e se ele tem fundos suficientes na conta para efetuar um saque. Como a rede de caixas eletrônicos é um sistema externo (da perspectiva do caixa eletrônico), você utilizaria uma classe de limite para representá-la na Análise de Caso de Uso.

Se a(s) interface(s) com o sistema for(em) simples e bem definida(s), é provável que uma única classe seja suficiente para representar o sistema externo. No entanto, essas interfaces são geralmente muito complexas para serem representadas por meio de uma única classe. Elas freqüentemente exigem colaborações complexas de várias classes. Além disso, as interfaces com os sistemas são, em geral, altamente reutilizáveis entre aplicativos. Conseqüentemente, em muitos casos, um subsistema modela de forma mais apropriada as interfaces do sistema.

O uso de um subsistema permite que a interface com o sistema externo seja definida e estabilizada, deixando, ao mesmo tempo, que os detalhes do design da interface com o sistema permaneçam ocultos enquanto sua definição se desenvolve.



Rational Unified Process   2003.06.15