Sobre o planejamento do projeto, de acordo com os preceitos da Engenharia de Software,
podemos afirmar a necessidade do uso de ferramentas de modelagem do sistema para que seja
possível ter uma visão, verificar especificações e analisar como será construído o software. A
UML (Unified Modeling Language) para o engenheiro de software é como a planta de uma
construção para o engenheiro (PRESSMAN; MAXIM, 2016), ou seja, a UML fornece subsídios
para a construção do projeto, bem como para previsão do resultado desta construção.
Dentre os diagramas UML, em consonância com o método de desenvolvimento ágil XP
1,
levantou-se a necessidade de utilizar um grupo de diagramas UML para a elaboração do modelo
conceitual, deixando a visão acerca do projeto definida o suficiente para ser desenvolvida com
qualidade e reduzindo a quantidade de documentação a ser produzida, focando desta maneira, na
codificação. Para tal, foram selecionados os seguintes diagramas:
• Diagrama de Processo;
• Diagrama de Caso de Uso;
• Diagrama de Classe.
1 O XP é um dos mais utilizado dos métodos ágeis, pois a abordagem foi desenvolvida para impulsionar
práticas notoriamente mais eficazes, como o desenvolvimento iterativo e incremental, a níveis extremos. No Extreme Programmingdiferentes versões de um software podem ser desenvolvidas, integradas e testadas em um único dia por programadores diferentes (SOMMERVILLE, 2011), garantindo uma maior produtividade no desenvolvimento, tornando os problemas encontrados em uma parte do sistema de software.
31
Para elaboração da documentação UML foi utilizado o aplicativo Astah
2, ferramenta
dedicada à modelagem de diagramas UML.
3.4.1
Diagrama de Processo
O diagrama de processo é utilizado para descrever a sequência de passos que serão
executadas para a conclusão de um processo no sistema, concentrando-se no fluxo do controle
deste processo.
Na Figura 5 é apresentado o Diagrama de processo para realização do simulado, onde, o
coordenador é responsável por abrir o processo (simulado). Após isso, é solicitado ao professor
a definição do conteúdo e a elaboração de todas as questões. Em seguida, é feita a revisão das
questões, que por sua vez são enviadas num arquivo de texto para análise pelo coordenador, que
poderá aceitar o conteúdo ou solicitar a revisão e posterior reenvio do material.
Uma vez que são definidas as questões do simulado, o coordenador abre o período de
inscrições para os alunos. Caso não haja inscrições, o simulado é cancelado. De outra maneira, é
impresso o caderno de questões com o respectivo cartão-resposta e folha de redação. No dia e
horário agendado para o simulado, o mesmo é aplicado pela coordenação do curso. Na aplicação
o aluno resolve as questões e preenche o gabarito, entregando-o ao final do simulado. De posse
do gabarito, o coordenador realiza o lançamento das informações, disponibiliza as notas para a
conferência e entrega dos resultados aos alunos.
Figura 5 – Diagrama de Processo para Realização do Simulado
Fonte: Os autores (2019). 2 Disponível em: http://astah.net/download. Acesso em: 08 jun. 2019.
32
3.4.2
Diagrama de Casos de Uso
O diagrama de casos de uso é um diagrama UML que define todas as funcionalidades que
foram propostas pelo sistema, ou seja, que representam os requisitos funcionais. Um diagrama
de caso de uso demonstra o comportamento produzido pelo sistema na visão de atores
3externos
(BOOCH et al., 2006), como é possível perceber através da Figura 6.
Figura 6 – Diagrama de Caso de Uso
Fonte: Os autores (2019).
A partir da utilização da solução foi possível ao coordenador automatizar as inscrições
dos alunos, sem que fosse necessária intervenção direta da coordenação do curso, demandando
menos tempo no gerenciamento das inscrições, bem como na emissão dos cartões-resposta
personalizados de acordo com os dados das inscrições. Foi importante também o gerenciamento
automático de prazo no sistema de inscrições, auxiliando a coordenação a preparar o material
impresso em tempo hábil e deixando o aluno ciente das informações sobre o simulado.
Com os gabaritos lançados pelos próprios alunos, tornou-se possível disponibilizar de
forma mais rápida o levantamento de informações sobre os desempenhos de cada professor. Essa
informação auxilia a coordenação a mensurar o trabalho que está sendo desenvolvido por cada
professor, e desta maneira, avaliar o ensino naquela turma.
A disponibilidade das informações dos simulados fornece ao professor dados para au-
toavaliação e avaliação dos alunos sob seu cuidado. Através desta metodologia de trabalho,
foi possível obter subsídio para diversificar a abordagem metodológica quando se observou
necessário por parte dos professores.
33
3.4.3
Diagrama de Classes
O diagrama de classes é o diagrama UML mais presente nos projetos de software, isso se
deve ao seu caráter intrínseco de relacionar as classes que fazem parte de um sistema. Em suma,
o diagrama subsidia a documentação da estrutura das classes de um sistema, seus atributos, suas
ações e interações com outras classes, estabelecendo relacionamentos com outros diagramas.
Na Figura 7 pode-se observar a representação das classes que compõem o subsistema abordado
neste trabalho.
Figura 7 – Diagrama de Classes
Fonte: Os autores (2019).
Diante do que foi levantado na fase de projeto, foi observado que a estrutura derivada do
processo documentado nas Figuras 5 e 6 deu origem às classes constantes na Figura 7. Dentre
34
as classes relacionadas, está a classe “Usuario”. A classe “Usuario” é responsável por definir
os atributos de acesso ao sistema, definindo a qual grupo de atores ele pertence. Esta definição
ocorre a partir de um dos atributos da classe chamado “tipo”, que é um atributo que recebe
valores de texto, e de um identificador único, o atributo “id”. Outro atributo importante para
garantir o acesso seguro ao sistema é a validação do status do usuário. O status pode receber
valores “verdadeiro” ou “falso”, impedindo assim, que usuários cadastrados e não autorizados,
como ex-alunos e ex-professores, continuem acessando o perfil.
A classe “Inscricao” decorre na necessidade de gerenciar os prazos de inscrições dos
simulados, registrando o ato de inscrição, repassando informações complementares ao aluno,
e repassar os dados à coordenação. Para identificar de maneira única, cada inscrição recebe
um atributo alfanumérico chamado “idInscri”, contendo também informações sobre o aluno, o
simulado, data e hora da inscrição e outros.
Entre as classes mais importantes está a classe “Simulado”. Como principais atributos,
os objetos desta classe recebem dados como o prazo de inscrição, se haverá redação, tempo de
prova, data de aplicação, status de execução e um resumo da quantidade das matérias e questões
aplicadas. Como nas demais classes, a classe “Simulado” também recebe um identificador único,
chamado “idSim”.
Com o simulado realizado é necessário adicionar as respostas dos alunos no sistema.
Para isso, o aluno deve estar logado em seu perfil, localizar o respectivo simulado e adicionar as
respostas do gabarito. A classe “Gabarito” vai conter tanto o gabarito do aluno quanto o gabarito
oficial, diferenciando-os por um atributo chamado “gabOfic”, do tipo booleano, atribuindo o
valor verdadeiro quando o objeto daquela classe for um gabarito oficial. Para identificar um
objeto específico da classe, foi criado um atributo de identificação chamado “idGab”. Na classe
gabarito estão contidos os números das questões e as respectivas respostas definidas no respectivo
cartão. Desta maneira é feito um comparativo entre as respostas do aluno com as respostas do
gabarito oficial previamente definido, gerando assim a estatística do desempenho.
Uma vez que foi concluída a estruturação da documentação que serviu de base para o
projeto, bem como a compreensão de como cada classe, atributo e método que foi utilizado,
o próximo passo foi dar início à codificação do módulo, concretizando através do uso das
ferramentas e das metodologias definidas, a construção da interface, criação das camadas da
aplicação e definição das regras de negócio.
35