Diretriz: Representação de Interfaces com Sistemas Externos
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
operações
ou
recepçõ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".
|