Yazılımın Yararlı Ömrü ve Değerlendirilmesi

Seguindo Catalysis, partiu-se do domínio do problema, onde foram identificados os principais objetos e ações envolvidos. Em seguida, estas primeiras especificações foram refinadas em mode- los de casos de uso e modelos de tipos. A Figura 33 mostra este modelo de tipos construído na MVCASE. Nesta figura não são mostrados os atributos de cada tipo, para enfatizar os relaciona- mentos entre eles.

Um professor (Teacher) pode criar várias disciplinas (Discipline) para determinado curso (Course) e definir várias aulas (Lesson) e provas (Test) para cada disciplina. Se o professor de- sejar, pode também definir exercícios (Exercise) de múltipla escolha (Option) para cada aula, com até cinco alternativas. As provas da disciplina agregam várias questões (Question) e cada questão pode agregar até cinco alternativas (Option). As respostas dos exercícios (ReplyExercise) e das questões das provas (Question) são armazenadas para que o professor possa definir uma média final da disciplina para o estudante. Em relação à prova, o professor pode definir várias questões e atribuir um número de questões para que cada estudante responda. Por exemplo, um professor de- fine trinta questões para uma prova de determinada disciplina e define que os estudantes precisam responder apenas dez questões. Quando o estudante acessar a prova, são escolhidas, aleatoria- mente, dez questões entre as trinta definidas pelo professor. A prova gerada para o estudante é armazenada em uma nova classe.

Ao definir uma disciplina, podem ser indicadas várias bibliografias (Bibliography). Cada dis- ciplina também pode estar associada a requisitos (Requirements), que são outras disciplinas obri- gatórias para realização da disciplina. Quando um estudante matriculado acessa e realiza os exer-

Figura 33: Tela da ferramenta MVCASE com o modelo de tipos.

cícios de uma aula de determinada disciplina, é gerado um acompanhamento (Accompaniment) do estudante para a aula. Uma aula pode agregar vários materiais (Material). O material pode ser uma mídia ou uma composição de cenas (objeto multimídia). Uma composição de cenas pode agregar uma ou mais cenas, e cada cena agrega uma ou mais mídias, que podem ser do tipo imagem, texto, áudio ou vídeo.

Durante a criação dos modelos, os Engenheiros de Software trabalharam em conjunto sobre os artefatos de modelagem. O plug-in para o CVS da MVCASE foi utilizado para acesso remoto ao repositório do projeto, auxiliando na transferência dos artefatos através da rede e no trabalho distribuído. Para ilustrar a utilização deste plug-in, considere o modelo da Figura 34.

Dois Engenheiros de Software eram responsáveis pelo modelo da Figura 34, modificando-o ao mesmo tempo. Um deles identificou que, ao invés de armazenar a idade do aluno (a), seria mais interessante armazenar a sua data de nascimento. O outro identificou a necessidade de um campo para que o professor insira comentários gerais sobre uma determinada prova (b). A seguir, cada Engenheiro de Software obteve uma cópia deste artefato, e realizou a sua mudança, conforme ilustra a Figura 35. Do lado esquerdo, o Engenheiro de Software A modificou o atributo age para birthDate (a). Do lado direito, o Engenheiro de Software B adicionou um novo atributo:

Figura 34: Modelo com algumas classes do Framework EAD.

Figura 35: Mudanças sendo efetuadas por diferentes Engenheiros de Software ao mesmo tempo. Após terem realizado as mudanças, os Engenheiros de Software utilizaram o plug-in do CVS para enviar os artefatos alterados novamente para o repositório. O primeiro Engenheiro de Soft- ware a enviar os artefatos alterados para o repositório não teve nenhum problema, pois a versão anterior que se encontrava no repositório é a mesma que ele havia recuperado. Já o segundo re- cebe uma mensagem informando que o artefato que está no repositório (que é a nova versão posta pelo primeiro Engenheiro de Software) é diferente daquele que havia sido por ele recuperado. É necessário então realizar a combinação (merge) das duas versões. Para isso, o Engenheiro de Soft- ware utiliza o plug-in para CVS da MVCASE, que tenta realizar a combinação automaticamente. Como neste caso cada Engenheiro de Software alterou parte diferente do modelo, não ocorre ne- nhum conflito, e esta operação termina sem problemas. O artefato final é então enviado para o

repositório, e passa a conter ambas as alterações (Figura 36). Neste caso, não ocorreu conflito, mas caso este tivesse ocorrido, o Engenheiro de Software deveria então resolvê-lo manualmente, diretamente no arquivo XMI.

Figura 36: Versão final do artefato, que contém ambas as alterações: (a) e (b).

Prosseguindo com Catalysis, partiu-se para o segundo nível: Especificação dos Componen- tes. Neste passo, os Engenheiros de Software identificaram quais seriam os componentes do fra- mework, adicionando também quais as operações a serem implementadas. Foram identificados neste framework 21 componentes de acesso a banco, e 7 componentes de negócio. As dependên- cias e relacionamentos entre os componentes também foram especificadas.

No terceiro nível de Catalysis, realizou-se o projeto interno dos componentes. Foi utilizada para isso a tecnologia EJB (DEMICHIEL, 2002), que auxilia na construção de componentes distri-

buídos com suporte à persistência em Banco de Dados. Neste caso, a MVCASE possui um plug-in que gera automaticamente a estrutura de componentes EJB a partir dos modelos de mais alto nível. A Figura 37 mostra um diagrama de componentes com alguns dos componentes EJB gerados pela MVCASE. A dependência entre os componentes transientes (estereótipo EJBSession) e persisten- tes (estereótipo EJBLocalEntity), formando uma arquitetura em camadas, também é especificada na ferramenta.

Finalmente, foi utilizado o JavaGeneratorPlugin, um plug-in da MVCASE para a geração de código Java. O código gerado foi compilado e executado. Foi utilizado o servidor de componentes JBoss (JBOSS, 2005) para execução. Testes foram realizados, utilizando a C-CORE para auxi-

liar nas tarefas de depuração. Correções e alterações foram realizadas diretamente nos modelos, utilizando a MVCASE para gerar novamente o código correspondente, ou diretamente no código, utilizando a C-CORE para persistir as mudanças em XMI, mantendo os modelos atualizados. Após

Figura 37: Diagrama que mostra parte dos componentes do framework EAD.

a finalização do framework, a ferramenta SoCManager ficou responsável pelo gerenciamento das alterações sobre os artefatos construídos, seguindo o processo definido em (CUNHA, 2005).

Uma vez finalizado, esse framework pode ser então reutilizado na construção de aplicações do domínio de educação à distância. Na próxima seção é apresentada a segunda parte deste estudo de caso, onde uma aplicação que reutiliza os componentes deste framework foi desenvolvida.