Enquanto o Modelo de Caso de Uso mostra o contexto comportamental do sistema, nesta tarefa, você criará um modelo do sistema em seu ambiente, utilizando o Produto de Trabalho: Modelo de Caso de Uso e o Produto de Trabalho: Especificações Suplementares para delinear o seguinte em um Diagrama de Contexto:

• As interfaces a serem realizadas pelo sistema, em termos das operações fornecidas pelo sistema e dos protocolos associados suportados, as variáveis de estado e os armazenamentos que o sistema realiza e os atributos caracterizados como Medidas Técnicas de Desempenho).
• As entidades de E/S que fluem entre o sistema e seus agentes.
• As interfaces necessárias pelo sistema (a serem realizadas pelos agentes que interagem com o sistema) para o desempenho correto. Muitas vezes, se o agente representa um sistema existente com o qual o sistema deve se comunicar, essas interfaces necessárias simplesmente refletem as restrições impostas por esse outro sistema.

Um diagrama de contexto mostra a colaboração de nível superior entre o sistema e seus agentes. Esse é o analógico estrutural para o Modelo de Caso de Uso do sistema. Essa colaboração é criada no Modelo de Análise.

Entidades de E/S (representadas para modelagem como classes estereotipadas de "E/S" com atributos, mas sem operações) descrevem itens que fluem para dentro ou para fora do sistema, podendo, no caso do sistema geral, incluir dados, massa, energia ou partes físicas. Essas entidades de E/S são associadas (durante a modelagem) a pares de agente/sistema, indicando que essas entidades de E/S específicas fluem entre o agente e o sistema. Como opção, elas podem ser mostradas nos diagramas, associadas ao agente, e a direção do fluxo é indicada por um estereótipo de envio" ou "recebimento" na associação, indicando a direção relativa ao agente.

Uma Operação do Sistema é um serviço que pode ser solicitado a partir de um objeto para gerar um comportamento. Uma operação especifica o nome, o tipo, os parâmetros e as restrições para chamar um comportamento associado. As Operações são agrupadas em torno das interfaces, junto às principais responsabilidades do (sub)sistema em consideração. Uma chamada de operação do sistema representa uma interação mais granular com o sistema em comparação a uma instância de caso de uso, e uma instância de caso de uso é uma composição de chamadas e respostas de operações.

Variáveis de estado e armazenamentos são atributos definidos nas interfaces realizadas pelo sistema. São abstratas e requerem que o sistema mantenha informações correspondentes ao tipo e a multiplicidade do atributo e que permita o armazenamento, a recuperação e a modificação dessas informações. Não há implicação de que um atributo no sistema corresponda diretamente ao atributo definido na interface. A diferença entre variáveis de estado e armazenamentos não é intrínseca, mas apenas reflete a forma como os atributos são utilizados para controlar a operação da máquina de estado do sistema (abstrato). Um "estado" persiste por um certo período, ao contrário de um evento (como a chegada de um sinal), que ocorre em um ponto no tempo. As máquinas de estado mencionadas aqui são máquinas de estado finitas, e a delineação de "estado" é, em geral, decidida por relativamente poucas variáveis; por exemplo, o estado atual pode ser especificado pelo valor de um único atributo de um tipo de enumeração. Entretanto, a reação do sistema a um evento pode depender não só da natureza desse evento (e das informações que ele transmite, por exemplo, nos parâmetros de operação) e do estado atual, como também do valor de outros atributos (talvez muitos outros).

Uma TPM (Technical Performance Measure) é um atributo técnico-chave, selecionado a partir de Especificações Suplementares ou de um Modelo de Caso de Uso como indicador crítico da eficácia do sistema, que, se não for obtido, colocará o desenvolvimento do sistema em risco de restrições de custo pelo excesso de execução, planejamento ou desempenho. Os valores emergentes desses atributos são rastreados ao longo da existência do projeto. Por exemplo, talvez seja importante que que o peso entregue de um sistema seja mantido abaixo de um certo limite e que a obtenção dessa meta precise ser rastreada durante o design e a construção. O peso do sistema entregue é obviamente um atributo (que pode ser realizado de várias maneiras) de uma instância do sistema e não é necessariamente igual ao peso de destino durante o desenvolvimento (para que um sistema seja ativado e fique operacional, você provavelmente preferirá que o peso seja menor). Um valor UML rotulado pode ser utilizado para anotar um atributo TPM de forma a indicar a meta de desempenho, por exemplo:

peso "TPM" {peso_máximo = 1000kg}

TPMs também podem ser aplicáveis a outras características não estruturais, como o tempo de resposta das operações. Valores rotulados podem ser aplicados a operações do sistema, ou ao próprio sistema, para registrar essas características.

As etapas a seguir mostram os níveis evolutivos de detalhes do sistema no contexto. O exemplo ilustrado é o de um sistema de segurança, protegendo uma propriedade contra invasão não autorizada, que, além de ativar um alarme, é capaz de reportar violações a algum tipo de serviço de resposta. 

À medida que se evolui e mais detalhes são incluídos no Modelo de Caso de Uso (descobrindo os agentes; ou, se a Modelagem de Negócios tiver sido desempenhada, e os agentes e talvez as operações já tenham sido identificados, elaborando sua interação), você poderá criar a colaboração inicial e ilustrar essa colaboração com um Diagrama de Contexto. O Diagrama de Contexto pode ser criado conforme especificado a seguir, com as interfaces do sistema inicialmente abstraídas. O sistema é representado como um subsistema de nível superior (estereotipado como "sistema") que, com o tempo, realiza várias interfaces. Agentes e suas associações também são mostrados, mais uma vez, sem detalhes no início.

Diagrama de Contexto (Inicial)

Em seguida, você refinará as associações entre os agentes e o sistema e a interface do sistema. Comece a considerar as operações do sistema e os atributos do sistema à medida que eles são exteriorizados a partir da Tarefa: Localizar Agentes e Casos de Uso (Posteriormente: Tarefa: Detalhar um Caso de Uso). Observe que, agora, o sistema aparece aos agentes, mostrando a interface. A realização disso poderá ser mostrada se desejado (realçada pelo círculo tracejado no diagrama), mas pode ser omitida sem muita perda de informações.

Nesse estágio, apenas identifique temporariamente as entidades de E/S, com base no conhecimento de domínio e em qualquer trabalho anteriormente feito na realização de casos de uso em nível corporativo. Observe que não é necessário que as entidades de E/S sejam mostradas no diagrama, mas isso pode ser útil na consideração sobre as interações entre os agentes e o sistema.

Portanto, você pode começar a caracterizar a(s) conexão(ões) entre o agente e o sistema (por exemplo, registrar o protocolo requerido) e a registrar as entidades que fluem entre eles.

Diagrama de Contexto (Preliminar)

Nesta etapa, você começa a construir cenários de caso de uso (instâncias de casos de uso) a partir dos quais possa descrever operações do sistema (fornecidas e necessárias). Os cenários podem ser ilustrados por diagramas de interação ou de atividades. Cada etapa em caixa preta de um caso de uso representa uma interação granular com o sistema e é mapeada para uma chamada de operação (mas não necessariamente uma operação exclusiva; outras etapas em caixas pretas podem utilizar a mesma operação). Além da definição das operações do sistema no Diagrama de Contexto (e, portanto, no Modelo de Análise), os casos de uso também são anotados, por questões de rastreabilidade, para as operações chamadas. As operações também herdam todos os requisitos de desempenho ou outros requisitos não funcionais que foram alocados às etapas em caixa preta. Ao examinar cada etapa em caixa preta desempenhada no cenário, você descobre o uso de nomes que podem sugerir variáveis de estado e armazenamentos que o sistema deve manter para executar o cenário de caso de uso. Você também pode refinar as entidades de E/S que são necessárias e associá-las às chamadas de operações para formar os sinais enviados entre o agente e o sistema. 

Para auxiliar na compreensão, talvez seja útil dividir a interface do sistema em interfaces mais específicas. De fato, pode haver requisitos de interface na Especificação Suplementar com orientações para essa divisão. A ilustração a seguir mostra a evolução da interface do sistema em direção a uma "interface de sistema fornecida" para cada tipo de agente, embora isso não seja uma ordem fixa. Os agentes podem compartilhar uma interface ou pode haver mais de uma interface para um agente.

Essa análise também pode identificar interfaces requeridas pelo sistema, ou seja, interfaces que devem ser suportadas pelos agentes (para processar mensagens do sistema). Elas podem ser incluídas no diagrama de forma simétrica (por exemplo, consulte a "interface de sistema requerida" de serviços do IE/ESS realizada pelo agente Serviços de Emergência no diagrama a seguir). Novamente, (embora isso não seja mostrado) um agente pode oferecer suporte a (realizar) mais de uma interface.

As operações, os armazenamentos e assim por diante precisam ser incluídos em um formato expandido de interfaces (nos compartimentos de atributos e operações), conforme mostrado. O diagrama está apenas parcialmente elaborado (em termos de espaço). A interface de ambiente físico, o agente e assim por diante não foram expandidos. Novamente, a realização das interfaces do sistema fornecidas pode ser omitida sem muita perda de informações.

Diagrama de Contexto (Final).

Esta colaboração de nível superior, capturada no Diagrama de Contexto, permite que interfaces e conexões que fluem para dentro e para fora do sistema, bem como as características de desempenho associadas, sejam rigorosamente especificadas, possibilitando que o desenvolvimento do sistema prossiga de certa forma independentemente de outros elementos no contexto do sistema.