Se o sistema se comunica 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.

Refinamento de Design

Um requisito para interface com outros sistemas ou dispositivos impõe a necessidade de ser formal na especificação e realização de (UML) interfaces. Nesses casos, é útil ser muito preciso sobre os limites do sistema e o contexto em que o sistema opera. Enquanto o Modelo de Caso de Uso mostra o contexto comportamental do sistema, um modelo lógico do sistema em seu ambiente, mostrará:

  • As interfaces a serem realizadas e fornecidas pelo sistema (em termos dos serviços que o sistema fornece-como ../../glossary.htm#operation -- This hyperlink in not present in this generated websiteoperações ou ../../glossary.htm#reception -- This hyperlink in not present in this generated websiterecepções de sinal -os protocolos associados suportados e as informações trocadas)
  • As interfaces requeridas pelo sistema (a serem realizadas pelos sistemas externos que interagem com o sistema) para o desempenho correto. Freqüentemente, quando o sistema externo já existe, essas interfaces requeridas e fornecidas simplesmente refletem as restrições impostas por outro sistema porque seu comportamento não pode ser alterado

Um diagrama de contexto pode ser criado para mostrar a colaboração de alto nível entre o sistema e outros sistemas ou dispositivos. Esse é o analógico estrutural para o Modelo de Caso de Uso do sistema. Os serviços do sistema compõem para suportar os casos de uso -por exemplo, é possível construir um conjunto de diagramas de seqüência mostrando as interações entre os sistemas externos e o sistema em construção para ilustrar as mensagens que são trocadas na execução de um caso de uso e mapeiam as mensagens para operações (ou recepções)-observe que isso não é a mesma coisa que um diagrama de seqüência mostrando uma realização de caso de uso porque não mostramos quaisquer qualidades internas do sistema. O desempenho de um cenário de caso de uso normalmente envolverá várias chamadas e respostas do sistema.

Essa identificação de serviços e suas realizações dentro do sistema não necessariamente prosseguem estritamente de cima para baixo: em Análise de Caso de Uso (executado pelo Designer) um modelo inicial das classes de realização (incluindo as classes de limite) e as colaborações são construídas, levando em conta o trabalho feito pelo Arquiteto de Software Architect na Atividade: Análise Arquitetural. Podemos iterar sobre esta análise e posteriormente refinar as classes de limite e as mensagens que fluem no limite do sistema-supondo que temos liberdade para fazer isso. Quando a interface está com um sistema externo existente que é difícil ou impossível de alterar, os detalhes da interface (portanto,os serviços para suportá-lo) são essencialmente corrigidos desde o início e tudo que podemos fazer é refinar nossa realização da interface.

Neste nível superior, o sistema pode ser representado como um (UML) componente (ou no UML 2.0 como uma classe estruturada) que realiza interfaces, definidas formalmente no UML, no suporte dos sistemas ou dispositivos externos. Além disso, no UML 2.0, essas interfaces podem ser designadas para pontos de interação definidos ou portas no limite do sistema. A utilização de portas permite que o Arquiteto de Software e o Designer mostrem como os componentes internos do sistema ou as classes são 'ligadas' para suportar as interfaces. Isso forma uma ponte natural para as classes de limite que foram identificadas na análise: no casos simples, elas podem ser conectadas às interfaces que realizam por meio de portas no limite do sistema. No UML 2.0, um nível maior de precisão está disponível por meio das máquinas de estado do protocolo: uma máquina de estado do protocolo pode estar associada a uma interface ou uma porta e especifica as seqüências legais da chamada dos recursos comportamentais especificados pela interface ou suportados pela porta.

Nos casos em que, conforme descrito anteriormente, uma colaboração é necessária para suportar uma interface complexa, essa colaboração (evoluindo da classe limite originalmente identificada) pode ser encapsulada como um componente (ou uma classe estruturada) interno do sistema -atuando como o subsistema descrito na primeira seção-e conectado à porta que suporta a interface requerida.

Para obter um tratamento detalhado de como as interfaces podem ser fornecidas e realizadas em uma Arquitetura Orientada ao Serviço, consulte o white paper "Utilizando a Arquitetura Orientada ao Serviço e o Desenvolvimento com Base em Componente para Construir Aplicativos de Serviço da Web".

Rational Unified Process   2003.06.15