desse sistema. No contexto de casos de uso, eventos de sistema correspondem às ações do ator no cenário de determinado caso de uso. Sendo assim, é relativamente fácil identificar eventos de sistemas em uma descrição de caso de uso: devemos procurar nessa descrição os eventos que correspondem a ações do ator. No caso particular em que o ator é um ser humano e existe uma interface gráfica para que o mesmo interaja com o sistema, os eventos do sistema são resultantes de ações desse ator sobre essa interface gráfica, que corresponde a objetos de fronteira. O conceito de evento de sistema não é novo. Na verdade, já era utilizado na metodologia de análise estruturada para a construção do modelo ambiental do sistema (YOURDON, 1990). Posteriormente esse conceito foi adaptado por Bertrand Meyer e Craig Larman ao paradigma da orientação a objetos (LARMAN, 2003; MEYER, 1997). Esse mesmo conceito é também descrito pelo professor Raul Wazlawick em WAZLAWICK (2011).
Em geral, as mensagens enviadas por um objeto de fronteira como consequência do acontecimento de algum evento de sistema resultam na execução de operações que devem ser alocadas na classe do objeto controlador do caso de uso em questão. Essas operações são denominadas operações de
sistema. Por definição, uma operação de sistema é qualquer operação que deve ser executada para
“recepcionar” um evento de sistema.
Na construção do modelo de classes de análise, vimos que é possível definir um objeto de controle para cada caso de uso (veja a Seção 5.4.2.1). Esse objeto fica então responsável por coordenar a realização desse caso de uso. Como o controlador tem essa responsabilidade de coordenação, todas as ações do ator resultam em alguma atividade realizada por esse objeto de controle. Portanto, as operações de sistemas identificadas em um caso de uso devem ser alocadas ao controlador desse caso de uso.
Figura 7-27: Protótipo da interface gráfica do caso de uso Fornecer Grade de Disponibilidades.
Para exemplificar os conceitos de evento de sistema de operação de sistema, considere a Figura 7-27, na qual é apresentado o protótipo de um dos formulários de nosso estudo de caso, o SCA. Esse formulário corresponde ao caso de uso Fornecer Grade de Disponibilidades (veja a Seção 4.7.3; veja também
a Figura 5-48). Neste formulário, o professor pode configurar sua grade de disponibilidade, que corresponde a um agregado de disciplinas que ele deseja lecionar e de dias e horários em que está disponível para lecionar no próximo período letivo. A princípio, o professor deve fornecer sua matrícula e solicitar sua validação pelo sistema (atente para o botão “Validar Matrícula”). Evidentemente,
• • • • • • • •
essa solicitação, que corresponde a um evento de sistema, desencadeia uma sequência de ações executadas pelos objetos componentes do SCA. Ou seja, essa solicitação do ator é um típico evento de sistema. Se a validação da matrícula do professor tiver sucesso, este pode montar sua grade (note as duas abas no formulário para fornecimento de disponibilidades). Ao final da montagem de sua grade, o professor pode solicitar ao sistema que este faça o registro da mesma. Em resumo, temos neste exemplo a seguinte lista de eventos de sistema (veja também a Seção 7.7, que fornece mais detalhes das operações de sistema identificadas para este caso de uso do SCA):
Solicitação de validação de matrícula de professor. Solicitação de adição de uma disciplina à grade.
Solicitação de adição de um item de horário (dia, hora inicial e hora final) à grade. Solicitação de registro da grade.
Repare que, embora o exemplo acima esteja no contexto de um formulário (p. ex., de um componente da interface gráfica com o usuário), é importante notar que nem todo evento de sistema é originado em um objeto de fronteira correspondente a uma interface gráfica. Um evento de sistema corresponde a qualquer ocorrência na fronteira do sistema que o leve a reagir de alguma forma; essa ocorrência pode mesmo ser gerada por um ator que não seja um ser humano (p. ex., outro sistema ou um equipamento).
Uma vez identificados os eventos de sistema, a definição das operações de sistema correspondentes é relativamente fácil: dado um evento de sistema, definimos uma operação de sistema correspondente (ou seja, uma mensagem enviada ao objeto de controle) e parâmetros para essa operação (ver Seção 8.3.1) que permitam que as informações necessárias à execução da operação sejam passadas de um objeto a outro. Por exemplo, para os quatro eventos de sistema acima, o controlador do caso de uso em questão deve possuir as seguintes operações:
validarProfessor(matrícula)
adicionarDisciplina(nomeDisciplina)
adicionarItemHorario(dia, horaInicial, horaFinal) registrarGradeDisponibilidade()
Obviamente, diversas outras operações são normalmente invocadas como consequência da chamada de uma única operação de sistema. Ou seja, uma vez que uma operação de sistema é identificada, devemos também identificar as operações que devem ser invocadas subsequentemente. A identificação correta dessas operações subsequentes e sua correta alocação aos objetos do sistema são tarefas complexas. Já a identificação das operações (ou equivalentemente, das mensagens) subsequentes depende muito da experiência dos projetistas envolvidos. Para essa tarefa, é necessário que esses projetistas apliquem corretamente diversos princípios da orientação a objetos (coesão, acoplamento, encapsulamento etc). É também fundamental que o projetista tenha conhecimento acerca de diversos padrões de projetos e de quais são os contextos de suas utilizações. O conhecimento acerca de como a aplicação deve estar organizada arquiteturalmente também é importante aqui, posto que uma operação de sistema pode resultar na invocação de operações em classes residentes em diferentes camadas do software. Entretanto, apesar de toda a complexidade envolvida, pelo menos o modelador tem um ponto de partida para começar a tarefa. Esse ponto de partida corresponde às operações de sistema.