LiA KAZAN'IN ccBiR YAŞAMı!l:

O protótipo construído exigiu a criação de um banco de dados para a gravação das informações das aulas.

A ideia é que cada aula de uma determinada disciplina, tenha cenários com “n” histórias OCC-RDD, exemplificando, em uma disciplina de redes de computadores, da aula 02 (segunda semana), tenha uma série de cenários OCC, com “tramas” que define o posicionamento de cada cena OCC-RRD na história. Como demonstrado no terceiro estudo de caso do capítulo 3, pode-se iniciar com uma cena “Catástrofe”, contando uma história, seguido de cenas “Objetivo” e “Contratempos”.

Visualizado os pontos principais de como deve funcionar o protótipo, sugere-se um modelo conceitual a partir do MER (Modelo de Entidade e Relacionamento) do protótipo que será utilizado para orientar o desenvolvimento propriamente dito.

“O modelo relacional é o mais empregado para descrever como os dados estão armazenados num banco de dados”. (LEITE, 2008, pg. 6).

“O modelo de dados entidade-relacionamento (ER) nos permite descrever os dados envolvidos em uma empresa do mundo real em termos de objetos e seus relacionamentos e é amplamente utilizado para desenvolver um projeto inicial de banco de dados”. (GEHRKE, J. & RAMAKRISHNAN, 2008, pg. 21).

Segundo Coronel & Rob (2011), “a modelagem de dados é um processo iterativo e progressivo. Começa-se com uma compreensão simples do domínio do problema e, conforme essa compreensão se desenvolve, o nível de detalhes do modelo também se amplia”.

Para a construção do MER foi utilizada uma ferramenta de apoio “DIA”. A princípio para levantamento de requisitos para a construção do protótipo definiu-se quatro entidades: tbl_aula; tbl_questionarioAula; tbl_tematica; tbl_questionarioDET, com seus atributos e relacionamentos.

Definindo de maneira sucinta os elementos que formam um MER, Coronel & Rob (2011), definem “entidade como qualquer coisa sobre a qual sejam coletados e armazenados dados. Uma entidade é representada no diagrama por um retângulo”.

Ainda conforme Coronel & Rob (2011) “cada entidade é definida por um conjunto de atributos que descrevem suas características particulares [...] e os relacionamentos descrevem associações entre dados [...] os relacionamentos são representados por um losango conectados às entidades”.

Para a representação do MER foi escolhido à notação original de Peter Chen, que apresentou o primeiro modelo de dados ER em 1976.

Figura 53– Modelo de Entidade e Relacionamento (MER) do protótipo Fonte: próprio autor

A figura 53 representa o MER – Modelo Entidade Relacionamento proposto para a ferramenta discutida neste trabalho. A seguir, o memorial descritivo das tabelas e seu funcionamento.

1- Entidade [tbl_tematica]: Inclusão dos dados principais quanto ás aulas que serão armazenadas, tem os seguintes atributos:

a: {[tem_codigo]}  número sequencial inteiro que representa a chave primária da entidade;

b: {tem_titulo}  indica a partir de um conjunto de palavras o contexto a ser seguindo na aula;

c:{tem_dataCriacao}  informação de quando foi criada a aula, representa um atributo de data;

d: {tem_descricao}  atributo que guarda as características que descrevem a aula; 2- Entidade [tbl_aula]: Recebe os dados da cena de aula a ser inserida no sistema, é nesse momento que o “Cadastrador de Aula” se ocupa em fornecer os dados como:

a: {aul_tipo}  tipo de cena de uma aula que pode ser “Objetivo”, “Contratempo” ou “Catástrofe”, segundo a técnica OCC-RDD;

b: {aul_titulo}  identifica a cena aula no sistema, é uma frase que exprime o contexto a ser tratado na cena de aula;

c: {aul_cor}  determina uma cor para a cena de aula em questão, para que possa ser identificado com mais facilidade;

d: [{aul_codigo}]  código sequencial numérico inteiro que funciona como uma chave primária da entidade representa uma numeração de cena de aula que a distingue das demais, pois uma única aula pode ter varias cenas OCC-RDD;

e: {aul_conteudo}  o texto narrativo, fornecendo ao leitor o entendimento sobre o contexto da cena de aula que esta sendo tratada;

f: {(tem_codigo)}  código da temática, representa um código de chave estrangeira, que conecta uma aula ao seu conjunto de cenas de aula.

3- Entidade [tbl_questionarioaula]: Mantém os dados de parametrização para os cenários no que tange ao questionário que poderá ser usado pelo “Cadastrador de Aula” o uso é optativo, e descreve como se comportará o questionário sobre o a cena de aula, seus atributos são:

a: {ques_tipo}  indica se o registro será de um questionário dissertativo ou de múltipla escolha através dos caracteres D = dissertativo ou M = múltipla escolha;

b: {ques_codigo}  número sequencial inteiro que representa a chave primária da entidade;

c: {ques_listasn}  determina se o “Cadastrador de Aula” optou por imprimir um gabarito vazio de uma lista numerada com cabeçalho informativo sobre a atividade que representa a entrega de exercício escrito ou participação do aluno apondo sua assinatura;

d: {ques_numeroquestoes}  indica quantas questões o questionário de aula terá, esse controle será feito pela ferramenta que lê esse atributo e requisita então “n” vezes sendo que cada vez é uma questão a ser editada;

e: {(ques_aul_codigo)}  representa a chave estrangeira que conecta uma aula e seu devido questionário.

4- Entidade fraca [tblquestionarioDET]: Mantém os dados oriundos da parametrização do questionário, que a partir do gerenciamento feito pela ferramenta, permite a inserção dos dados:

a: {(ques_det_sequencia)}  chave estrangeira obtida do questionário, liga o questionário ao seu conjunto de enunciados;

b: {ques_det_enunciado}  registra o enunciado da pergunta a ser tratada, se os dados de parametrização estiverem apontando para o questionário dissertativo, somente esse campo deverão ser requeridos obrigatoriamente pela ferramenta, os outros campos ficarão nulos, mas se a parametrização determina questionário de múltipla escolha, a rotina será repetida “n” vezes até que o total de questões seja editado, neste caso os seguintes campos deverão ser preenchidos, ressalta-se que o questionário de múltipla escolha esta configurado para somente quatro alterativas possíveis.

c: {ques_det_alternativa_A}  campo com a alternativa de resposta identificada como opção “A”;

d: {ques_det_alternativa_B}  campo com a alternativa de resposta identificada como opção “B”;

e: {ques_det_alternativa_C}  campo com a alternativa de resposta identificada como opção “C”;

f: {ques_det_alternativa_D}  campo com a alternativa de resposta identificada como opção “D”;

d: {ques_det_alternativa_CERTA}  campo com a alternativa de resposta identificada como opção correta.

Nesta seção apresentou-se o MER como uma forma expressar a ideia inicial para a construção de uma ferramenta de autoria para histórias OCC-RDD.

5.6 Considerações

Este capítulo teve como objetivo propor uma ideia de software de autoria de histórias OCC-RDD. No ponto de vista do desenvolvimento, notou-se que é possível produzir histórias utilizando-se da técnica OCC-RDD. O protótipo foi representado através das suas telas principais de cadastros de uma aula, inserção da história e cenas OCC.

A ferramenta também foi representada a partir da notação UML, sendo exemplificada através dos diagramas de atividades. Como uma forma de facilitar o entendimento do funcionamento do sistema, usou-se a notação matemática da teoria de conjuntos, onde foi possível visualizar o comportamento dos dados no momento de uma inserção, exclusão e deleção.

Foi apresentado um modelo de entidade e relacionamento, como uma opção de interação entre o projetista, o programador de aplicações e o usuário final, o modelo é uma sugestão de compreensão do funcionamento dos dados.

Sugeriu-se para a criação de histórias OCC-RDD uma orientação ao professor, sobre o conhecimento prévio de seu plano de aula, para guiar melhor a criação de sua própria história. Observaram-se alguns pontos importantes para que o cenário não fuja do modelo ideal de uma fábula OCC-RDD, o professor precisa conhecer a técnica OCC-RDD e seu objetivo; isso é fundamental para o momento da narrativa, outro ponto importante, as tramas de cenários

cenas, ficou sobre responsabilidade do “Cadastrador de aula”; essa condição limitou o protótipo para uma ferramenta semiautomática. Ainda como sugestão a entrada de questionários dissertativos ou múltiplas escolhas, para testar o conhecimento dos aprendizes no momento em que a aula é narrada.

O protótipo limitou-se a mostrar a criação de história, mas existe a possibilidade da integração de uma base de dados com histórias prontas, para guiar o mestre na criação de sua história, vídeos, cenários em 3D e gamificação, tudo podendo ser inserido desde que não se perca a rigidez da aula.