Modelagem de classes de análise

Estudo de caso
Utilizamos a técnica de análise de casos de uso, estudamos a descrição de cada passo do fluxo
principal do caso de uso em que o sistema realiza alguma ação. Cada um desses passos implica classes e
responsabilidades dentro do sistema. Durante a identificação de classes a partir do texto de um caso de uso,
os fluxos alternativos e de exceção devem também ser analisados.
Descrevemos a aplicação desta e de outras técnicas para identificar classes de entidade nos três
seguintes casos de uso do SCA:
● Fornecer Grade de Disponibilidades,
● Realizar Inscrição,
● Lançar Avaliações.

Análise do caso de uso Fornecer Grade de Disponibilidades

“Professor fornece sua matrícula para validação.”

Essa frase suscita a decisão de criar uma primeira classe, ​Professor , e definir nela um atributo para
representar a ​matrícula​ de um professor.

“Sistema apresenta a lista de disciplinas disponíveis (conforme RN04), e a lista de dias da semana e
de horários do semestre letivo”.
Esse passo leva o modelador a concluir que é necessária uma classe para representar ​disciplinas​.
Além disso, é possível concluir também que o sistema deve ter conhecimento acerca dos horários em que
pode haver alocação de uma turma de alguma disciplina. Como consequência, é criada uma classe Disciplina
e outra denominada ​ItemHorario​ .

Outra conclusão é que esse mesmo sistema também deve ter informações acerca de que disciplinas
um professor está apto a lecionar, o que resulta na criação de uma ​associação entre ​Professor e ​Disciplina
. A semântica dessa associação corresponde às habilitações de um professor, i.e., quais disciplinas da grade
curricular ele está apto a lecionar. Repare também que essa associação é uma forma de refletir no modelo a
regra de negócio cujo identificador é ​RN04​.
Quando passamos para analisar o terceiro passo do caso de uso, encontramos:
“Professor informa (1) cada disciplina que deseja lecionar e (2) cada disponibilidade para o próximo semestre
letivo”.
Uma interpretação razoável é que o sistema deve registrar duas listas de informações associadas ao
professor.
1. A primeira lista corresponde às ​disciplinas​ ​que o professor selecionou.
2. A segunda lista corresponde ​aos dias da semana (e respectivos horários de início e término) em que
este mesmo ​professor está disponível para ser alocado em ​turmas de disciplinas componentes da
primeira lista.

Primeiramente é possível concluir que uma turma é composta por um professor e uma disciplina:

O modelador então decide unificar essas duas listas como a definição de um novo conceito
denominado grade de disponibilidades. Como resultado, a classe ​GradeDisponibilidades é criada, assim
como são criadas duas novas associações (para representar as duas listas de informações previamente
mencionadas), uma com Disciplina e outra com ​ItemHorario . Finalmente, uma terceira associação é criada,
entre Professor e GradeDisponibilidades.
Realizar Inscrição

Fluxo Principal
1. Aluno solicita a realização de inscrições.
2. Sistema apresenta as disciplinas (e respectivos códigos das turmas) em que o aluno pode se inscrever
(conforme a ​RN03​).
3. Aluno escolhe a lista de turmas que deseja cursar no próximo semestre letivo e as submete para inscrição.
4. Para cada turma, o sistema informa o professor, os horários e os respectivos locais das aulas.
5. Aluno confirma as inscrições.
6. Sistema registra as inscrições do aluno, envia os dados sobre as mesmas para o Sistema de Faturamento,
e o caso de uso termina.

RN03 → Um aluno não pode se inscrever em uma turma de uma disciplina para a qual não possua Descrição
os pré-requisitos necessários. Além disso, um aluno não pode se inscrever em uma turma de alguma
disciplina que já tenha cursado com aprovação.

Os passos ​1​, ​2 e ​3 deste caso de uso sugerem que deve haver alguma forma de o sistema registrar
cada solicitação de matrícula realizada por um aluno. Como resultado, a classe ​Turma foi criada. Essa classe
é a contrapartida temporal de uma disciplina: toda vez que uma disciplina deve ser ofertada em um semestre
letivo, uma nova turma é criada.
 Foram também criadas a classe ​Inscrição e as ​associações desta com as classes ​Aluno e ​Turma .
Repare ainda que o ​passo 2 ​faz menção à regra de negócio ​RN03​. Essa restrição é contemplada no modelo
por meio da adição de uma ​autoassociação​ na classe Disciplina .

Ainda sobre o ​passo 3​, a análise de sua descrição nos permite concluir que é responsabilidade do
sistema saber cada turma (e respectiva disciplina) que pode ser apresentada a um determinado aluno para
inscrição. Avaliar ​RN03​. Criamos a classe ​HistoricoEscolar para assumir a responsabilidade de gerar a lista
de disciplinas em cujas turmas um aluno pode se inscrever. Essa classe está associada a ​Aluno​ .

Uma vez de posse dessa lista, o próximo passo é determinar que turmas (no período letivo corrente)
estão abertas para cada uma dessas disciplinas. Visto que essa responsabilidade envolve a manipulação de
várias turmas, decidimos atribuí-la a uma nova classe ​GradeHorarios e criamos uma associação dessa
última com ​Turma​.
 Portanto, repare que a obtenção da lista de turmas possíveis para um aluno é um procedimento de
dois passos. Primeiro deve-se definir a lista de disciplinas e, depois disso, definir uma lista de turmas. Para
orquestrar a realização desses dois passos, decidimos criar um ​Serviço de Domínio denominado
TurmasPossiveisServico​. Neste ponto, está claro que um objeto dessa classe irá interagir com objeto da
classe ​HistoricoEscolar e com outro da classe ​GradeHorarios​, mas não de que forma ocorrerá essa
interação. Portanto, definição completa dessa parte do modelo será postergada para quando iniciar a
atividade de modelagem de interações

O ​passo 4 desse caso de uso sugere que o sistema deve manter informação acerca do professor,
assim dos horários e respectivos locais de aula de cada turma. Por conta disso, as classes ​Aula e ​Local são
adicionadas ao modelo e associações são criadas para contemplar essa necessidade de informação. A
classe ​ItemHorario , que surgiu durante a análise do caso de uso Fornecer Grade de Disponibilidades , é
reusada aqui com o propósito de registrar, para cada aula, os horários em que ela ocorre.

Por meio da análise do fluxo alternativo ​Inclusão em lista de espera​, identificamos a necessidade da
classe ​ListaEspera​, responsável por manter uma fila de alunos que estão esperando pela abertura de mais
uma turma para uma determinada disciplina.
A Figura a seguir também apresenta a classe ​ListaEspera​, associada a duas classes que já haviam
sido identificadas, ​Aluno e ​Disciplina . Dessa forma, uma lista de espera é criada para registrar a espera de
alunos pela abertura de uma turma para a disciplina associada. Ao mesmo tempo, uma lista de espera está
associada aos alunos que aguardam a abertura dessa turma.
Um detalhe relevante nessa modelagem é o uso da restrição {ordered} na associação entre
ListaEspera e Aluno , no extremo próximo a esta última classe. Essa restrição, predefinida na UML, indica que
a ordem dos objetos na coleção de alunos associada a uma lista de espera deve ser mantida pelo sistema.
 Cada caso de uso tem, a princípio, um objeto de fronteira para cada ator e um objeto controlador. Com
base nessa heurística, as primeiras classes identificadas para o cenário principal desse caso de uso foram
RealizarInscriçãoControlador​, ​RealizarInscriçãoFormulário e ​SistemaFaturamento​. Essas duas últimas
são classes de fronteira do sistema que realizam a interface com os atores Aluno e Sistema de Faturamento,
respectivamente. Note que essas classes de fronteira têm naturezas completamente diferentes. Uma
corresponde possivelmente a uma interface gráfica com o usuário. A outra corresponde à implementação de
algum protocolo de comunicação. Entretanto, não devemos nos ater a esses detalhes durante a análise, pois
eles precisam ser abordados apenas na etapa de projeto do sistema. O importante neste momento da
modelagem é apenas identificar que tais classes são necessárias para prover as funcionalidades (requisitos
funcionais) do sistema.

Análise do caso de uso Lançar Avaliações

Agora vamos analisar o caso de uso Lançar Avaliações. Ao considerarmos a descrição do fluxo
principal desse caso de uso, podemos perceber que os passos de 1 até 4 não demandam a criação de novas
classes. Entretanto, o passo 5 (“O Professor fornece as notas de A1 e de A2 e a quantidade de faltas
solicitadas.”) sugere que o sistema precisa armazenar as avaliações (notas parciais, denominadas A1 e A2 no
caso de uso) e a frequência para cada aluno inscrito em um turma. Sendo assim, o resolvemos criar a classe
denominada ​Avaliacao para registrar essas informações. Além disso, a associação com ​Inscricao permite
atrelar essas informações a cada aluno inscrito em uma turma. Repare também que os limites máximos das
multiplicidades dessa associação estão coerentes. Isso porque, quando o registro de uma avaliação é
realizado, o objeto inscrição ao qual essa avaliação deve ser associada já existe. Por outro lado, quando um
objeto ​Inscricao​ é criado, a avaliação correspondente ainda não existe.

Resultado final pode ser visto na figura a seguir.

Documentação das responsabilidades
Algumas responsabilidades simples podem ser representadas na análise por meio de atributos,
restrições etc., enquanto outras devem ser identificadas e modeladas em um nível alto de abstração, para
posteriormente serem detalhadas na fase de projeto.
Esse detalhamento normalmente ocorre por meio da criação de uma ou mais operações, em classes
já identificadas durante a análise, ou mesmo em novas classes definidas durante a etapa de projeto. A seguir,
apresentamos uma possível forma de documentação de responsabilidades em tempo de análise para
algumas classes do SCA.

Disciplina
1. Conhecer seus pré-requisitos;
2. Conhecer seu código, nome e quantidade de créditos.
ListaEspera
1. Conhecer a disciplina para a qual foi criada;
2. Manter os alunos em espera pela abertura de vagas.
Aluno
1. Conhecer seu número de registro e nome;
2. Conhecer as disciplinas que já cursou.
HistoricoEscolar
1. Permitir o lançamento de trancamentos, aprovações e reprovações;
2. Conhecer quais são as disciplinas da grade curricular que ainda não foram cursadas pelo aluno;
3. Conhecer quais são as disciplinas da grade curricular que já foram cursadas e as que não foram
pelo aluno.
Turma
1. Conhecer o seu código e situação;
2. Conhecer a disciplina para a qual é ofertada;
3. Inscrever um aluno;
4. Conhecer o semestre letivo em que acontece;
5. Conhecer dias, horários e salas de aula em que acontece;
6. Conhecer sua capacidade, por exemplo, sua quantidade máxima de alunos;
7. Conhecer seu professor.