Capítulo 5 – Modelagem de sistemas
5.2 Modelos de interação
Todos os sistemas envolvem algum tipo de interação. Pode-se ter interação do usuário, que envolve entradas e saídas, interação entre o sistema que está em desenvolvimento e outros sistemas, ou interação entre os compo- nentes do sistema. A modelagem da interação do usuário é importante, pois ajuda a identificar os requisitos do usuário.
O sistema de modelagem da interação do sistema destaca os problemas de comunicação que podem surgir. A modelagem da interação nos ajuda a compreender se a estrutura proposta para o sistema é suscetível de produzir o desempenho e a confiança requerida do sistema. Nesta seção, trato de duas abordagens relacionadas à mode- lagem da interação:
1. Modelagem de caso de uso, usada principalmente para modelar interações entre um sistema e atores externos
(usuários ou outros sistemas).
2. Diagramas de sequência, usados para modelar interações entre os componentes do sistema, embora os agen-
tes externos também possam ser incluídos.
Os modelos de caso de uso e diagramas de sequência apresentam interações em diferentes níveis de detalha- mento e, assim, podem ser usados juntos. Os detalhes das interações envolvidas em um caso de uso de alto nível podem ser documentados em um diagrama de sequência. A UML inclui diagramas de comunicação que podem ser usados para modelar as interações. Como eles são uma representação alternativa de diagramas de sequência, eu não os discuto neste momento. De fato, algumas ferramentas podem gerar um diagrama de comunicação a partir de um diagrama de sequência.
5.2.1 Modelagem de caso de uso
A modelagem de caso de uso foi originalmente desenvolvida por Jacobson et al. (1993) na década de 1990, e foi incorporada ao primeiro release da UML (RUMBAUGH et al., 1999). Como discutido no Capítulo 4, a modelagem de caso de uso é amplamente usada para apoiar a elicitação de requisitos. Um caso de uso pode ser tomado como um cenário simples que descreve o que o usuário espera de um sistema.
Cada caso de uso representa uma tarefa discreta que envolve a interação externa com um sistema. Em sua forma mais simples, um caso de uso é mostrado como uma elipse, com os atores envolvidos representados por figuras-palito. A Figura 5.3 mostra um caso de uso do MHC-PMS que representa a tarefa de carregar os dados do MHC-PMS para um sistema mais geral de registro de pacientes. Esse sistema mais geral mantém um resumo dos dados do paciente, em vez de manter os dados sobre cada consulta, que são registrados no MHC-PMS.
Observe que existem dois atores nesse caso de uso: o operador que transfere os dados e o sistema de registro de pacientes. A notação da figura-palito foi originalmente desenvolvida para cobrir a interação humana, mas tam- bém é usada para representar outros sistemas externos e hardware. Formalmente, os diagramas de caso de uso devem usar linhas sem setas, pois na UML as setas indicam a direção do fluxo de mensagens. Certamente, em um caso de uso, as mensagens seguem nas duas direções. No entanto, as setas na Figura 5.3 são usadas informalmen- te para indicar que a(o) recepcionista do médico inicia a operação e os dados são transferidos para o sistema de registro de pacientes.
Figura 5.3 Caso de uso de transferência de dados.
Recepcionista do médico Sistema de registro de pacientes Transferir dados
87
Capítulo 5 Modelagem de sistemas
Diagramas de casos de uso dão uma visão simples de uma interação. Logo, é necessário fornecer mais detalhes para entender o que está envolvido. Esses detalhes podem ser uma simples descrição textual, uma descrição estrutu- rada em uma tabela ou um diagrama de sequência, como discutido a seguir. Você deve escolher o formato mais ade- quado, dependendo do caso de uso, e o nível de detalhamento que você acredita ser necessário no modelo. Para mim, o formato-padrão de tabela é o mais útil. A Tabela 5.1 mostra uma descrição tabular do caso de uso ‘Transferir dados’.
Como já discutido no Capítulo 4, diagramas compostos de casos de uso mostram situações diferentes. Às ve- zes, todas as possíveis interações de um sistema são incluídas em um único diagrama composto de casos de uso. No entanto, isso pode não ser possível, conforme o número de casos de uso. Nesses casos, você pode desenvolver vários diagramas, cada um mostrando casos de uso relacionados. Por exemplo, a Figura 5.4 mostra todos os casos de uso no MHC-PMS em que o ator ‘recepcionista do médico’ está envolvido.
5.2.2 Diagramas de sequência
Os diagramas de sequência em UML são usados, principalmente, para modelar as interações entre os atores e os objetos em um sistema e as interações entre os próprios objetos. A UML tem uma sintaxe rica para diagramas de sequência, que permite a modelagem de vários tipos de interação. Como não tenho espaço para cobrir todas as possibilidades aqui, concentro-me nos fundamentos desse tipo de diagrama.
Como o nome indica, um diagrama de sequência mostra a sequência de interações que ocorrem durante um caso de uso em particular ou em uma instância de caso de uso. A Figura 5.5 é um exemplo de diagrama de sequên- cia que ilustra os conceitos básicos da notação. Esse diagrama modela as interações envolvidas no caso de uso ‘Ver informações de pacientes’, em que a recepcionista do médico pode ver algumas informações sobre o paciente.
Os objetos e atores envolvidos estão listados na parte superior do diagrama, com uma linha tracejada verti- calmente a partir deles. Interações entre objetos são indicadas por setas anotadas. O retângulo na linha tracejada indica a linha da vida do objeto em questão (ou seja, o tempo em que a instância do objeto está envolvida no processamento). Deve-se ler a sequência de interações de cima para baixo. As anotações sobre as setas indicam as chamadas para os objetos, seus parâmetros e os valores de retorno. Nesse exemplo, também mostro a notação para designar as alternativas. Uma caixa nomeada ‘alt’ é usada com as condições indicadas entre colchetes.
Você pode ler a Figura 5.5 da seguinte maneira:
1. A recepcionista do médico aciona o método VerInfo em uma instância P da classe de objeto InfoPaciente, for-
necendo o identificador do paciente (PID, do inglês patient’s identifier). P é um objeto de interface do usuário, exibido como um formulário que mostra os dados do paciente.
2. A instância P chama o banco de dados para retornar as informações necessárias, fornecendo o identificador
da recepcionista, que permite a verificação de proteção (nessa fase, não importa de onde vem esse UID — do inglês, user´s identifier).
3. O banco de dados verifica, com um sistema de autorização, que o usuário está autorizado a essa ação.
4. Se autorizado, as informações de pacientes são retornadas, e um formulário é preenchido na tela do usuário. Se
falhar a autorização, aparece uma mensagem de erro.
Tabela 5.1 Descrição tabular do caso de uso ‘Transferir dados’
Atores Recepcionista do médico, sistema de registros de pacientes (PRS, do inglês patient records system) Descrição Uma recepcionista pode transferir dados do MHC-PMS para um banco de dados geral de registros de
pacientes mantido por uma autoridade de saúde. As informações transferidas podem ser atualizadas com as informações pessoais (endereço, telefone etc.) ou com um resumo do diagnóstico e tratamento do paciente. Dados Informações pessoais do paciente, resumo do tratamento.
Estímulos Comando de usuário emitido pela recepcionista do médico. Resposta Confirmação de que o PRS foi atualizado.
Comentários A recepcionista deve ter permissões de proteção adequadas para acessar as informações do paciente e o PRS.
88 Engenharia de software
A Figura 5.6 é um segundo exemplo de diagrama de sequência do mesmo sistema, que ilustra duas caracte- rísticas adicionais. Estas são a comunicação direta entre os atores do sistema e a criação de objetos como parte de uma sequência de operações. Nesse exemplo, um objeto do tipo Sumário é criado para armazenar os dados de resumo que serão enviados para o PRS. Você pode ler esse diagrama da seguinte maneira:
1. A recepcionista inicia sessão (login) no PRS.
2. Existem duas opções disponíveis. Elas permitem a transferência direta de informações atualizadas de pacientes
para o PRS e a transferência de dados do sumário de saúde do MHC-PMS para o PRS.
3. Em cada caso, as permissões da recepcionista são verificadas por meio do sistema de autorização.
4. As informações pessoais podem ser transferidas diretamente do objeto de interface de usuário para o PRS.
Como alternativa, um registro do sumário pode ser criado a partir do banco de dados e, então, o registro é transferido.
5. Após concluir a transferência, o PRS emite uma mensagem de status e o usuário fecha a sessão (logoff ).
Figura 5.5 Diagrama de sequência para ‘Ver informações de pacientes’
P: InfoPaciente VerInfo (PID) Relatório
(Info, PID, UID)
Autorizar (Info, UID) Informações de pacientes D: MHCPMS-DB AS: Autorização Autorização
Erro (sem acesso) [Autorização OK]
[Falha de autorização] Recepcionista do médico
Alt
Figura 5.4 Casos de uso envolvendo o papel da ‘recepcionista do médico’
Recepcionista do médico Registrar pacientes Transferir dados Contatar pacientes Ver informações de pacientes Não registrar pacientes Sommerville_Cap_05.indd 88 31/05/2011 15:07:31
89
Capítulo 5 Modelagem de sistemas
A menos que você esteja usando diagramas de sequência para geração de código ou documentação detalha- da, você não precisa incluir todas as interações nesses diagramas. Se você desenvolver modelos de sistemas no início do processo de desenvolvimento para dar apoio à engenharia de requisitos e projeto de alto nível, aconte- cerão muitas interações que dependem de decisões de implementação. Por exemplo, na Figura 5.6, a decisão de como obter o identificador de usuário para verificação de autorização pode ser adiada. Em uma implementação, isso pode envolver a interação com um objeto Usuário, mas, nesse momento, essa decisão não é importante e, por isso, não deve ser incluída no diagrama de sequência.