Diretrizes:
|
 Classe de Análise |
As classes de análise representam um primeiro modelo conceitual para "elementos no sistema que possuam responsabilidades e comportamento". Com o tempo, elas evoluirão para classes e subsistemas no Modelo de Design. |
As classes de análise podem ser estereotipadas como:
Além de fornecer orientações mais específicas do processo para localizar classes, a criação de estereótipos é um poderoso modelo de objetos, pois as mudanças no modelo tendem a afetar somente uma área específica. As mudanças na interface do usuário, por exemplo, irão afetar somente as classes de fronteira. As mudanças no fluxo de controle irão afetar somente as classes de controle. As mudanças em informações de longo prazo irão afetar somente as classes de entidade. Esses estereótipos são especialmente úteis para identificar classes em análise e design inicial. É muito provável que, em fases posteriores do design, você precise utilizar um conjunto de estereótipos ligeiramente diferente para fazer uma correlação melhor com o ambiente de implementação, com o tipo de aplicativo, e assim por diante.
A classe de fronteira é uma classe usada para modelar a interação entre o ambiente do sistema e seus trabalhos internos. Essa interação envolve transformar e converter eventos, bem como observar mudanças na apresentação do sistema (como a interface).
As classes de fronteira modelam as partes do sistema que dependem do ambiente. As classes de entidade e de controle modelam as partes que são independentes de fatores externos ao sistema. Portanto, alterar a GUI ou o protocolo de comunicação significa alterar somente as classes de fronteira, e não as classes de entidade e de controle.
As classes de fronteira também facilitam a compreensão do sistema, pois definem suas fronteiras. Elas ajudam no design, fornecendo um bom ponto de partida para identificar serviços relacionados. Por exemplo, se você identificar uma interface de impressora logo no início do design, perceberá de imediato que também deve modelar a formatação das impressões.
Algumas classes de fronteira comuns são janelas, protocolos de comunicação, interfaces de impressora, sensores e terminais. Se você estiver usando um construtor GUI, não será necessário modelar partes da interface de rotinas (botões, por exemplo) como classes de fronteira separadas. Geralmente, a janela inteira é o objeto de fronteira mais refinado. As classes de fronteira também são úteis para capturar interfaces para APIs possivelmente não orientadas a objetos (como código mais antigo, por exemplo).
Você deve modelar as classes de fronteira de acordo com o tipo de fronteira que elas representam. A comunicação com outro sistema e a comunicação com um ator humano (através de uma interface do usuário) têm objetivos diferentes. Durante a modelagem da interface do usuário, a principal preocupação deve ser a forma como a interface será apresentada ao usuário. Durante a modelagem da comunicação do sistema, a principal preocupação deve ser o protocolo de comunicação.
Um objeto de fronteira (uma instância de uma classe de fronteira) poderá durar mais que uma instância de caso de uso se, por exemplo, precisar ser exibido em uma tela entre o desempenho de dois casos de uso. Os objetos de fronteira, porém, costumam ter a mesma duração da instância de caso de uso.
Uma classe de fronteira faz a intermediação entre a interface e algo fora do sistema. Os objetos de fronteira isolam o sistema de mudanças externas (mudanças nas interfaces com outros sistemas, nos requisitos do usuário, etc.), impedindo que elas afetem o restante do sistema.
Um sistema pode ter vários tipos de classes de fronteira:
Podem existir classes de fronteira que representem a interface do usuário a partir de atividades de modelagem dessa interface. Quando apropriado, reutilize essas classes nessa atividade. Caso a modelagem de interface de usuário não tenha sido feita, a discussão a seguir ajudará a localizar essas classes.
Existe pelo menos um objeto de fronteira para cada par de atores de caso de uso. Esse objeto pode ser visto como tendo a responsabilidade de coordenar a interação com o ator. Ele também pode ter objetos secundários , aos quais delega algumas de suas responsabilidades. Isso é verdadeiro para aplicativos GUI baseados em janela, nos quais geralmente existe um objeto de fronteira para cada janela ou para cada formulário.
Faça esboços ou use impressões de tela de um protótipo da interface do usuário que ilustrem o comportamento e a aparência dos objetos de fronteira.
Modele somente as principais abstrações do sistema. Não modele todos os botões, listas e elementos da GUI. A meta da análise não é projetar cada detalhe, mas dar uma boa idéia de como o sistema é composto. Em outras palavras, identifique classes de fronteira apenas para fenômenos do sistema ou para elementos mencionados no fluxo de eventos da realização de casos de uso. Consulte também Diretrizes: Classe de Fronteira (Modelagem da Interface do Usuário).
Uma classe de fronteira que se comunica com um sistema externo é responsável pelo gerenciamento do diálogo com esse sistema. Ela fornece a interface entre o sistema externo e o sistema que está sendo criado.
Exemplo
Em um Caixa Eletrônico, a retirada de dinheiro deve ser verificada através da Rede do Caixa Eletrônico, um ator (que, por sua vez, faz a verificação da retirada com o sistema de contabilidade do banco). Um objeto chamado Interface da Rede do Caixa Eletrônico pode ser identificado para fazer a comunicação com aquela Rede.
A interface com um sistema existente pode já estar bem definida. Se estiver, as responsabilidades serão derivadas diretamente da definição da interface. Se existir uma definição formal de interface, ela pode ser obtida por meio de engenharia reversa e isso precisa estar formalmente definido aqui. Simplesmente anote o fato de que a interface existente será reutilizada durante o design.
O sistema pode conter elementos que agem como se fossem externos (seus valores são alterados espontaneamente, sem que algum objeto do sistema os tenha afetado); por exemplo, um equipamento sensor. Embora seja possível representar esse tipo de dispositivo externo usando atores, os usuários do sistema podem achar isso "confuso", já que o processo tende a colocar dispositivos e atores humanos no mesmo "nível". Após a conclusão da coleta de requisitos, no entanto, precisamos considerar a origem de todos os eventos externos e verificar se dispomos de meios para fazer com que o sistema detecte esses eventos.
Se o dispositivo estiver representado como um ator no modelo de casos de uso, será fácil justificar a utilização de uma classe de fronteira para intermediar a comunicação entre o dispositivo e o sistema. Se o modelo de casos de uso não incluir esses "atores-dispositivo", este será o momento adequado para adicioná-los, atualizando as Descrições Suplementares dos Casos de Uso, quando apropriado.
Para cada "ator-dispositivo", crie uma classe de fronteira para capturar as responsabilidades do dispositivo ou do sensor. Se já existir uma interface bem definida para o dispositivo, anote-a para fazer referência posteriormente durante o design.
A classe de controle é uma classe usada para modelar um comportamento de controle específico de um ou alguns casos de uso. Como objetos de controle (instâncias de classes de controle) geralmente controlam outros objetos, o comportamento de objetos de controle é do tipo coordenador. As classes de controle encapsulam um comportamento específico de caso de uso.
O comportamento de um objeto de controle está estreitamente relacionado à realização de um caso de uso específico. Em muitos cenários, é possível até dizer que os objetos de controle "executam" as realizações de casos de uso. Entretanto, se as tarefas de caso de uso estiverem intrinsecamente relacionadas, alguns objetos de controle poderão participar de mais de uma realização de casos de uso. Além disso, vários objetos de controle de diferentes classes de controle podem participar de um único caso de uso. Nem todos os casos de uso exigem um objeto de controle. Por exemplo, se o fluxo de eventos em um caso de uso estiver relacionado a um objeto de entidade, um objeto de fronteira poderá realizar o caso de uso em cooperação com o objeto de entidade. Comece identificando uma classe de controle para cada realização de casos de uso e, em seguida, refine-a à medida que identifica mais realizações de casos de uso e o respectivo compartilhamento de características comuns.
As classes de controle podem ajudar a entender o sistema, pois representam a dinâmica do sistema, controlando as principais tarefas e os fluxos de controle.
Quando o sistema executar o caso de uso, um objeto de controle será criado. Os objetos de controle geralmente desaparecem após a execução do correspondente caso de uso.
Observe que uma classe de controle não controla tudo o que é necessário em um caso de uso. Em vez disso, ela coordena as atividades de outros objetos que implementam a funcionalidade. A classe de controle delega trabalho aos objetos aos quais foi atribuída a responsabilidade pela funcionalidade.
As classes de controle fornecem comportamento de coordenação no sistema. O sistema pode executar alguns casos de uso sem objetos de controle (simplesmente usando objetos de fronteira e de entidade), principalmente os casos de uso que envolvem somente a simples manipulação de informações armazenadas.
Em geral, casos de uso mais complexos exigem uma ou mais classes de controle para coordenar o comportamento de outros objetos no sistema. Exemplos de objetos de controle incluem programas como gerenciadores de transações, coordenadores de recursos e identificadores de erros.
As classes de controle realmente dissociam objetos de fronteira de objetos de entidade (e vice-versa), tornando o sistema mais tolerante a mudanças em sua fronteira. Elas também dissociam o comportamento específico de casos de uso dos objetos de entidade, tornando-os mais reutilizáveis em casos de uso e sistemas.
As classes de controle fornecem um comportamento que:
O fluxo de eventos de um caso de uso define a ordem em que diferentes tarefas são executadas. Comece investigando se o fluxo pode ser gerenciado pelas classes de fronteira e de entidade já identificadas. Para fluxos de eventos simples, que basicamente inserem, recuperam e exibem ou modificam informações, normalmente não justifica ter uma classe de controle separada. As classes de fronteira serão responsáveis por coordenar o caso de uso.
Os fluxos de eventos devem ser encapsulados em uma classe de controle separada quando forem complexos e consistirem em comportamento dinâmico, que possa ser alterado sem levar em consideração as interfaces (classes de fronteira) ou armazenamentos de informações (classes de entidade) do sistema. Por meio do encapsulamento dos fluxos de eventos, a mesma classe de controle pode ser reutilizada para vários sistemas, que podem ter diferente interfaces e armazenamentos de informações (ou, pelo menos, as estruturas básicas de dados).
Exemplo: Gerenciamento de Fila de Tarefas
É possível identificar uma classe de controle no caso de uso Executar Tarefa no Sistema para Administração de Depósito. Essa classe de controle gerencia uma fila de Tarefas, assegurando a execução das Tarefas na ordem correta. Ela executa a próxima Tarefa da fila assim que um equipamento de transporte adequado é alocado. O sistema pode, portanto, executar várias Tarefas ao mesmo tempo.
Fica mais fácil descrever o comportamento definido pelo objeto de controle correspondente se você dividi-lo em duas classes de controle, o Executor de Tarefas e o Gerenciador de Filas. O objeto Gerenciador de Filas irá gerenciar somente a ordem da fila e a alocação dos equipamentos de transporte. Um único objeto Gerenciador de Filas é necessário para toda a fila. Cada vez que uma Tarefa é executada, o sistema cria um novo objeto Executor de Tarefas, que executará a próxima Tarefa. Precisamos, portanto, de um objeto Executor de Tarefas para cada Tarefa que o sistema executar.
Classes complexas devem ser divididas segundo um modelo de responsabilidades semelhantes
A principal vantagem dessa divisão é obter responsabilidades de gerenciamento de filas separadas (algo genérico em muitos casos de uso) a partir das atividades específicas de gerenciamento de tarefas, que são específicas para esse caso de uso. Isso torna as classes mais fáceis de entender e de adaptar, à medida que o design se desenvolve. Também traz vantagens ao equilibrar a carga do sistema, já que vários Executores de Tarefas podem ser criados conforme a necessidade de gerenciar a carga de trabalho.
Para simplificar as mudanças, encapsule o fluxo de eventos principal e os alternativos em classes de controle diferentes. Se os fluxos alternativos e excepcionais forem completamente independentes, separe-os também. Isso facilitará a ampliação e manutenção do sistema ao longo do tempo.
Também pode ser necessário dividir as classes de controle quando vários atores usam a mesma classe de controle. Ao fazer isso, isolamos as mudanças nos requisitos de um ator a partir do restante do sistema. Quando o custo da mudança for alto ou as conseqüências forem terríveis, você deverá identificar e dividir todas as classes de controle que estejam relacionadas a mais de um ator. Em uma situação ideal, cada classe de controle deve interagir (através de algum objeto de fronteira) com um ou nenhum ator.
Exemplo: Gerenciamento de Chamadas
Considere o caso de uso Chamada Local. Inicialmente, podemos identificar uma classe de controle para gerenciar a chamada em si.
A classe de controle que gerencia chamadas telefônicas locais em um sistema telefônico pode ser rapidamente dividida em duas classes de controle, comportamento A e comportamento B, uma para cada ator envolvido.
Em uma chamada telefônica local, há dois atores: assinante A, que inicia a chamada, e assinante B, que recebe a chamada. O assinante A tira o telefone do gancho, ouve o tom de discagem e disca alguns números, que o sistema armazena e analisa. Depois de receber todos os números, o sistema envia um tom de chamada para o assinante A e um sinal de chamada para o assinante B. Quando o assinante B responde, o tom e o sinal param e a conversa entre os assinantes pode começar. A chamada é concluída quando os dois assinantes desligam.
Dois comportamentos devem ser controlados: o que ocorre no local do assinante A e o que ocorre no local do assinante B. Por esse motivo, o objeto de controle original foi dividido em dois objetos de controle, comportamento A e comportamento B.
Não será necessário dividir uma classe de controle se:
A classe de entidade é uma classe usada para modelar as informações e o comportamento associado que devem ser armazenados. Os objetos de entidade (instâncias de classes de entidade) são usados para manter e atualizar informações sobre alguns fenômenos, como um evento, uma pessoa ou algum objeto real. Esses objetos geralmente são persistentes, precisando de atributos e relacionamentos durante muito tempo, algumas vezes durante todo o ciclo de vida do sistema.
Um objeto de entidade geralmente não é específico para uma realização de casos de uso. Às vezes, um objeto de entidade não é nem mesmo específico para o próprio sistema. Os valores de seus atributos e relacionamentos costumam ser fornecidos por um ator. Um objeto de entidade também pode ajudar a executar tarefas internas do sistema. Seu comportamento pode ser tão complicado quanto o de outros estereótipos de objeto. No entanto, ao contrário de outros objetos, esse comportamento está intrinsecamente relacionado ao fenômeno que o objeto de entidade representa. Os objetos de entidade independem do ambiente (os atores).
Os objetos de entidade representam os conceitos-chave do sistema que está sendo desenvolvido. Exemplos típicos de classes de entidade em um sistema bancário são Conta e Cliente. Em um sistema de gerenciamento de redes, os exemplos são Nó e Link.
Se o fenômeno que você deseja modelar não for usado por outras classes, será possível modelá-lo como um atributo de uma classe de entidade ou mesmo como um relacionamento entre classes de entidade. Por outro lado, se o fenômeno for usado por qualquer outra classe do modelo de design, será preciso modelá-lo como uma classe.
As classes de entidade fornecem um outro ponto de vista do sistema, pois mostram a estrutura lógica dos dados, que pode ajudá-lo a compreender o que o sistema deve oferecer aos usuários.
As classes de entidade representam os armazenamentos de informações no sistema e geralmente são usadas para representar os conceitos-chave que o sistema gerencia. Os objetos de entidade costumam ser passivos e persistentes. Suas principais responsabilidades são armazenar e gerenciar informações no sistema.
O Glossário (desenvolvido durante os requisitos) e um modelo de domínio de negócios (desenvolvido durante a modelagem de negócios, se esta tiver sido executada) são fontes freqüentes de inspiração para as classes de entidade.
As seguintes situações são permitidas:
As seguintes situações são permitidas:
As classes de entidade devem ser apenas a origem de associações (comunicar ou assinar) com outras classes de entidade. Os objetos da classe de entidade normalmente têm longa duração, já os objetos de classe de fronteira e de controle costumam durar pouco. Do ponto de vista arquitetural, é sensato limitar a visibilidade que um objeto de entidade tem do ambiente; dessa maneira, o sistema fica mais receptivo a mudanças.
| De\Para (navegabilidade) |
Fronteira |
Entidade |
Controle |
|
Fronteira |
comunicar |
comunicar
assinar |
comunicar |
|
Entidade |
|
comunicar
assinar |
|
|
Controle |
comunicar |
comunicar
assinar |
comunicar
|
Combinações de Estereótipos de Associação Válidas
|
Rational Unified Process
|
