UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
CENTRO TECNOLÓGICO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
SILVANO NOGUEIRA BUBACK
ODEDoc: Uma Ferramenta de Apoio à
Documentação no Ambiente ODE
Vitória
2007
1
SILVANO NOGUEIRA BUBACK
ODEDoc: Uma Ferramenta de Apoio à
Documentação no Ambiente ODE
Monografia apresentada à Universidade
Federal do Espírito Santo como requisito
parcial para obtenção do título de Bacharel
em Ciência da Computação, na área de
concentração de Sistemas de Informação.
Orientador: Ricardo de Almeida Falbo
Vitória
Outubro, 2007
2
Silvano Nogueira Buback
ODEDoc: Uma Ferramenta de Apoio à
Documentação no Ambiente ODE
Aprovada em 22 de outubro de 2007.
COMISSÃO EXAMINADORA
Prof. Ricardo de Almeida Falbo, D.Sc.
Orientador
Prof. Davidson Cury, D.Sc.
Prof. Julio César Nardi, M.Sc.
3
Agradecimentos principalmente para Deus, pois sem
ele nada faria sentido. Aos meus pais, pois deles tive
todo o apoio necessário para chegar até aqui. Ao
Falbo, pela orientação e paciência.
4
RESUMO
ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE
Silvano Nogueira Buback
Outubro de 2007
Orientador: Prof. Ricardo de Almeida Falbo
A necessidade cada vez mais freqüente por softwares e estes cada vez mais
complexos trazem desafios aos engenheiros de software, principalmente no que diz
respeito à manutenibilidade desses sistemas. A atividade de documentação visa apoiar a
manutenibilidade dos sistemas, porém, para reduzir custos e compensar atrasos,
principalmente da fase de desenvolvimento, a documentação é colocada em segundo
plano, reduzindo a qualidade do software construído e aumentando o custo da
manutenção.
O uso de uma ferramenta que apóie a geração dos documentos pode tornar a
atividade de documentação mais rápida, além de facilitar a atualização quando tais
documentos são alterados. Ainda, a criação de modelos de documento facilita a
padronização dos documentos de uma corporação.
Neste trabalho foi construída a ferramenta ODEDOC, uma ferramenta de apoio à
documentação para o ambiente ODE (Ontology-based software Development
Environment). É apresentado como a ferramenta foi construída e mostrado como ela
pode facilitar a geração e atualização dos documentos pelo uso de modelos de
documentos.
Palavras
chave:
Documentação,
Modelos
de
Documento,
Ambiente
de
Desenvolvimento de Software.
5
SUMÁRIO
Capítulo 1 -
Introdução ............................................................................................... 9
1.1
Objetivo ............................................................................................................. 9
1.2
Metodologia ..................................................................................................... 10
Capítulo 2 -
Automatização do Processo e Documentação ...................................... 12
2.1
CASE ............................................................................................................... 12
2.2
I-CASE............................................................................................................. 14
2.2.1
Framework de Integração ......................................................................... 14
2.2.2
Problemas relacionados à integração........................................................ 16
2.3
Ambientes de Desenvolvimento de Software .................................................. 16
2.4
O Ambiente ODE............................................................................................. 17
2.5
Documentação de Software ............................................................................. 18
Capítulo 3 3.1
Especificação de Requisitos.................................................................. 21
Requisitos Funcionais ...................................................................................... 21
3.1.1
Caso de Uso Editar Modelo de Documento ............................................. 22
3.1.2
Caso de Uso Editar Modelo de Seção ...................................................... 24
3.1.3
Caso de Uso Editar Documento Formatado ............................................. 25
3.1.4
Caso de Uso Editar Seção......................................................................... 26
3.1.5
Caso de Uso Gerar Documento Formatado.............................................. 27
3.2
Especificação de Requisitos Não Funcionais .................................................. 28
3.2.1
Manutenibilidade ...................................................................................... 29
3.2.2
Usabilidade ............................................................................................... 30
Capítulo 4 4.1
Análise .................................................................................................. 31
Modelo de Classes ........................................................................................... 31
4.1.1
Pacote Controle ........................................................................................ 33
4.1.2
Pacote Conhecimento ............................................................................... 33
4.1.3
Pacote Documentacao............................................................................... 35
4.2
Modelagem comportamental ........................................................................... 37
Capítulo 5 -
Projeto................................................................................................... 39
5.1
Plataforma de implementação.......................................................................... 39
5.2
Arquitetura ....................................................................................................... 40
5.3
Pacote Conhecimento.documentacao .............................................................. 43
6
5.3.1
Pacote cdp................................................................................................. 43
5.3.2
Pacote cgd................................................................................................. 45
5.3.3
Pacote cgt.................................................................................................. 45
5.3.4
Pacote cih.................................................................................................. 47
5.3.5
Pacote cci.................................................................................................. 49
5.4
Pacote Ode.documentacao ............................................................................... 51
5.4.1
Pacote cdp................................................................................................. 51
5.4.2
Pacote cgd................................................................................................. 52
5.4.3
Pacote cgt.................................................................................................. 52
5.4.4
Pacote cih.................................................................................................. 53
5.4.5
Pacote cci.................................................................................................. 55
5.5
Implementação................................................................................................. 57
5.5.1
5.6
Gerar Documento Formatado ................................................................... 57
Testes ............................................................................................................... 59
Capítulo 6 -
Conclusões e Perspectivas Futuras ....................................................... 62
6.1
Conclusões ....................................................................................................... 62
6.2
Perspectivas futuras ......................................................................................... 62
7
INDÍCE DE FIGURAS
Figura 2.1 - Arquitetura Conceitual de ODE.................................................................. 17
Figura 2.2 - Ontologia de Artefato (NUNES et al., 2004).............................................. 19
Figura 2.3 - Ontologia de Documentos de Software. ..................................................... 20
Figura 3.1 - Diagrama de Casos de Uso. ........................................................................ 22
Figura 4.2 - Diagrama de pacotes................................................................................... 32
Figura 4.3 - Diagrama de classes parcial do pacote Ode.ControleProcesso.................. 33
Figura 4.4 - Diagrama de classes do pacote Ode.Conhecimento.Documentacao .......... 34
Figura 4.5 - Diagrama de classes do pacote Ode.Documentacao................................... 36
Figura 4.6 – Caso de Uso Exportar Documento............................................................. 38
Figura 5.1 - Arquitetura em camadas. ............................................................................ 41
Figura 5.2 – Comparação entre modelo MVC e o modelo adotado no Ode. ................. 41
Figura 5.3 - Dependência de pacotes de todo o sistema................................................. 42
Figura 5.4 - Pacote Conhecimento.documentacao.cdp................................................... 44
Figura 5.5 - Pacote Conhecimento.documentacao.cgd................................................... 45
Figura 5.6 - Pacote Ode.Conhecimento.Documentacao.Cgt .......................................... 46
Figura 5.7 - Diagrama de classes do pacote ode.conhecimento.documentacao.cih ....... 47
Figura 5.8 - Janela de seleção dos modelos de documentos........................................... 48
Figura 5.9 - Janela de edição dos dados do modelo de documento................................ 48
Figura 5.10 - Janela de edição dos dados do modelo de seção....................................... 49
Figura 5.11 - Diagrama de classes do pacote ode.conhecimento.documentacao.cci ..... 50
Figura 5.12 - Pacote documentacao.cdp......................................................................... 51
Figura 5.13 - Pacote documentacao.cgd......................................................................... 52
Figura 5.14 - Pacote documentacao.cgt.......................................................................... 53
Figura 5.15 - Diagrama de classes do pacote documentacao.cih ................................... 54
Figura 5.16 - Janela de edição dos dados do documento formatado e das seções.......... 55
Figura 5.17 - Diagrama de classes do pacote ode.conhecimento.documentacao.cci ..... 56
8
Capítulo 1 - Introdução
A documentação de software tem a finalidade de comunicar informações
sobre o sistema de software ao qual ela pertence (FORWARD, 2002). Em
outras palavras, documentar é comunicar. Porém a comunicação informal,
essencialmente baseada em palavras, não é suficiente. Além da facilidade de
ocorrerem distorções na compreensão, termo popularmente conhecido como
telefone sem fio, ela não é capaz de resistir ao tempo e não é prática quando a
quantidade de pessoas envolvidas no projeto é muito alta ou quando o mesmo
tem rotatividade alta. Por isto, um processo formal de documentação se faz
necessário.
Assim, a documentação assume um papel imprescindível no processo
de desenvolvimento de software, visto que a mesma está presente em todas as
fases do ciclo de vida do software (PRESSMAN, 2002). Como a demanda por
software cresce continuamente, principalmente no que diz respeito a problemas
que pedem soluções mais complexas, muitas vezes o trabalho de se
documentar torna-se deveras oneroso, sendo usualmente posto de lado em
detrimento a outras atividades, tal como a codificação. Contudo, o engenheiro
de software deve possuir em mente que, sem uma documentação consistente
e detalhada, é praticamente impossível garantir a manutenibilidade.
1.1
Objetivo
O objetivo deste trabalho é desenvolver uma ferramenta de apoio à
documentação que possa auxiliar na geração da documentação do projeto. O
objetivo não é somente gerar a primeira documentação, mas sim auxiliar na
manutenção da mesma, permitindo que as alterações feitas no projeto possam
ser refletidas nos documentos.
Ainda, é fundamental que a geração de documentos seja integrada ao
ambiente ODE (Ontology-based software Development Environment) (FALBO
et al., 2003), o Ambiente de Desenvolvimento de Software (ADS) em
desenvolvimento no Laboratório de Engenharia de Software da Universidade
Federal do Espírito Santo (LabES). A integração da ferramenta de apoio à
9
documentação a ODE vai permitir que as várias ferramentas do ambiente
possam
utilizá-la,
evitando
a
construção
de
soluções
isoladas
de
documentação, o que pode comprometer a integração de ferramentas.
Como diferencial em relação aos outros dois trabalhos de pesquisa
sobre documentação desenvolvidos para o ODE (SOARES, 2002) (SILVA,
2004), este trabalho tem por objetivo tornar a documentação um processo
simples de ser feito, não sendo necessários conhecimentos sobre XML, HTML
ou qualquer outra tecnologia. O objetivo é que o gerente de documentação
conheça apenas o ADS ODE.
1.2
Metodologia
A metodologia adotada no desenvolvimento deste trabalho pode ser
dividida em três fases: revisão bibliográfica sobre ferramentas CASE e ADS,
definição do escopo do trabalho e desenvolvimento.
Ainda na fase de revisão bibliográfica foi delimitado o escopo inicial do
trabalho, porém, esse escopo original incluía também a persistência de
artefatos em XML para apoiar a ferramenta de gerência de configuração
(NUNES, 2005). Na fase de definição do escopo, decidiu-se abandonar essa
idéia, concentrando a atenção deste trabalho apenas na documentação de
artefatos produzidos internamente a ODE.
A motivação para retirar a persistência de artefatos em XML surgiu da
separação entre a documentação e a gerência de configuração. A geração dos
artefatos em XML permitia atender às duas soluções, porém não atendia de
forma razoável a nenhuma das duas. Na documentação, o uso do artefato em
XML facilitava a leitura dos dados, porém exigia a construção das folhas de
estilo para gerar a apresentação, uma tarefa que exigia um conhecimento
técnico sobre XML e tecnologias relacionadas. Na gerência de configuração, as
versões antigas dos artefatos não podiam ser manipuladas de forma
transparente pelas ferramentas, impedindo que dois usuários fossem capazes
de visualizar, através da ferramenta que as gerou, duas versões distintas de
um mesmo artefato.
10
1.3
Organização da monografia
Além deste capítulo, esta monografia contém mais cinco capítulos, a
saber:
• Capítulo 2 – Automatização do Processo e Documentação: neste
capítulo discute-se a evolução das ferramentas CASE até os se
chegar aos ADSs. Também é enfatizada a importância da
documentação de software, além de uma breve apresentação do
ADS ODE;
• Capítulo 3 – Especificação de Requisitos: neste capítulo são
apresentados os requisitos funcionais e não-funcionais para o
desenvolvimento da ferramenta de apoio à documentação;
• Capítulo 4 – Análise: neste capítulo é apresentada a modelagem
de análise da aplicação, com diagramas de classes e de
seqüência;
• Capítulo 5 – Projeto: é apresentado o projeto da ferramenta,
levando em consideração os aspectos tecnológicos e requisitos.
Também neste capítulo são descritas as estratégias de
implementação e testes;
• Capítulo 6 – Conclusões e Perspectivas Futuras: neste capítulo é
explicado como este trabalho poderá ajudar na atividade de
documentação além de melhorias e trabalhos futuros que
poderão surgir.
11
Capítulo 2 - Automatização do Processo e
Documentação
Há um provérbio árabe que diz: “Conheces um trabalhador pelas tuas
ferramentas”. Um engenheiro de software, hoje, conhece bem a aplicação
desse ditado. Com softwares cada vez mais complexos, prazos mais curtos e a
necessidade de custos menores, em função de um mercado cada vez mais
competitivo, o desenvolvimento de software tornou-se uma tarefa árdua.
Levantar requisitos, gerar documentação, acompanhar cronograma, gerenciar
riscos, codificar, testar, implantar são algumas das atividades presentes em
qualquer ciclo de desenvolvimento de software que se tornaram praticamente
impossíveis de realizar sem o uso de ferramentas adequadas.
Neste capítulo examinamos a evolução das ferramentas CASE
(Computer-Aided Software Engineering) e a necessidade da documentação de
software, terminando com a apresentação do projeto no qual a ferramenta
desenvolvida por este trabalho está inserida
2.1
CASE
Existem muitas definições para CASE. Segundo (PRESSMAN, 2002),
CASE é uma ferramenta de software apoiada por computador, que assiste
gerentes e profissionais de engenharia de software em toda atividade
associada com o processo de software. Ferramentas CASE automatizam as
atividades de gestão de projetos, gerenciam todos os produtos de trabalho
produzidos ao longo do processo e assistem os engenheiros em seu trabalho
de análise, projeto, codificação e teste. Já o Instituto de Engenharia de
Software (Software Engineering Institute – SEI) (SEI, 2007) define CASE de
uma forma bem direta: CASE é o apoio do computador no processo de
desenvolvimento de software. Essencialmente, a definição do SEI é mais
ampla, não restringindo o conceito de CASE apenas a software.
Em (PRESSMAN, 2002) foi criada uma taxonomia para essas
ferramentas, utilizando como critério a função à qual ela é aplicada. A seguir
temos uma lista dos grupos de ferramentas:
12
•
Ferramentas de engenharia de processos de negócio;
•
Ferramentas de modelagem e gestão de processo;
•
Ferramentas de planejamento de projeto;
•
Ferramentas de análise de riscos;
•
Ferramentas de gestão de projetos;
•
Ferramentas de rastreamento de requisitos;
•
Ferramentas de métricas e gestão;
•
Ferramentas de documentação;
•
Ferramentas de software básico;
•
Ferramentas de garantia da qualidade;
•
Ferramentas de gestão de bases de dados;
•
Ferramentas de gestão de configuração de software;
•
Ferramentas de análise e projeto;
•
Ferramentas de prototipação / simulação;
•
Ferramentas de projeto e desenvolvimento de interfaces;
•
Ferramentas de programação;
•
Ferramentas de desenvolvimento Web;
•
Ferramentas de integração e testes;
•
Ferramentas de análise estática;
•
Ferramentas de análise dinâmica;
•
Ferramentas de gestão de testes;
•
Ferramentas de teste cliente/servidor;
•
Ferramentas de reengenharia;
Apesar da evolução permanente dessas ferramentas, elas não
substituem práticas confiáveis de engenharia de software. Elas devem ser
utilizadas apenas para complementá-las. Sem um processo de software
estabelecido, métodos de engenharia de software e qualidade aprendidos, o
uso dessas ferramentas CASE pode vir a prejudicar o bom andamento do
projeto, tornando-o burocrático e confuso (PRESSMAN, 2002) .
13
2.2
I-CASE
As etapas de desenvolvimento de software são todas interligadas. Os
métodos utilizados para realizar os testes, ao final do processo de
desenvolvimento, estão intimamente ligados aos requisitos colhidos no início
do projeto. Isso torna necessária uma integração muito ampla por parte das
ferramentas CASE. Ferramentas isoladas são muito úteis em determinadas
etapas, porém os resultados obtidos pela integração podem ser muito maiores.
À ferramenta CASE integrada dá-se o nome de I-CASE (Integrated
CASE) (PRESSMAN, 2002). De fato, a integração de ferramentas não é uma
tarefa muito simples de ser feita, principalmente, considerando que, apesar do
processo de desenvolvimento de software ser todo integrado, significados
diferentes
são
atribuídos
às
informações
durante
cada
etapa
do
desenvolvimento. Uma ferramenta CASE totalmente integrada deve refletir
todas as peculiaridades do processo de desenvolvimento, enfatizando as
necessidades de cada etapa. Apesar do significado que cada informação
possui para determinada ferramenta, estas não podem perder o significado
global da informação. Por exemplo, um diagrama de classes é feito a partir dos
requisitos levantados do sistema. A partir dele pode-se derivar o modelo
relacional. Porém, se um requisito a mais for considerado, este pode, por
exemplo, implicar na adição de um atributo em alguma classe. O atributo em
questão deve ser adicionado ao código fonte e, também, deve ser propagado
para o modelo relacional. Apesar dos modelos serem aparentemente
diferentes, todos fazem parte do contexto do software que está sendo
desenvolvido. As alterações feitas em algum dos modelos têm impacto em
muitos outros.
2.2.1
Framework de Integração
Em relação à integração, há dois pontos de visão distintos: o ambiente
do ponto de vista do usuário e o ambiente do ponto de vista do construtor. O
ambiente do usuário é voltado para interface. Este quer ver o quanto bem
integrado está às ferramentas. Já o construtor de ferramentas, preocupa-se
14
com o quão fácil é integrar uma ferramenta ao ambiente (THOMAS et al.,
1992).
De acordo com o modelo de referência proposto em (THOMAS et al.,
1992), há quatro dimensões de integração:
•
Integração de dados: é suportada pelo repositório e serviços de
integração de dados;
•
Integração de controle: é suportada pela gerência de processos e
serviços de mensagens;
•
Integração de apresentação: é suportada pelos serviços de
interface com o usuário;
•
Integração de processo: garante que a ferramenta interage
efetivamente no apoio a um processo definido.
Integração de dados
A informação manipulada pelas ferramentas inclui dados persistentes e
não-persistentes (que não sobrevivem após a execução das ferramentas e que
são compartilhados e trocados entre elas). O objetivo é manter a informação
consistente, independentemente de quantas partes estão sendo operadas e
transformadas pelas ferramentas (THOMAS et at., 1992).
Integração de Controle
Para ferramentas compartilharem funcionalidades, elas precisam ser
capazes de comunicar as operações que devem ser executadas. Como as
operações requerem dados, as ferramentas também devem comunicar ou
referenciar dados. Neste contexto, a integração de controle complementa a
integração de dados.
Integração de dados diz respeito à representação dos dados, conversão
e tarefas de armazenamento. Integração de controle diz respeito à
transferência, controle e compartilhamento de serviços (THOMAS et at., 1992).
Integração de Apresentação
O objetivo da integração de apresentação é aumentar a eficiência e a
efetividade da interação do usuário com o ambiente, reduzindo o esforço
cognitivo (THOMAS et at., 1992). Ela diz respeito à forma como os dados são
15
apresentados e os recursos acessados. A uniformização da apresentação torna
o aprendizado de ferramentas novas muito mais rápido e fácil
Integração de Processos
O objetivo da integração de processo é garantir que as ferramentas
interagem de forma eficaz com base em um processo definido.
Uma ferramenta incorpora um conjunto de concepções sobre o processo
que pode ser usado. Duas ferramentas são bem integradas em relação ao
processo se suas concepções são consistentes (THOMAS et at., 1992).
2.2.2
Problemas relacionados à integração
A maior parte das pesquisas e desenvolvimento de ferramentas CASE
integradas está focada na infra-estrutura e mecanismos para integração, como
funcionalidades de usuários e mecanismos de troca de dados entre as
ferramentas. Não há tantas pesquisas referentes à semântica dos dados,
sendo esta o objetivo final da integração: integrar ferramentas sem que elas
percam a semântica da informação que está sendo manipulada. Também há
problemas de muitas ferramentas CASE não terem sido implementadas em
uma arquitetura em que a integração fosse possível. Desta forma, seria
necessário remodelar toda ferramenta, o que é, na maioria das vezes, inviável
para os negócios da empresa. Questões de estratégia por parte das empresas
também impedem a integração real. Muitas empresas já possuem, por meio de
suas ferramentas, uma grande parcela do mercado. Não seria interessante
para elas permitir que algumas de suas ferramentas possam ser substituídas
pelas dos concorrentes. A integração ocorre apenas entre ferramentas da
própria empresa desenvolvedora, ou seja, a camada de integração das
ferramentas existe, em parte, porém são proprietárias.
2.3
Ambientes de Desenvolvimento de Software
Como a integração de ferramentas CASE produzidas sem uma
preocupação prévia com esse aspecto revelou-se utópica e a necessidade de
ferramentas que apoiassem todas as etapas do desenvolvimento de software
16
cresce cada vez mais, começaram a surgir os Ambientes de Desenvolvimento
de Software (ADSs). Um ADS apóia todas as etapas do desenvolvimento,
consistindo ainda de ferramentas separadas, porém as ferramentas do ADS
são construídas sobre um núcleo comum, o que facilita a integração.
Um tipo de ADS merece destaque: os Ambientes de Desenvolvimento
de Software Centrados em Processo. Esses ambientes exploram uma
representação explícita do processo de software para guiar e auxiliar os
desenvolvedores no desenvolvimento de software. Os processos são
modelados no ADS e a execução dá-se quando os agentes, humanos ou não,
executam as atividades decorrentes do processo.
2.4
O Ambiente ODE
Ontology-based software Development Environment (ODE) é um
ambiente que vem sendo desenvolvido no Laboratório de Engenharia de
Software (LABES) da Universidade Federal do Espírito Santo. O ambiente é
um ADS Centrado em Processo e baseado em ontologias que possui uma
infra-estrutura de gerência do conhecimento. Em ODE, parte-se do
pressuposto que, se as ferramentas de um ADS são construídas baseadas em
ontologias, a integração delas pode ser facilitada, pois os conceitos envolvidos
são bem definidos pelas ontologias (FALBO et al., 2003).
Dentre as ontologias que compõem a base ontológica de ODE, tem-se a
ontologias de processo de software (BERTOLLO, 2006), de qualidade de
software (FALBO et al., 2002) e de artefatos de software (NUNES, 2005),
utilizada neste trabalho.
Para manter a amarração semântica entre os objetos de ODE e agregar
as ontologias ao ambiente, foi proposta uma arquitetura de três níveis (RUY,
2006):
Figura 2.1 - Arquitetura Conceitual de ODE
17
•
O Nível Ontológico é responsável pela descrição das ontologias.
O pacote Ontologia contém as classes que definem uma
ontologia de certo domínio e seus elementos. As instâncias das
classes do nível ontológico servem de base para a definição das
classes dos outros níveis.
•
O Meta-Nível abriga as classes que descrevem o conhecimento
em relação a um domínio de aplicação. Suas classes são
derivadas das ontologias e as instâncias dessas classes atuam
no papel de conhecimento sobre os objetos do nível base. Elas
constituem o conhecimento do ambiente, que pode ser utilizado
por qualquer ferramenta que o compõe.
•
O Nível Base define as classes responsáveis por implementar as
aplicações no contexto do ambiente (funcionalidades da infraestrutura e suas ferramentas). Essas classes são também
derivadas das ontologias, mas tipicamente incorporam detalhes
não descritos por elas, necessários para implementar as
aplicações.
2.5
Documentação de Software
Um documento de software pode ser definido como um artefato cuja
finalidade é comunicar uma informação sobre o sistema de software ao qual ele
pertence (FORWARD, 2002). Em outras palavras, documentar é comunicar.
Segundo Ambler (AMBLER, 2004), do ponto de vista da modelagem ágil, um
documento é qualquer artefato externo ao código fonte cujo propósito seja
transmitir informação de uma maneira persistente. Já um modelo é uma
abstração que descreve um ou mais aspectos de um problema ou de uma
solução potencial para resolver um problema. Alguns modelos podem se tornar
documentos, ou incluídos como parte deles, ou simplesmente serem
descartados quando cumprirem seu papel. Por fim, código fonte é uma
seqüência de instruções, incluindo os comentários que descrevem essas
18
instruções, para um sistema de computador. O termo documentação inclui
documentos e comentários de código fonte.
O objetivo deste trabalho é desenvolver uma ferramenta de apoio à
documentação em ODE. Como foi dito anteriormente, ODE é um ADS baseado
em ontologias. As ontologias são a base para a integração das ferramentas em
ODE. Assim, é natural que uma ferramenta de documentação inserida no
contexto de ODE seja apoiada por uma ontologia de documentos, que, por sua
vez, é parte da ontologia de artefatos (NUNES et al., 2004), parcialmente
mostrada na Figura 2.2.
produto
+super-artefato
0..*
<<Conceito>>
Atividade
0..*
0..*
0..*
insumo
(from Ontologia de Processo)
Recurso Humano
<<Conceito>> 0..*
Artefato +sub-artefato
(from Ontologia de Processo)
0..*
0..*
dependência
<<Conceito>>
Documento
<<Conceito>>
0..*
<<Conceito>>
Diagrama
<<Conceito>>
0..*
0..*
aprovação
<<Conceito>>
Artefato de Código Componente de Software
<<Conceito>>
Produto de Software
Figura 2.2 - Ontologia de Artefato (NUNES et al., 2004)
Segundo (NUNES et al., 2004), documentos são artefatos de software
não passíveis de execução, constituídos tipicamente de declarações textuais,
normalmente associados a padrões organizacionais (roteiros) que definem a
forma como eles devem ser produzidos. Exemplos de documentos incluem
documentos de especificação de requisitos, planos de projeto, planos de
qualidade, relatórios de avaliação de qualidade, entre outros. A Figura 2.3
apresenta a ontologia de documento de software proposta em (NUNES et al.,
2004). Os conceitos de Artefato, Procedimento e Roteiro foram importados da
ontologia de processo de software (BERTOLLO, 2006), indicando a integração
entre essas ontologias.
19
<<Conceito>>
Procedimento
(f rom Ontologia de Processo)
0..*
+super-artefato
<<Conceito>>
+sub-artefato <<Conceito>>
0..*
Artefato 0..*
0..*
Diretriz
(f rom Ontologia de Processo)
dependência
0..*
<<Conceito>>
0..*
Roteiro
(f rom Ontologia de Processo)
aplicação
+sub-modelo-documento
<<Conceito>>
Documento
0..*
0..*
<<Conceito>>
Modelo Documento
1
0..*
+super-modelo-documento
1
0..*
0..*
0..*
<<Conceito>> 0..*
correspondência
Seção
0..1
+super-seção
0..*
0..1
<<Conceito>>
Modelo Seção
0..*
opcional
+modelo-super-seção
+modelo-sub-seção
0..1
+sub-seção
Figura 2.3 - Ontologia de Documentos de Software.
De acordo com a arquitetura de ODE, apresentada na Figura 2.1, a
ontologia acima vai deu origem a classes nos níveis de conhecimento e base,
conforme discutido no Capítulo 5.
20
Capítulo 3 - Especificação de Requisitos
Neste capítulo são apresentados os requisitos funcionais e nãofuncionais para o desenvolvimento da ferramenta de apoio à documentação do
ambiente ODE, denominada ODEDoc. Esses requisitos foram adaptados e
reformulados a partir dos requisitos de uma outra ferramenta de apoio à
documentação, XMLDoc, desenvolvida em (SILVA, 2004) e (SOARES, 2002).
Na seção 3.1 tratamos dos requisitos funcionais, ou seja, das necessidades do
sistema. Na seção 3.2 são tratados os requisitos não-funcionais.
3.1
Requisitos Funcionais
Em se tratando de requisitos funcionais, os modelos de casos de uso,
juntamente com suas descrições, fornecem uma eficiente forma de modelar
esses requisitos. Tais modelos dão ao desenvolvedor uma visão externa do
problema a ser capturado, mostrando a interação entre o usuário e o sistema.
Os casos de uso possuem dois importantes papéis (FALBO, 2000):
•
Capturar os requisitos funcionais do sistema. Um modelo de caso
de uso define o comportamento de um software (e a informação
associada) através de um conjunto de casos de uso. O ambiente do
sistema é definido pela descrição dos diferentes atores. Esses atores
utilizam o sistema através de um número de casos de uso;
•
Oferecer uma abordagem para a modelagem de sistemas. Para
gerenciar a complexidade de sistemas reais, é comum apresentar os
modelos do sistema em um número de diferentes visões. Em uma
abordagem guiada por casos de uso, pode-se construir uma visão
para cada caso de uso, isto é, em cada visão são modelados apenas
aqueles elementos que participam de um caso de uso específico. Isto
21
significa que um modelo de sistema completo só é visto através de
um conjunto de visões.
A Figura 3.1 mostra o diagrama de casos de uso para o
desenvolvimento de ODEDoc. O ator Desenvolvedor pode criar um documento
formatado e solicitar a geração dos documentos formatados do projeto. Os
documentos formatados são gerados seguindo as instruções de modelos de
documento, criados pelo Gerente de Documentação.
Figura 3.1 - Diagrama de Casos de Uso.
A seguir são apresentadas as descrições dos casos de uso.
3.1.1
Caso de Uso Editar Modelo de Documento
Este caso de uso é realizado pelo gerente de documentação e é
responsável por criar, alterar e excluir um modelo de documento. Os cenários
Criar Modelo de Documento, Alterar Modelo de Documento e Excluir Modelo de
Documento compõem este caso de uso.
22
Cursos Normais
Criar Modelo de Documento
O gerente de documentação informa o nome, uma descrição, o título, o
corpo do preâmbulo e o tipo de artefato ao qual se aplica o modelo de
documento. Caso os dados sejam válidos, um novo modelo de documento é
criado. O cenário Criar Modelo de Seção do caso de uso Editar Modelo de
Seção é chamado.
Alterar Modelo de Documento
O gerente de documentação informa o modelo de documento que
deseja alterar e os novos dados. Caso os dados sejam válidos, a alteração é
registrada. Cenários do caso de uso Editar Modelo de Seção podem ser
chamados.
Excluir Modelo de Documento
O gerente de documentação informa o modelo de documento que
deseja excluir. Uma confirmação para a operação é solicitada. Se a exclusão
for confirmada, o modelo de documento e seus modelos de seção são
excluídos. Não é permitida a exclusão de modelos de documento que possuam
documentos formatados associados.
Cursos Alternativos
Criar/Alterar Modelo de Documento
Dados inválidos: Uma mensagem de erro é exibida solicitando correção
dos dados.
Excluir Modelo de Documento
Existe um ou mais documentos formatados associados ao modelo de
documento: Uma mensagem de erro é exibida, informando ao gerente de
documentação que existem documentos formatados associados ao modelo de
documento e a exclusão não pode ser realizada.
23
3.1.2
Caso de Uso Editar Modelo de Seção
Este caso de uso permite criar, alterar e excluir modelos de seção de um
modelo de documento. Os cenários Criar Modelo de Seção, Alterar Modelo de
Seção e Excluir Modelo de Seção compõem esse caso de uso.
Cursos Normais
Criar Modelo de Seção
O gerente de documentação informa o modelo de seção pai, caso a
seção a ser criada seja subseção de uma outra, o título, se a existência de
seções desse tipo nos documentos a serem gerados é obrigatória ou opcional,
o corpo de texto básico da seção e, opcionalmente, o tipo de artefato que
deverá compor o corpo do modelo de seção. Caso os dados sejam válidos, um
novo modelo de seção é criado. Caso o modelo de seção não tenha um
modelo de seção pai, ele é adicionado como a última seção do modelo de
documento. Caso contrário, a nova seção deve ser adicionada ao final da lista
de subseções do modelo de seção pai do mesmo.
Alterar Modelo de Seção
O gerente de documentação informa o modelo de seção que deseja
alterar e os novos dados. Caso os dados sejam válidos a alteração é
registrada.
Excluir Modelo de Seção
O gerente de documentação informa o modelo de seção que deseja
excluir. Os dados são apresentados e é solicitada uma confirmação. Se a
exclusão for confirmada, o modelo de seção e todas as suas subseções são
excluídos. Não é permitida a exclusão de um modelo de seção que tenha
seções em documentos formatados associados.
Cursos Alternativos
Criar Modelo de Seção/Alterar Modelo de Seção
Dados inválidos: Uma mensagem de erro é exibida solicitando a
correção dos dados.
24
Excluir Modelo de Seção
Existem uma ou mais seções associadas ao modelo de seção: Uma
mensagem de erro é exibida, informando ao gerente de documentação que
existem documentos formatados associados ao modelo de documento e, por
isso, a exclusão de seção não é permitida.
3.1.3
Caso de Uso Editar Documento Formatado
Este caso de uso é iniciado pelo desenvolvedor e permite criar e excluir
um documento formatado. Os cenários Criar Documento Formatado e Excluir
Documento Formatado compõem este caso de uso.
Cursos Normais
Criar Documento Formatado
O desenvolvedor informa o modelo de documento, o documento ao qual
este documento formatado se aplica e as seções opcionais que deseja. Caso
os dados sejam válidos, o documento formatado é criado. Para cada modelo de
seção obrigatória e para as opcionais do modelo de documento selecionadas, o
cenário Criar Seção do caso de uso Editar Seção deve ser realizado.
Alterar Documento Formatado
O desenvolvedor informa o documento formatado que deseja alterar. Os
cenários do caso de uso Editar Seção podem ser chamados.
Excluir Documento Formatado
O desenvolvedor informa o documento formatado que deseja excluir. É
solicitada uma confirmação. Se a exclusão for confirmada, o documento
formatado é excluído, juntamente com todas as suas seções.
Cursos Alternativos
Criar Documento Formatado
Dados inválidos: Uma mensagem de erro é exibida, solicitando correção
dos dados.
25
Excluir Documento Formatado
O documento formatado é corpo de uma seção: Uma mensagem de erro
é exibida informando ao desenvolvedor que o documento formatado é corpo de
uma seção e por isso não pode ser excluído.
3.1.4
Caso de Uso Editar Seção
Este caso de uso permite criar, editar e excluir seções de um documento
formatado. Os cenários Criar Seção, Alterar Seção e Excluir Seção compõem
este caso de uso.
Cursos Normais
Criar Seção
O desenvolvedor informa o modelo de seção e, se este possuir um tipo
de artefato como corpo, deverá informar um artefato que irá compor o corpo da
seção. O artefato deve ser do mesmo tipo que o tipo de artefato do modelo
seção e deve estar entre os sub-artefatos do documento.
Alterar Seção
O desenvolvedor informa o modelo de seção que deseja alterar e os
novos dados. Caso os dados sejam válidos, a alteração é registrada.
Excluir Seção
O desenvolvedor informa a seção que deseja excluir. Os dados são
apresentados e é solicitada uma confirmação. Se a exclusão for confirmada, a
seção é excluída.
Cursos Alternativos
Criar/Alterar Seção
Dados inválidos: Uma mensagem de erro é exibida solicitando a
correção dos dados.
Excluir Seção
Modelo de seção da seção não é opcional: Uma mensagem de erro é
exibida, informando que a seção não pode ser excluída.
26
3.1.5
Caso de Uso Gerar Documento Formatado
Este caso de uso permite ao desenvolvedor gerar um documento
formatado. O documento formatado gerado pode ser exportado ou impresso.
Curso Normal
O desenvolvedor informa o documento formatado que deseja gerar e o
tipo de geração desejado (documento impresso ou em arquivo). Caso o tipo de
geração seja impresso, uma janela solicitando a impressora e a quantidade de
cópias é exibida. Se for escolhida a geração em arquivo, o desenvolvedor deve
informar o formato do arquivo de saída e o destino.
O texto correspondente ao documento é gerado conforme abaixo:
1. O título do texto é o título do modelo de documento associado ao
documento formatado em geração;
2. Após o título, é apresentado o corpo do preâmbulo do modelo de
documento.
3. Cada seção do documento dá origem a uma seção no texto, de
acordo com a ordem especificada pelas seções. As subseções da
seção, analogamente, geram subseções no texto;
Para o preenchimento do conteúdo de uma seção do documento
formatado, o seguinte procedimento é adotado:
1. O título da seção é o título do modelo de seção correspondente;
2. Um texto inicial da seção é produzido a partir do corpo texto do
modelo de seção, sendo que as referências a elementos do
documento, como nome do projeto, equipe, etc, devem ser
substituídas pelos respectivos valores;
3. Se a seção contiver um outro documento como corpo, uma
quebra de página será gerada no texto e o documento
correspondente é gerado, utilizando-se as mesmas regras
descritas aqui, à exceção da numeração das seções do
documento corpo, que serão seções filhas da seção atual;
27
4. Se a seção contiver um diagrama como corpo, uma referência à
exibição do diagrama deve ser feita no corpo de texto, indicando
onde a imagem deve ser exibida;
5. As regras acima se aplicam recursivamente às subseções.
Ao final do processo, uma mensagem é exibida, informando que o texto
foi enviado para a impressora ou que o arquivo foi gerado com sucesso e
mostrando a localização do mesmo.
Cursos Alternativos
Arquivo de saída já existente: Uma mensagem de aviso é exibida,
solicitando a confirmação da sobrescrita do arquivo.
Erro na geração do arquivo de saída: Uma mensagem de erro é exibida,
informando o motivo do erro e o caso de uso é finalizado.
3.2
Especificação de Requisitos Não Funcionais
Na seção anterior foram tratados apenas os requisitos funcionais, ou
seja, aqueles que não levam em consideração a tecnologia a ser utilizada na
implementação do sistema. Agora, são tratados os requisitos não funcionais
requeridos
pelo
software.
Esses
levam
em
consideração
aspectos
tecnológicos, juntamente com suas imperfeições, e podem determinar o
sucesso ou o fracasso de um sistema, sendo o diferencial entre dois produtos
que satisfazem aos mesmos requisitos funcionais do usuário.
Dentre os requisitos não funcionais, podemos citar (ISO, 1999):
•
Confiabilidade: diz respeito à capacidade do software manter seu
nível de desempenho, sob condições estabelecidas, por um período
de tempo. Tem como sub-características: maturidade, tolerância à
falhas, recuperabilidade e conformidade;
•
Usabilidade: refere-se ao esforço necessário para se utilizar um
produto de software, bem como o julgamento individual de tal uso por
um
conjunto
de
usuários.
Tem
como
sub-características:
28
inteligibilidade, apreensibilidade, operacionalidade, atratividade e
conformidade;
•
Eficiência: diz respeito ao relacionamento entre o nível de
desempenho do software e a quantidade de recursos utilizados sob
condições
estabelecidas.
Tem
como
sub-características:
comportamento em relação ao tempo, comportamento em relação
aos recursos e conformidade;
•
Manutenibilidade: concerne ao esforço necessário para se fazer
modificações
no
analisabilidade,
software.
Tem
modificabilidade,
como
sub-características:
estabilidade,
testabilidade
e
conformidade;
•
Portabilidade: refere-se à capacidade do software ser transferido de
um
ambiente
adaptabilidade,
para
outro.
capacidade
Tem
para
como
ser
sub-características:
instalado,
coexistência,
capacidade para substituir e conformidade.
Dentre os requisitos não funcionais descritos acima, os de maior
relevância para este trabalho são: Manutenibilidade e Usabilidade.
3.2.1
Manutenibilidade
Manutenibilidade é um critério de qualidade que visa a garantir a
facilidade de alterar futuramente o projeto tecnológico em função de erros de
projeto, novas necessidades do usuário e alterações no ambiente tecnológico
do usuário (XAVIER, 1995).
A manutenibilidade do sistema será dada principalmente pela estrutura
em camadas. A estrutura em camadas provê uma estratégia de como distribuir
a funcionalidade da aplicação entre classes. Além disso, arquiteturas em
camadas provêem direção sobre com que outros tipos de classes uma certa
classe pode interagir e como esta interação acontecerá. Isto aumenta a
extensibilidade, manutenibilidade e portabilidade dos sistemas desenvolvidos
(AMBLER, 1998).
29
A manutenibilidade do sistema será dada, também, pela padronização
de nomes, de documentos e de código, o que aumenta a legibilidade e a
modificabilidade.
3.2.2
Usabilidade
Na medida em que os recursos computacionais foram ficando mais
próximos do usuário final, os sistemas necessitavam de um apresentação
visual mais conveniente. Para auxiliar a comunicação entre o usuário e o
sistema surgiram interfaces com elementos gráficos padronizados (menus,
janelas, botões). O objetivo de uma boa interface homem-máquina é colocar as
funções mais próximas do alcance do usuário, sem confundi-lo. Neste sentido,
a prioridade é o usuário, depois a tarefa que ele irá realizar e, finalmente, as
técnicas utilizadas (XAVIER et al., 1995).
Esta ferramenta faz uso destes elementos gráficos padronizados,
buscando uma interface com a qual o usuário se sinta familiarizado.
O projeto de interface será discutido com mais detalhes no capítulo 6
referente a Projeto e Implementação.
30
Capítulo 4 - Análise
O objetivo da Análise Orientada a Objetos é definir as classes, os
relacionamentos e o comportamento associado a elas, que são relevantes ao
problema a ser resolvido no contexto do sistema. Para tal, um número de
tarefas deve ocorrer (FALBO, 2000):
•
Identificação de Classes;
•
Especificação de Hierarquias de Generalização/Especialização;
•
Identificação de Associações e Atributos;
•
Modelagem do Comportamento;
•
Definição das Operações.
Na seção 4.1 tratamos das três primeiras tarefas, descrevendo os
aspectos estáticos do sistema, enquanto na seção 4.2 tratamos das tarefas
restantes, apresentando os modelos comportamentais do sistema, mapenado
aspectos dinâmicos da interação entre os objetos.
4.1
Modelo de Classes
Sendo este trabalho realizado no contexto de um ADS, é necessário
integrar a ferramenta desenvolvida na arquitetura do mesmo.
Tomando por base o modelo de arquitetura conceitual de ODE (ver
Figura 2.1), as ontologias do ambiente e os pacotes responsáveis por oferecer
um suporte à integração das ferramentas de ODE, podemos dividir esta
ferramenta em três sub-sistemas, ou pacotes, como mostra a Figura 4.1.
31
Figura 4.2 - Diagrama de pacotes.
O pacote Controle contém as principais classes responsáveis por
implementar as aplicações no contexto do ambiente (funcionalidades da infraestrutura do ambiente e suas ferramentas). Essas classes são derivadas das
ontologias, mas tipicamente incorporam detalhes não descritos por elas,
necessários para implementar as aplicações do ambiente (FALBO et al.,
2004a).
O pacote Conhecimento abriga as classes que descrevem o
conhecimento em relação a um domínio de aplicação. Suas classes são
derivadas das ontologias e as instâncias dessas classes atuam, tipicamente, no
papel de conhecimento sobre os objetos do Controle (FALBO et al., 2004). O
sub-pacote Conhecimento.Documentacao contém as classes derivadas da
ontologia de documento, cujo modelo foi apresentado no Capítulo 2 (Figura
2.3).
O pacote Documentacao é responsável por abrigar as classes que
representam os artefatos dos tipos documento e diagrama. Esse pacote ainda
abriga as classes relativas à formatação de documentos, que são utilizadas
para criar uma representação para as informações dos artefatos do tipo
documento.
Nas sub-seções seguintes têm-se os modelos de classes de cada um
dos pacotes utilizados neste trabalho.
32
4.1.1
Pacote Controle
Conforme discutido anteriormente, o pacote Controle contém as
principais classes responsáveis por implementar as aplicações no contexto do
ambiente (funcionalidades da infra-estrutura do ambiente e suas ferramentas).
No contexto deste trabalho, foi utilizada apenas a classe Artefato do sub-pacote
ControleProcesso (BERTOLLO, 2006), mostrada na Figura 4.2.
Figura 4.3 - Diagrama de classes parcial do pacote Ode.ControleProcesso
•
Artefatos: São os produtos gerados nas atividades do processo de
software. Podem ser produzidos ou consumidos por uma atividade.
São exemplos de artefatos: documentos de especificação de
requisitos, manuais de qualidade, atas de revisão, diagramas de
classes e código fonte (MIAN et al., 2001). Esta classe é muito
importante para este trabalho, pois todo documento é um artefato
produzido por uma atividade do processo de software.
4.1.2
Pacote Conhecimento
Assim como o pacote Controle é decomposto em vários sub-pacotes, o
pacote Conhecimento também o é. Mais especificamente, cada sub-pacote do
pacote Conhecimento trata de uma ontologia desenvolvida em ODE. Assim, no
contexto
deste
trabalho,
são
importantes
as
classes
dos
pacotes
Conhecimento.Processo e Conhecimento.Documentacao, derivadas a partir
das ontologias de processo e de documento, respectivamente, e parcialmente
mostradas na Figura 4.4.
33
Figura 4.4 - Diagrama de classes do pacote Ode.Conhecimento.Documentacao
As classes KModeloDocumento e KModeloSecao são derivadas
diretamente da ontologia de documentos proposta em (NUNES et al., 2004).
Um modelo de documento é definido como sendo um tipo especial de
roteiro que estabelece a estrutura de um documento e informações para a sua
elaboração. O atributo titulo representa o título do documento final gerado com
base neste modelo de documento. O atributo corpoPreambulo contém o texto
que deverá aparecer entre o título e a primeira seção do documento.
Já um modelo de seção contém a formatação para a elaboração de
seções de documentos aderentes ao respectivo modelo de documento. Como
pode ser visto pelo diagrama da Figura 4.3, um modelo de documento é
composto de modelos de seção, podendo estes serem opcionais ou não. Um
modelo de seção opcional é aquele que não necessita de uma seção
correspondente nos documentos que aplicam o modelo de documento ao qual
pertencem. Um modelo de seção contém ainda o título da seção (atributo titulo)
e um corpo de texto (atributo corpoTexto). Este último contém o texto que
34
preencherá a seção, juntamente com sua formatação. Observe também que
um modelo de seção pode especificar um tipo de artefato (KArtefato) como
corpo. Por fim, modelos de seção podem ser decompostos em outros modelos
de seções.
4.1.3
Pacote Documentacao
Como foi citado, o pacote Documentacao é responsável por abrigar a
classe que representa artefatos do tipo documento, classe Documento na
Figura 4.4. Além disso, esse pacote também contém as classes responsáveis
pela formatação de documentos, de acordo com um modelo de documento: as
classes DocumentoFormatado e Secao.
Assim como um modelo de documento possui modelos de seções e os
modelos de seção, subseções, um documento formatado está associado a
seções (classe Secao), que possui subseções. Cada seção possui
uma
associação com um modelo de seção (KModeloSecao) correspondente. A
Figura 4.3 apresenta o diagrama de classes do pacote Documentacao, sendo
que as classes desse pacote estão destacadas em amarelo.
35
Figura 4.5 - Diagrama de classes do pacote Ode.Documentacao
Observe
no
diagrama
a
associação
corpo
entre
Secao
e
DocumentoFormatado. Como um modelo de seção (KModeloSecao) pode ter
um tipo de artefato (KArtefato) como corpo, a seção correspondente deve
possuir um DocumentoFormatado como corpo. Este deve estar associado a um
modelo de documento (KModeloDocumento) que se aplica ao mesmo tipo de
artefato (KArtefato) do modelo de seção (KModeloSecao). Temos, assim, uma
restrição de integridade.
Diagramas são artefatos que possuem uma representação visual e,
portanto, todo diagrama deve ter de fornecer essa representação por meio do
método obterImagem(), que será utilizado para incluir a imagem do diagrama
no documento formatado. A classe Diagrama foi desenvolvida como parte do
trabalho de (NARDI, 2003).
36
4.2
Modelagem comportamental
Os diagramas de interação são ferramentas que permitem modelar os
aspectos dinâmicos das colaborações entre os objetos. Há dois tipos de
diagramas
de
interação:
Diagramas
de
Seqüência
e
Diagramas
de
Colaborações. Uma vez que ambos representam o mesmo tipo de informação,
optou-se por utilizar neste trabalho apenas diagramas de seqüência.
Segundo (AMBLER, 1998), um diagrama de seqüência mostra os tipos
de objetos envolvidos no cenário de utilização, as mensagens que podem ser
enviadas uns aos outros, como também os valores associados às mensagens.
A apresentação dos diagramas de seqüência mostra com detalhes a
colaboração entre objetos na realização dos casos de uso.
A Figura 4.5 mostra o diagrama de seqüência para o caso de uso
Exportar Documento, apresentado no capítulo 3.
37
Figura 4.6 – Caso de Uso Exportar Documento
38
Capítulo 5 - Projeto
Durante a fase de análise não nos preocupamos com as restrições
tecnológicas. Levamos em consideração apenas os requisitos funcionais que
deveriam ser atendidos. Neste capítulo vamos incorporar as restrições
tecnológicas para modelar a solução que será implementada.
Na seção 5.1 está descrita a plataforma de implementação. Na seção
5.2 está descrita a arquitetura de pacotes, mostrando o acoplamento com os
sistemas já existentes, inclusive com o próprio núcleo de ODE. Nas seções 5.3
e 5.4 está sendo tratado o projeto dos pacotes identificados na fase de análise.
A seção 5.5 discute a implementação. Por fim, na seção 5.6 é abordado o
processo de testes.
5.1
Plataforma de implementação
Como esta ferramenta deverá ser integrada a ODE, vamos nos orientar
na plataforma em que este foi construído, com o intuito de facilitar a integração
e permitir o reúso de componentes. O reúso de componentes de persistência,
visão, negócio, entre outras classes utilitárias, traz algumas vantagens:
•
Redução do tempo de desenvolvimento: como os componentes já
estão implementados, documentados e testados, pode-se focar
no desenvolvimento das funcionalidades específicas do projeto.
•
Facilidade de manutenção: uma vez que os componentes
reutilizados são de conhecimento de todo o projeto ODE e já
estão bem testados, diminui-se também o tempo despendido em
depurações.
Sendo assim, como ODE, esta ferramenta foi implementada utilizando
Java como linguagem de programação (na versão 5.0) e para persistência de
dados Hibernate 3.1 (HIBERNATE, 2007) e PostgreSQL 8.2 como Sistema
Gerenciador de Banco de Dados (SGBD).
39
Para a geração dos documentos, os frameworks Jelly (APACHE, 2007a)
e AurigaDoc (SOURCEFORGE, 2007a) foram utilizados.
5.2
Arquitetura
Com o intuito de facilitar a manutenção e evolução do ambiente e
permitir produção de componentes para reúso, a maior parte das ferramentas
de ODE, incluindo a apresentada neste trabalho, é organizada em uma
arquitetura em camadas, composta de cinco componentes principais, cada um
deles responsável por tratar de uma parte do sistema, a saber:
•
Componente de Domínio do Problema (cdp): contém as classes
que identificam os conceitos do domínio do negócio. Essas classes
são tipicamente identificadas na fase de análise.
•
Componente de Gerência de Tarefas (cgt): é responsável pelo
controle e execução das funcionalidades das ferramentas. Suas
classes implementam os casos de uso e junto com o cdp forma a
camada de negócio.
•
Componente de Interface Humana (cih): contém as classes que
representam os elementos de interação de entrada e saída de dados
com o meio externo. É representado por janelas, botões, desenhos
entre outros. Uma atenção especial deve ser dada a essa
componente, pois é por meio dele que o usuário final interage com o
ambiente.
•
Componente de Controle de Interação (cci): Faz a intermediação
entre a comunicação do cih e o cgt, permitindo uma menor
dependência do cgt em relação ao cih.
•
Componente de Gerência de Dados (cgd): Contém as classes
responsáveis por encapsular o mecanismo de persistência de
objetos.
A dependência entre os componentes é apresentada na Figura 5.1.
40
Figura 5.1 - Arquitetura em camadas.
O modelo de arquitetura de ODE é semelhante ao modelo MVC (Model
– View – Controller) (SUN, 2007a). As principais diferenças são:
•
Componente Model do MVC encapsula os pacotes cgt e cdp do
modelo de arquitetura de ODE.
•
O MVC não descreve a interação com a camada de persistência.
•
MVC permite que a camada Model se comunique com a View
através de eventos, notificando-a de alterações que ocorrem no
modelo, enquanto que o modelo de arquitetura de ODE não
admite essa comunicação.
A Figura 5.2 compara os dois modelos.
Figura 5.2 – Comparação entre modelo MVC e o modelo adotado no Ode.
41
Outro detalhe arquitetural importante é mostrar de quais componentes
de ODE este trabalho depende e possíveis impactos que este trabalho possa
causar no ambiente. Essas dependências são mostradas na Figura 5.3.
Figura 5.3 - Dependência de pacotes de todo o sistema.
Como pode ser visto pelo diagrama de pacotes da Figura 5.3, este
trabalho depende dos componentes Controle, Conhecimento e Utilitario de
ODE. No momento, não há dependências de pacotes do ambiente para os
pacotes propostos neste trabalho, porém outras ferramentas poderão ter uma
dependência se desejarem utilizar os recursos que eles oferecem.
Além da dependencia de pacotes do próprio ambiente em que está
inserido, este trabalho também tem dependências externas com os framework
Jelly e AurigaDoc, como já foi citado no início deste capítulo.
42
O Jelly é um framework que implementa uma linguagem de script
baseada em XML, muito semelhante a JSTL (SUN, 2007c). A função dele é
combinar o modelo de documento com o documento, através das marcações
que serão inseridas. A linguagem de script de Jelly será responsável por fazer
as substituições.
Já o AurigaDoc é utilizado para fazer a geração do documento em
diversos formatos, como HTML e PDF. Ele recebe um documento XML de
entrada e é capaz de convertê-lo para o formato de saída solicitado.
5.3
Pacote Conhecimento.documentacao
Como já citado no capítulo 4, este pacote descreve o conhecimento em
relação ao domínio de documentação, ou seja, as classes derivadas da
ontologia de documentos (Figura 2.3). A seguir cada um dos cinco
componentes da arquitetura é descrito para esse pacote.
5.3.1
Pacote cdp
A Figura 5.4 apresenta o Diagrama de Classe referente ao Componente
do Domínio do Problema do pacote Conhecimento.documentacao.
43
Figura 5.4 - Pacote Conhecimento.documentacao.cdp
Em
relação
ao
modelo
de
análise,
este
modelo
contém
as
navegabilidades e os tipos de dados, importantes no modelo de projeto. Outras
modificações foram feitas, a saber:
•
Adição do atributo ordem à classe KModeloSecao, garantindo que
a ordem seja mantida após a recuperação a partir do SGBD. Esse
atributo foi adicionado para implementar a restrição ordenado que
havia no modelo de análise.
•
Herança da classe ObjetoPersistente, feita para auxiliar a
persistência. Essa superclasse adiciona os atributos id e version,
responsáveis por manter a identidade do objeto e o controle de
modificações concorrentes, respectivamente.
•
Alteração
da
multiplicidade
entre
KModeloSecao
e
KModeloDocumento. Na fase de projeto, é permitido que um
KModeloSecao não possua um KModeloDocumento associado,
quando for subseção de um outro KModeloSecao. Assim,
somente os KModeloSecao que não possuem seção pai estão
associados a um KModeloDocumento.
44
5.3.2
Pacote cgd
A Figura 5.5 apresenta o modelo de classes referente ao Componente
de Gerência de Dados ao pacote Conhecimento.documentacao. Ele foi definido
utilizando-se o padrão de projeto DAO (SUN, 2007b).
Figura 5.5 - Pacote Conhecimento.documentacao.cgd
A herança da classe Hib3DAO não é opcional. Essa classe é
responsável por disponibilizar o objeto Session, responsável por realizar as
operações de persistência do Hibernate. Essa classe também disponibiliza
alguns métodos auxiliares para facilitar a implementação das classes DAO,
como salvar, excluir, obterPorId e obterTodos.
5.3.3
Pacote cgt
A Figura 5.6 mostra o diagrama de classes do Componente de Gerência
de Tarefas. Esse componente é responsável por implementar os casos de uso
do sistema. A classe AplEditarModeloDocumento implementa o caso de uso
Editar
Modelo
de
Documento
e,
portanto,
possui
os
métodos
criarModeloDocumento, alterarModeloDocumento e excluirModeloDocumento
que estão diretamente ligados aos cenários desse caso de uso, conforme
45
discutido na seção 3.1. O método buscarModeloDocumento é auxiliar, utilizado
pela cci para obter uma lista de todos os modelos de documentos, de forma
que o usuário possa selecionar o que ele deseja alterar ou excluir, no
componente de visão. O método verificarPossibilidadeExclusaoModeloSecao é
somente
uma
ponte
para
o
método
de
igual
nome
na
classe
AplEditarModeloSecao. Seu acesso precisa ser exposto para ser acessado
pelo controlador, conforme discutido na seção 5.3.5.
Figura 5.6 - Pacote Ode.Conhecimento.Documentacao.Cgt
O
método
excluirModeloDocumento
pode
disparar
a
exceção
ModeloDocumentoEmUsoException, referente ao curso alternativo do cenário
Excluir Modelo de Documento do caso de uso Editar Modelo de Documento.
A classe AplEditarModeloSecao implementa o caso de uso Editar
Modelo de Seção e, portanto, possui os métodos criarModeloSecao,
alterarModeloSecao e excluirModeloSecao que estão diretamente ligados aos
cenários desse caso de uso, conforme discutido na seção 3.1. O método
verificarPossibilidadeExclusaoModeloSecao existe para verificar se é possível
excluir um objeto KModeloSecao. De acordo com a especificação de requisitos,
um modelo de seção pode ser excluído somente se não existe nenhuma seção
associada a ele.
Observando o diagrama de casos de uso da Figura 3.1, vemos uma
extensão entre os casos de uso Editar Modelo de Seção e Editar Modelo de
Documento. No projeto do cgt, essa extensão foi traduzida em uma associação
entre as classes AplEditarModeloDocumento e AplEditarModeloSecao, que
representam esses casos de uso.
46
5.3.4
Pacote cih
O
Componente
de
Interação
Humana
(cih)
do
pacote
Conhecimento.documentacao é responsável por estabelecer uma comunicação
entre o usuário e a máquina, na realização dos casos de uso.
Figura 5.7 - Diagrama de classes do pacote ode.conhecimento.documentacao.cih
Como pode ser observado pela Figura 5.7, o pacote cih possui duas
janelas: uma janela de cadastro, classe JanCadastroModeloDocumento, que é
responsável
por
apresentar
uma
lista
dos
modelos
de
documento
(KModeloDocumento) disponíveis e uma janela onde os dados são
apresentados e editados, classe JanDadosModeloDocumento. Ainda pelo
diagrama pode ser visto o reúso de um componente de interface de ODE, o
PainelCadastroTabela, que auxilia o usuário na seleção dos modelos de
documento.
A Figura 5.8 mostra o layout da janela JanCadastroModeloDocumento,
enquanto que as Figuras 5.9 e 5.10 apresentam o layout da janela
JanDadosModeloDocumento.
47
Figura 5.8 - Janela de seleção dos modelos de documentos
Figura 5.9 - Janela de edição dos dados do modelo de documento
48
Figura 5.10 - Janela de edição dos dados do modelo de seção
5.3.5
Pacote cci
O Componente de Controle de Interação (cci) tem como objetivo tratar a
comunicação de dados entre as interfaces da ferramenta (cih) e as classes de
aplicação (cgt), como mostra a Figura 5.11.
49
Figura 5.11 - Diagrama de classes do pacote ode.conhecimento.documentacao.cci
A
navegabilidade
no
CtrlConhecimentoDocumentacao
sentido
para
da
a
classe
classe
controladora
de
aplicação
AplEditarModeloDocumento permite que as funcionalidades da ferramenta
também possam ser usadas por outras ferramentas do ambiente ODE e
também permite que a ferramenta possua mais de um tipo de interface
diferente, como swing e web.
O controlador conhece todas as operações necessárias para atender às
requisições das interfaces. Quando uma interface necessita de alguma
funcionalidade da classe de aplicação, o controlador faz uma requisição à
aplicação. Em seguida, esta retorna um resultado para o controlador que o
interpreta e atualiza as interfaces, caso haja necessidade.
Apesar dos métodos não estarem explícitos no diagrama da Figura 5.11,
o controlador possui vários métodos, cujas principais funcionalidades são de
atualização das interfaces e de requisições às aplicações.
50
5.4
Pacote Ode.documentacao
Este pacote abriga a classe que representa artefatos do tipo documento,
além das classes responsáveis pela formatação de documentos. A seguir cada
um dos cinco componentes da arquitetura é descrito para esse pacote.
5.4.1
Pacote cdp
A Figura 5.12 apresenta o diagrama de classe referente ao Componente
do Domínio do Problema do pacote documentacao.
Figura 5.12 - Pacote documentacao.cdp
Em
relação
ao
modelo
de
análise,
este
modelo
contém
as
navegabilidades e os tipos de dados, importantes no modelo de projeto. Outras
modificações foram feitas, a saber:
•
Herança da classe ObjetoPersistente, feita para auxiliar a
persistência. Essa superclasse adiciona os atributos id e version,
responsáveis por manter a identidade do objeto e o controle de
modificações concorrentes, respectivamente.
51
•
Classe Secao não possui mais a associação subsecao. A
navegação através das seções, pela ordem e pela hierarquia
deve ser feita através do modelo de seção (KModeloSecao)
correspondente. Essa escolha permite que os modelos de seção
(KModeloSecao) sejam reordenados ou tenham sua hierarquia
alterada, sem a necessidade de se preocupar em reordenar as
seções dos documentos (classe Secao).
5.4.2
Pacote cgd
A Figura 5.13 apresenta o modelo de classes referente ao Componente
de Gerência de Dados ao pacote documentacao. Ele foi definido utilizando-se o
padrão de projeto DAO (SUN, 2007b) e as considerações feitas para o pacote
Conhecimento.documentacao.cgd aplicam-se aqui também.
Figura 5.13 - Pacote documentacao.cgd
5.4.3
Pacote cgt
A Figura 5.14 mostra o digrama de classes do Componente de Gerência
de Tarefas. Esse componente é responsável por implementar os casos de uso
relativos à formatação e geração de documentos. Assim, as classes
AplEditarDocumentoFormatado,
AplEditarSecao
e
52
AplGerarDocumentoFormatado correspondem aos casos de uso Editar
Documento Formatado, Editar Seção e Gerar Documento Formatado,
respectivamente.
Os
alterarDocumentoFormatado,
métodos
criarDocumentoFormatado,
excluirDocumentosFormatado,
criarSecao,
alterarSecao, excluirSecao e gerarDocumento correspondem à implementação
dos cenários dos seus respectivos casos de uso. Os demais métodos são
auxiliares e análogos aos descritos no pacote Conhecimento.documentacao.
Figura 5.14 - Pacote documentacao.cgt
O método excluirDocumentoFormatado pode disparar a exceção
DocumentoFormatadoEmUsoException,
caso
o
documento
formatado
(DocumentoFormatado) seja corpo de uma seção.
Observando o diagrama de casos de uso da Figura 3.1, vemos uma
extensão entre os casos de uso Editar Seção e Editar Documento Formatado.
No projeto do cgt, essa extensão foi traduzida em uma associação entre as
classes AplEditarDocumentoFormatado e AplEditarSecao, que representam
esses casos de uso.
5.4.4
Pacote cih
O Componente de Interação Humana (cih) é responsável por
estabelecer uma comunicação entre o usuário e a máquina, na realização dos
casos de uso.
53
Figura 5.15 - Diagrama de classes do pacote documentacao.cih
Como pode ser observado pela Figura 5.15, o pacote cih possui duas
janelas: uma janela de cadastro, classe JanCadastroDocumentoFormatado,
que é responsável por apresentar uma lista dos documentos formatados
(DocumentoFormatado) disponíveis e uma janela onde os dados de um
documento formatado selecionado são apresentados e editados, classe
JanDadosDocumentoFormatado.
A
Figura
5.16
JanDadosDocumentoFormatado.
mostra
A
o
layout
janela
da
de
janela
cadastro
(JanCadastroDocumentoFormatado) possui layout análogo ao da janela da
Figura 5.8.
54
Figura 5.16 - Janela de edição dos dados do documento formatado e das seções
5.4.5
Pacote cci
O Componente de Controle de Interação (cci) tem como objetivo tratar a
comunicação de dados entre as interfaces da ferramenta (cih) e as classes de
aplicação (cgt), como mostra a Figura 5.17.
55
Figura 5.17 - Diagrama de classes do pacote ode.conhecimento.documentacao.cci
Analogamente
navegabilidade
ao
no
pacote
sentido
CtrlEditarDocumentoFormatado
para
Conhecimento.documentacao.cci,
da
as
classe
classes
a
controladora
de
aplicação
AplEditarDocumentoFormatado e AplGerarDocumentoFormato permite que as
funcionalidades da ferramenta possam ser usadas por outras ferramentas do
ambiente ODE. Além disso, também permite que a ferramenta possua mais de
um tipo de interface diferente, como swing e web.
Apesar dos métodos não estarem explícitos no diagrama da Figura 5.17,
o controlador possui vários métodos, cujas principais funcionalidades são de
atualização das interfaces e de requisições às aplicações.
56
5.5
Implementação
A fase de implementação ocorre no instante em que as classes
necessitam ser programadas, tomando-se por base o modelo de projeto. O
sistema é concebido através da implementação, produzindo-se os arquivos de
código fonte que resultarão em um sistema executável. Se o projeto foi
elaborado corretamente e com detalhes suficientes, a tarefa de codificação é
facilitada (RATTES, 2001).
Poucos diagramas adicionais são criados na fase de implementação. Na
verdade, os diagramas criados na fase de projeto são detalhados ou corrigidos
quando necessário (FURLAN, 1998).
Como já havia uma experiência nas ferramentas utilizadas para
construção deste trabalho e as decisões de projeto eram, sempre que possível,
prototipadas,
nenhuma
modificação
do
modelo
de
projeto
para
a
implementação foi feita.
O caso de uso mais complexo de ser implementado foi o Gerar
Documento Formatado, pois envolve a geração de documentos em formatos
diferentes e requer a navegação ao longo dos modelos das subclasses de
Documento. Os demais casos de uso são apenas cadastros. Assim, na seção
5.5.1 detalha-se como foi realizada a implementação desse caso de uso.
5.5.1
Gerar Documento Formatado
A implementação deste caso de uso consiste em transformar o modelo
de documento, juntamente com os modelos de seção e as marcações nos
corpos texto, preâmbulo e títulos, em um arquivo de documento em múltiplos
formatos, utilizando as informações de um objeto da classe Documento.
A dificuldade para implementar uma substituição de texto para as
marcações existe porque que não conhecemos nada sobre as subclasses de
Documento, que é utilizada para realizar a documentação. Assim, para
combinar as informações de um objeto da classe Documento com os textos
marcados, foi necessário utilizar uma linguagem de script que fosse capaz de
processar as marcações no texto que referenciavam os elementos do
57
documento de uma forma dinâmica. O Jelly é o executor de script responsável
por transformar as marcações no corpo de texto do modelo de seção, título do
modelo de seção, corpo preâmbulo e título do modelo de documento na
informação supostamente desejada no objeto a ser documentado da classe
Documento.
O principal motivo para escolha do Jelly como framework para executar
o script é porque ele pode ser facilmente extensível e sua linguagem é baseada
em marcações XML, o que facilita a analise e a edição dos textos que serão
processados.
Contudo a solução oferecida pelo Jelly para realizar a substituição das
marcações ainda é muito simples para atender aos requisitos deste trabalho.
Assim, foi necessário estender sua funcionalidade implementando o que o
framework chama de taglibs, que nada mais é que uma tag XML (a
especificação de XML chama de Element (W3C, 2007a)), cujo conteúdo será
processado por uma classe Java. A implementação da taglib consiste em ser
capaz de realizar uma substituição simples, como o nome do projeto, ou de
repetir uma seção ou lista, caso os elementos da marcação contenham listas.
Para facilitar a compreensão, imagine que o gerente de documentação
deseja imprimir uma subseção para cada equipe do projeto. Neste caso, o título
deverá conter o texto abaixo:
Equipe <o:doc>projeto.equipes.tipo<o:doc>
O conteúdo projeto.equipes é uma lista e indica que esta seção deverá
ser repetida para cada elemento da lista de equipes do projeto. Assim, serão
geradas tantas seções quanto forem as equipes do projeto. Cada referência
projeto.equipes.tipo está associada ao tipo de uma equipe específica no título
do modelo de seção. A mesma regra vale para listas, numeradas ou não.
Caso a referência seja de um objeto da classe Diagrama, o desenho
correspondente (DDiagrama) será chamado para renderizar a imagem.
Após substituir todas as marcações do texto, um arquivo XML é gerado
em um formato muito parecido com o XHTML (W3C, 2007b). Porém, ainda é
necessário gerar o arquivo de saída no formato selecionado pelo ator
desenvolvedor. Para isto o framework AurigaDoc foi utilizado. Basta gerar o
documento em um formato XML especificado por esse framework, que ele é
58
capaz de gerar os documentos nos mais diversos formatos, sendo possível
adicionar um novo formato caso seja necessário.
O arquivo gerado após o processamento do Jelly ainda não esta no
formato requerido pelo AurigaDoc. Para gerar o formato requerido, uma folha
de estilos (W3C, 2007c) é aplicada no XML de saída para convertê-lo. A partir
daí, o processo fica por conta do framework AurigaDoc que se encarrega de
gerar o arquivo final nos formatos de saída desejados.
Para realizar essa tarefa, o AurigaDoc possui um driver para cada
formato de saída suportado. A maioria dos drivers consiste de uma folha de
estilo que converte o formato do AurigaDoc no formato desejado, como a
geração para HTML ou DHTML. A geração para os formatos RTF e PDF é
mais complexa, pois esses formatos não são XML. Neste caso o documento
enviado para o AurigaDoc é convertido para o formato XSL-FO (W3C, 2007c) e
convertido para PDF ou RTF através do Apache FOP (APACHE, 2007b).
5.6
Testes
O teste do software é um processo realizado pelo testador de software
que permeia outros processos da Engenharia de Software e envolve ações que
vão do levantamento de requisitos até a execução do teste propriamente dito.
O objetivo é encontrar defeitos nos produtos, para que estes possam ser
corrigidos pela equipe de programadores.
No
contexto
deste
trabalho,
além
dos
testes
realizados
pelo
desenvolvedor, testes automatizados foram criados.
A vantagem de se criar testes automatizados é poder sempre garantir
que um caso de uso estará sempre atendendo aos requisitos para o qual foi
projetado, embora não assegure que a equipe de desenvolvimento tenha
entendido corretamente o requisito. Assim, quando uma manutenção é feita no
sistema, basta executar o caso de teste para assegurar que as outras
funcionalidades continuam funcionando.
Já após o levantamento dos requisitos, ficam claros os casos de testes
abaixo:
59
•
Testar a criação de um modelo de documento e seus modelos de
seção;
•
Testar a alteração de um modelo de documento e seus modelos de
seção;
•
Testar a pesquisa de modelos de documentos criados;
•
Testar a exclusão de um modelo de documento e seus modelos de
seção;
•
Testar a exclusão de um modelo de documento que está em uso por
um documento;
•
Testar a criação de um documento formatado;
•
Testar a alteração de um documento formatado;
•
Testar a pesquisa de documentos formatados criados;
•
Testar a exclusão de um documento formatado;
•
Testar a exclusão de uma seção associada a modelo de seção
obrigatório ou não;
•
Gerar documento formatado;
Para facilitar a automatização dos testes foi utilizado um framework de
testes unitários conhecido como JUnit (SOURCEFORGE, 2007b), na versão
3.8. O critério de escolha foi baseado na experiência anterior com esse
framework, facilitadade de integração dele com a IDE utilizada para o
desenvolvimento da ferramenta de documentação e no tamanho da
comunidade que já utilizou o framework.
A desvantagem de utilizar o JUnit neste contexto é que alguns testes
não são necessáriamente unitários, pois envolvem persistencia de dados ou
dependem de insumos produzidos por outras ferramentas. Observe o exemplo
dos testes de geração do documento formatado. É necessário ter instâncias
das classes Documento e DocumentoFormatado no sistema de persistencia,
ou escrever um código para gerá-las, dentro do caso de testes, o que pode ser
bastante complexo dependendo o modelo. Neste caso optou-se por assumir
que a base estivesse populada com alguns objetos que seriam pesquisados e
utilizados para a execução do caso de testes.
Com o uso do JUnit já no início da fase de implementação, foi possível
testar rapidamente tudo o que era produzido, sem a necessidade de aguardar
60
pela criação da interface gráfica com o usuário, permitindo ao desenvolvimento
caminhar de forma independente da confecção das interfaces. Isto é muito útil
em organizações onde as equipes de implementação e a equipe de design são
diferentes.
61
Capítulo 6 - Conclusões e Perspectivas Futuras
Neste capítulo são apresentadas as considerações finais deste trabalho.
Na seção 6.1 são apresentadas as conclusões e na seção 6.2 as perspectivas
para trabalhos futuros.
6.1
Conclusões
Mesmo que não seja negligenciada a atividade de documentação de
software, a manutenção, muitas vezes, é, tornando a documentação existente
desatualizada, podendo, assim, atrapalhar mais do que ajudar na identificação
dos requisitos e entendimento do sistema.
Com este trabalho espera-se auxiliar o processo de geração de
documentos
nos
projetos
acompanhados
através
do
ADS
ODE.
A
documentação gerada a partir de modelos de documentos é automaticamente
atualizada quando qualquer um dos objetos é modificado, reduzindo o esforço
necessário de atualização e também permitindo maior integração entre as
ferramentas de ODE, uma vez que a geração da documentação passa a ser
um processo único em ODE.
Além de complementar o ADS ODE, o desenvolvimento deste trabalho
permitiu consolidar os conhecimentos adquiridos durante o curso de Ciência da
Computação da Universidade Federal do Espírito Santo, principalmente na
área de engenharia de software.
6.2
Perspectivas futuras
Mesmo atingindo o objetivo proposto, sempre é possível melhorar.
Abaixo temos uma lista de melhorias que podem ser feitas para auxiliar ainda
mais a geração de documentos em ODE:
• Este trabalho fornece a base para a criação de artefatos internos
do tipo documentos no ambiente ODE. Porém, para permitir uma
melhor utilização dele no ambiente como um todo, é importante
62
que o máximo de ferramentas sejam capazes de produzir
artefatos, como sub-classes da classe Documento.
• Facilitar a criação do modelo de documento também é uma
importante melhoria para este trabalho. Atualmente ele está
diretamente ligado ao modelo de projeto de ODE, ou seja, é
necessário que o gerente de documentação tenha uma visão da
modelagem de dados interna de ODE. Juntamente a este item,
pode-se acrescentar uma melhora na interface, para torná-la mais
intuitiva.
• A geração de elementos mais complexos também é importante.
Gerar uma tabela, por exemplo, com valores obtidos dos
documentos não é uma tarefa fácil de ser feita no estágio atual da
ferramenta.
63
REFERÊNCIAS BIBLIOGRÁFICAS
(AMBLER, 1998)
AMBLER, Scott. Análise e Projeto Orientados a
Objetos – Vol. 2. Rio de Janeiro: Infobook, 1998.
(AMBLER, 2004)
AMBLER, Scott W. Agile Documentation. 20012004, The Official Agile Modeling (AM) Site, 2001,
Disponível
em
:
<http://www.agilemodeling.com/essays/
agileDocumentation.htm>, Acesso em: 02 abr.
2001.
(APACHE, 2007a)
Apache
Software
Executable
Foundation
XML.
(Org.).
Disponível
Jelly:
em:
<http://commons.apache.org/jelly/>. Acesso em: 24
set. 2007.
(APACHE, 2007b)
Apache Software Foundation (Org.). Apache FOP.
Disponível
em:
<http://xmlgraphics.apache.org/fop/>. Acesso em:
24 set. 2007.
(BERTOLLO, 2006)
BERTOLLO, G., “Definição de Processos em um
Ambiente
de
Desenvolvimento
de
Software”.
Dissertação de Mestrado, Mestrado em Informática,
UFES, Vitória, Junho 2006.
(FALBO, 2000)
Projeto de Sistemas - Notas de Aula, Departamento
de Informática, UFES, 2000.
64
(FALBO et al., 2002)
FALBO, R.A.; GUIZZARDI, G.; DUARTE, K.C.; “An
Ontological Approach do Domain Engineering”.
Proceedings of the 14th International Conference
on
Software
Engineering
and
Knownledge
Engineering, SEKE’2002, pp.351-358, Ischia, Italy,
2002.
(FALBO et al., 2003)
FALBO, R. A., NATALI, A. C. C., MIAN, P. G.,
BERTOLO, G., RUY, F. B., “ODE: Ontology-based
software Development Environment”. IX Congreso
Argentino de Ciencias de la Computación, p. 11241135. La Plata, Argentina, Outubro de 2003.
(FALBO et al., 2004)
FALBO, R.A., RUY, F.B., PEZZIN, J., DAL MORO,
R., “Ontologias e Ambientes de Desenvolvimento
de Software Semânticos”. 4th Ibero-American
Symposium
on
Software
Engineering
and
Knowledge Engineering, JIISIC’2004, Vol. I, 277292, Madrid, Spain, November 2004.
(FORWARD, 2002)
FORWARD, Andrew. Software Documentation –
Building and Maintaining Artefacts of Comunication,
2002. Teste de Mestrado, Universidade de Ottawa,
Ottawa, Toronto, Canadá.
(FURLAN, 1998)
FURLAN, José Davi. Modelagem de Objetos
através da UML. São Paulo: Makron Books, 1998.
(ISO, 1999)
ISO/IEC 9126-1, Information technology – software
product quality – Part 1: quality model, 1999.
(HIBERNATE, 2007)
HIBERNATE (Org.). Hibernate. Disponível em:
<http://www.hibernate.org>. Acesso em: 18 jun.
2007.
65
(MIAN et al., 2001)
MIAN, P. G.; NATALI, A. C. C.; FALBO, R. A..
Ambientes de Desenvolvimento de Software e o
Projeto
ADS.
Revista
Engenharia
Ciência
Tecnologia, Vitória, ES, v. 04, n. 04, p. 3-10, 2001.
(NARDI, 2003)
NARDI, J.C., “Modelagem de Estados em OODE
Segundo o Meta-Modelo da UML”. Projeto de
Graduação, Curso de Ciência da Computação,
UFES, Novembro 2003.
(NUNES et al., 2004)
NUNES, V.B.; SOARES, A.O.; FALBO, R.A. “Apoio
à
Documentação
em
um
ambiente
de
desenvolvimento de Software”, Memorias de VII
Workshop
Iberoamericano
de
Ingeniería
de
Requisitos y Desarrollo de Ambientes de Software IDEAS'2004, pp. 50-55, Arequipa, Peru, 2004.
(NUNES, 2005)
NUNES,
B.V.,
Configuração
de
“Integrando
Software,
Gerência
de
Documentação
e
Gerência de Conhecimento em um Ambiente de
Desenvolvimento de Software”. Dissertação de
Mestrado, UFES, Vitória, Brasil, 2005.
(PRESSMAN, 2002)
PRESSMAN, Roger S. Engenharia de Software. 5º
edição. Rio de Janeiro: McGrawHill, 2002.
(RATTES, 2001)
RATTES,
Pablo
Damasceno.
CASE
para
Tecnologia de Objetos: Suporte à Modelagem de
Classes e Estados, Projeto de Graduação, Curso
de Ciência da Computação. Espírito Santo: UFES,
Abril 2001.
(RUY, 2006)
RUY, F.B., “Semântica em um Ambiente de
Desenvolvimento de Software”. Dissertação de
Mestrado, Mestrado em Informática, UFES, Vitória,
Junho 2006.
66
(SEI, 2007)
SOFTWARE ENGINEERING INSTITUTE (Org.).
What is a CASE Environment? Disponível em:
<http://www.sei.cmu.edu/legacy/case/case_whatis.
html>. Acesso em: 04 fev. 2007.
(SILVA, 2004)
SILVA, P.B., “Adequação da Ferramenta de
Documentação de ODE a uma Ontologia de
Artefato”. Projeto de Graduação, Curso de Ciência
da Computação, UFES, Dezembro 2004.
(SOARES, 2002)
SOARES,
A.O.,
“Ferramenta
de
Apoio
à
Documentação”. Projeto de Graduação, Curso
Ciência da Computação, UFES.
(SOURCEFORGE, 2007a) SOURCEFORGE.NET
(Org.).
AurigaDoc.
Disponível em: <http://aurigadoc.sourceforge.net/>.
Acesso em: 24 set. 2007.
(SOURCEFORGE, 2007b) SOURCEFORGE.NET (Org.). JUnit. Disponível em:
<http://junit.sourceforge.net/>. Acesso em: 24 set.
2007.
(SUN, 2007a)
SUN
MICROSYSTEMS
Controller.
J2EE
(Inc.).
Patterns.
Model-View-
Disponível
em:
<http://java.sun.com/blueprints/patterns/MVCdetailed.html>. Acesso em: 07 maio 2007.
(SUN, 2007b)
SUN MICROSYSTEMS (Org.). Data Access Object.
Disponível
em:
<http://java.sun.com/blueprints/corej2eepatterns/Pa
tterns/DataAccessObject.html>. Acesso em: 07
maio 2007.
(SUN, 2007c)
SUN MICROSYSTEMS (Org.). JavaServer Pages
Standard
Tag
Library.
Disponível
em:
<
http://java.sun.com/products/jsp/jstl/>. Acesso em:
01 outubro 2007.
67
(THOMAS et al., 1992)
THOMAS I., NEJMEH, B.A. “Definitions of Tool
Integration for Environments”, IEEE Software, 2935, March 1992.
(W3C, 2007a)
W3C.ORG (Org.). Extensible Markup Language
(XML) 1.0 (Fourth Edition). Disponível em: <
http://www.w3.org/TR/REC-xml/>. Acesso em: 24
set. 2007.
(W3C, 2007b)
W3C.ORG (Org.). XHTML™ 1.0 The Extensible
HyperText Markup Language (Second Edition).
Disponível em: < http://www.w3.org/TR/xhtml1/>.
Acesso em: 24 set. 2007.
(W3C, 2007c)
W3C.ORG (Org.). Extensible Stylesheet Language
(XSL)
Version
1.1.
Disponível
em:
<
http://www.w3.org/TR/xsl11>. Acesso em: 24 set.
2007.
(XAVIER, 1995)
XAVIER, Carlos Magno da S., Portilho., C.
Projetando com Qualidade a Tecnologia em
Sistemas de Informação. LTC Editora, 1995;
68