Se o sistema se comunicar com outro sistema, haverá uma ou mais classes de fronteira 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 eletrônica para verificar se o número do banco e o número de identificação pessoal (PIN) de um cliente estão corretos e se ele tem fundos suficientes na conta para efetuar um saque. Como a rede eletrônica é um sistema externo (analisando da perspectiva do caixa eletrônico), deveríamos usar uma classe fronteira para representá-la em 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 do sistema permaneçam ocultos enquanto sua definição se desenvolve.

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process