universidade federal fluminense agnaldo … · jvm – java virtual machine gnu – gnu is not unix...
TRANSCRIPT
UNIVERSIDADE FEDERAL FLUMINENSEAGNALDO OLIVEIRA MOURA
ESTUDO SOBRE A DOCUMENTAÇÃO DE SOFTWARE
Niterói2008
AGNALDO OLIVEIRA MOURA
ESTUDO SOBRE A DOCUMENTAÇÃO DE SOFTWARE
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Tecnólogo em Sis-
temas de Computação.
Orientador:Cristiano Grijó Pitangui
Niterói2008
AGNALDO OLIVEIRA MOURA
ESTUDO SOBRE A DOCUMENTAÇÃO DE SOFTWARE
O SOFTWARE SOB A LUZ DA DOCUMENTAÇÃO TÉCNICA
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Tecnólogo em Sis-
temas de Computação.
Niterói, ___ de _______________ de 2008.
Banca Examinadora:
_________________________________________
Prof. Cristiano Grijó Pitangui, Msc. – Tutor Orientador
UFRJ – Universidade Federal do Rio de Janeiro
_________________________________________
Prof. Leandro Soares de Sousa, Msc. – Avaliador
UFF - Universidade Federal Fluminense
Dedico este trabalho a minha esposa Deise
e aos meus filhos Agnaldo Junior e Daniel.
Que com amor, dedicação e, sobretudo
compreensão, me proporcionaram a paz e
serenidade para cumprir mais essa missão.
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-
nhada.
A meu Orientador Cristiano Grijó Pitangui
pelo estímulo e atenção que me concedeu
durante o curso.
A todos os meus familiares e amigos pelo
apoio e colaboração direta ou indireta que ti-
veram durante toda esta jornada.
“Para alcançar o conhecimento, acrescente
coisas todos os dias. Para alcançar a sabe-
doria, remova coisas todos os dias”.
Lao Tse
RESUMO
Este trabalho visa demonstrar a importância da documentação de softwa-re. Assim, discutem-se a documentação de uso e a documentação técnica, sendo esta última o foco principal do trabalho.
O trabalho mostra diversas possibilidades e técnicas que podem e devem ser utilizadas durante o processo de documentação, e foca na apresentação e dis-cussão de ferramentas livres que podem ser utilizadas durante este processo.
A documentação é uma importante ferramenta para tornar o novo softwa-re mais simples de ser desenvolvido e mais fácil de ser mantido, o que certamente irá economizar horas de manutenção em eventuais problemas ou upgrades.
O presente trabalho se propõe a responder algumas perguntas do tipo: O que significa documentar um software e qual é o resultado final de uma documenta-ção? Quais as vantagens de se documentar um software e quais as desvantagens de um software não documentado ou mal documentado? Como prever os custos da documentação no projeto e também os ganhos em horas de manutenção?
O trabalho tem ainda como objetivo, auxiliar o desenvolvedor na tarefa de diferenciar os diversos tipos e métodos de documentação e quais ferramentas utili -zar para cada um deles de modo eficaz e produtivo. Adicionalmente, apresentam-se boas práticas de programação e dicas/técnicas para tornar as documentações mais objetivas, completas e ágeis.
Palavras-chaves: documentação, software e técnicas.
LISTA DE ILUSTRAÇÕES
Figura 1.1: Evolução do Software [2]..........................................................................13
Figura 2.2: Framework fornecido pela norma ISO 12207 [4]......................................20
Figura 2.3: Creativity in Engineering (Paper Submission Guidelines – www.phdco-
mics.com) [12].............................................................................................................22
Figura 2.4: Diretrizes básicas no projeto de Software [10].........................................23
Figura 3.5: Manual do usuário em papel e CD/DVD...................................................26
Figura 3.6: Manual de acesso rápido..........................................................................27
Figura 3.7: Dispositivo de ajuda..................................................................................28
Figura 3.8: Help on-line...............................................................................................28
Figura 3.9: Atribuições do Arquiteto de Software. Rational Software Corporation [47].
.....................................................................................................................................30
Figura 3.10: Exemplo casos de uso [11].....................................................................31
Figura 3.11: Visão lógica da documentação de arquitetura [11]................................31
Figura 3.12: Visão de processo da documentação de arquitetura [11]......................32
Figura 3.13: Visão de Implantação da documentação de arquitetura [11].................32
Figura 3.14: Modelo Entidade Relacionamento..........................................................33
Figura 3.15: Modelo lógico baseado em registros [14]...............................................34
Figura 3.16: Modelo lógico convertido para SQL [14].................................................34
Figura 3.17: Exemplo de dicionário de dados.............................................................36
Figura 3.18: Tipos de fluxograma [29]........................................................................37
Figura 3.19: Código fonte documentado [18]..............................................................38
Figura 3.20: Pseudocódigo em português..................................................................39
Figura 4.21: Software de Modelagem dia [17]............................................................51
Figura 4.22: Software de modelagem ARGO [17]......................................................52
Figura 4.23: Software de modelagem Umbrello [17]..................................................53
LISTA DE TABELAS
Tabela 3.1: Notação típica do dicionário de dados.....................................................35
Tabela 3.2. Modelo de dicionário de dados em tabela [18]........................................36
LISTA DE GRÁFICOS
Gráfico 2.1: Parte da manutenção no custo total de um software...........................22
LISTA DE ABREVIATURAS E SIGLAS
TCO – Total Costs Ownerships
ISO – International Organization for Standardization
ER – Entidade Relacionamento
TI – Tecnologia da Informação
AECL – Atomic Energy of Canada Limited
SQL – Structured Query Language
HDR – High Dynamic Range
DER – Diagrama Entidade Relacionamento
HTTP – HyperText Transfer Protocol
HTML – HyperText Markup Language
UML – Unified Modeling Language
JVM – Java Virtual Machine
GNU – Gnu is Not UNIX
CPU – Central Processing Unit
CA – Computer Associates
KDE – K desktop enviroment
GPL – General Public License
XML – eXtensible Markup Language
MSDN – Microsoft Developer Network
SUMÁRIO
RESUMO ...................................................................................................................... 7
LISTA DE ILUSTRAÇÕES ........................................................................................... 8
LISTA DE TABELAS .................................................................................................... 9
LISTA DE GRÁFICOS ................................................................................................ 10
LISTA DE ABREVIATURAS E SIGLAS ..................................................................... 11
1 INTRODUÇÃO ......................................................................................................... 13
2 UM BREVE HISTÓRICO .......................................................................................... 16
3 CLASSIFICAÇÃO DOS DOCUMENTOS DE SOFTWARE .................................... 24
4 FERRAMENTAS PARA DOCUMENTAÇÃO DE SOFTWARE ............................... 42
5 BOAS PRÁTICAS NA DOCUMENTAÇÃO DE SOFTWARE ................................... 54
6 Conclusões ............................................................................................................... 57
................................................................................................................................... 57
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 58
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 58
1 INTRODUÇÃO
A cada dia que passa nossa realidade muda, e são inseridas novas pala-
vras de ordem como: globalização, produtividade, eficiência entre outras tantas, que,
traduzindo, nos incentiva a alcançar o objetivo de produzir mais com mais qualidade
e melhor custo benefício utilizando menos recursos. A especialização deu espaço a
polivalência e a padronização se tornou algo indispensável.
Hoje um pequeno sistema pode ter telas desenvolvidas na Alemanha, in-
terface desenvolvida nos EUA, banco de dados na Índia, “tudo batido em um liquidifi -
cador técnico” na Austrália de onde irá surgir um produto revolucionário e barato que
vai “resolver” todos os problemas de um determinado segmento de usuários. Usuá-
rios estes, que cada vez mais detêm maior conhecimento dos sistemas, mais sabem
como eles funcionam e o que se esperar deles, mas que cada vez têm menos tempo
de definir bem o que ele realmente precisa e almeja antes de comprar seu novo pa-
cote de softwares.
A Evolução do hardware [2], apresentada na Figura 1.1, nos criou uma sé-
rie de possibilidades alavancando o desenvolvimento do software.
Figura 1.1: Evolução do Software [2].
A Figura 1.1 exibe as quatro principais eras da evolução de software. Na
visão do professor Lafayette B. Melo [19], uma quinta era começa a despontar. A so-
13
fisticação do software ultrapassou a capacidade de construir um software que tirasse
potencial do hardware. A capacidade de construir programas não acompanha a de-
manda, Engenheiros de Software não têm sido capazes de dar vazão a tantos requi-
sitos. E qual a relação disso com a documentação de software? Vejamos.
Você viaja a China para os jogos olímpicos e não conhece uma palavra de
mandarim e, para tornar o cenário um pouco mais complexo, o bom chinês que o
atende em um hotel sequer ouviu uma palavra em português. Qual a solução vem à
mente? Obviamente apelar para a língua mais difundida do mundo em termos co-
merciais, ou seja, o Inglês. Em qualquer lugar do mundo, alguém “arranha” algumas
palavras chave da língua inglesa e qualquer dificuldade sempre é possível utilizar
um bom e velho dicionário para descobrir aquela palavra que faltou para completar a
frase.
Fazendo uma simples analogia, a língua inglesa seria o padrão que nos
colocaria no mesmo nível de entendimento e o dicionário seria a documentação que
nos mostra como o padrão foi definido e como ele está relacionado com os dispositi -
vos de nosso conhecimento.
Essa abstração do que está encapsulado na “caixa preta” que é o softwa-
re que eu estou utilizando para escrever agora e que você utiliza para sacar dinheiro
no caixa eletrônico, é o que vai colocar em nível de igualdade programadores e de-
senvolvedores em qualquer lugar no tempo e espaço. Tal abstração permite que um
programador não necessite de abrir uma linha de código para saber quais as restri-
ções o desenvolvedor original definiu para um determinado método ser executado.
Nos próximos capítulos deste trabalho, iremos ver que tão importante
quanto um software bem estruturado e eficiente, é uma documentação completa,
ágil e bem feita. Veremos também, que a documentação começa antes mesmo da
primeira linha de código ser gerada e que ela irá tornar o produto final mais adequa-
do aos requisitos do usuário.
Falaremos também da documentação para o usuário, tão importante quan-
to à documentação técnica, mas que proporciona ao usuário a capacidade de usu-
fruir todo o potencial do software.
A boa pratica de documentação não se resume somente a padronização e
utilização de técnicas, mas estende-se ao sentimento do desenvolvedor aliado ao
14
perfil do projeto, já que cada projeto demanda um tipo de análise e aplicação dessas
técnicas.
Cristiano,
É apenas uma preferência minha (sugestão), mas gosto de ver a organiza-
ção do trabalho, no formato: Capítulo 2... no terceiro capítulo... acho que situa e pre-
para o leitor para os temas discutidos.
.
15
2 UM BREVE HISTÓRICO
A história da documentação de software confunde-se com a própria histó-
ria da engenharia de software [1] - o termo engenharia de software apareceu entre
os anos de 1960 e 1970. Antes disso, hardware e software tinham aplicações espe-
cíficas para ciência, engenharia, civil e outros campos. Os softwares eram progra-
mados em linguagens como COBOL, FORTRAN e ALGOL, contudo, com o apareci-
mento de novos computadores, essas linguagens sofreram adaptações para essa
nova realidade e as grandes empresas de hardware não tinham como vender seu
produto sem o software. Dessa forma, abriu-se espaço para o aparecimento de em-
presas de software que desenvolviam e negociavam pacotes de software para o
novo hardware que surgia com evolução cada vez mais rápida.
Sendo assim, o status dos programadores foi crescendo e para se traba-
lhar no desenvolvimento dos softwares e aplicativos, cada vez mais os programado-
res tinham que conhecer sobre mecânica, elétrica, civil e finanças, além da enge-
nharia da computação. Muitos acreditam que em 1969 a NATO Science Committee
em uma de suas conferências na Alemanha, marcou o inicio da utilização do termo
[1].
Nasciam ali os profissionais do software que motivaram, após um período
negro de crises de desenvolvimento ocorridas entre as décadas de 1970 e 1980, o
aparecimento dos padrões e documentações dos softwares.
2.1 O QUE É DOCUMENTAR UM SOFTWARE?
O processo de documentação de software tem muitas etapas e abrange
todo o sistema desde a idealização até a implementação. Ele é dividido em três
16
grandes grupos, a saber: a documentação técnica, a documentação de uso e a do-
cumentação de marketing [13].
A documentação técnica tem como alvo o próprio desenvolvedor e o man-
tenedor, bem como o pessoal da Tecnologia de Informação (TI), que irá trabalhar di-
retamente como o software. A maioria dos programadores imagina a descrição das
linhas de código quando se fala de documentação técnica, mas ela vai muito além. A
documentação da arquitetura do sistema é um dos pontos mais importantes e deve
ser um dos primeiros documentos a serem gerados assim que a análise de requisi-
tos junto ao usuário for concluída. Na documentação técnica, estão inclusos casos
de uso, diagramas de classe, dicionários e modelos de dados, fluxogramas de pro-
cesso, regras de negócios, comentários de códigos, entre outros.
A documentação de uso é destinada ao usuário final: são apostilas, manu-
ais, help on-line entre outros documentos que podem ser utilizados pelos usuários
para aprender como utilizar o software, o que se esperar dele, sanar eventuais pro-
blemas e como tirar dele as informações que lhe serão úteis.
Já a documentação de marketing nem sempre é aplicada a todos os tipos
de software; ela aplica-se aos grandes pacotes de software ou a softwares pré-con-
cebidos para uso geral que atende as necessidades específicas de um grupo de
usuários. Esta documentação abrange os folders explicativos, briefs exemplificando
funcionalidades, demonstrativos de custo benefício e promoções entre outras.
2.2 COMO COMEÇOU?
Entre o final da década de 60 e o final dos anos 80 ocorreu uma grande
onda de desenvolvimento de softwares devido à demanda crescente do hardware
disponível. Isso causou um das maiores abalos já vistos no mercado de desenvolvi-
mento de software que ficou conhecido como a “Crise do Software” [1]. Grandes pro-
jetos eram iniciados sem nenhum tipo de preparação e desenvolvidos por programa-
dores sem habilidade suficiente, o que resultou em projetos com custos muito acima
dos previstos, com prazos vencidos e de qualidade reprovável.
17
Problemas como as falhas ocorridas em um sistema utilizado em apare-
lhos de radioterapia que falharam e aplicaram doses letais de radiação em seus pa-
cientes. Um dos casos mais famosos é o do equipamento Therac-25 [6] produzida
pela Atomic Energy of Canadá Limited (AECL) e a CGR MeV da França. Este equi-
pamento esteve envolvido em pelo menos 6 acidentes entre 1985 e 1987, destes 6
casos 3 levaram a morte dos pacientes envolvidos. Especialistas que investigaram o
caso chegaram a conclusão que o software desenvolvido para controlar o equipa-
mento foi responsável pela falha que fez com que alguns pacientes fossem expostos
a radiação 100 vezes maior do que a devida causando o envenenamento por radia-
ção nas vítimas. Casos como este fizeram à confiabilidade dos softwares cair.
Por décadas, Engenheiros de Software trabalharam para resolver esses
problemas e desenvolveram técnicas não só para resolver tais problemas, mas para
evitar possíveis erros futuros. Essas práticas, que foram chamadas na época de “Sil-
ver Bullets” (Cabe citar este artigo que praticamente encerrou esta discussão, ou
seja, não existe uma “bala de prata” para a complexidade no desenvolvimento de
software, o que podemos fazer é “administrá-la” através das práticas preconizadas
na engenharia de software. O artigo segue em anexo - Broo87. Acho que é um “gan-
cho” interessante para o texto.), seriam as balas de prata para matar os “monstros
da crise”; um deles conhecido a falta de disciplina, pois muitos acreditavam que a
ausência de disciplina de alguns programadores era o motivo de algumas negligên-
cias. Dessa forma, métodos formais de construção de software deveriam ser aplica-
dos, assim, um padrão seria estabelecido e improvisos minimizados. A profissionali-
zação dos programadores criação de códigos de ética, licenças para produção de
software entre outros, foram ferramentas que auxiliaram especialização da produção
do software. Entre essas ferramentas, estava à utilização de documentação do
software que previa a criação de cases para estruturar a programação e manter pa-
dronização.
18
2.3 PORQUE DOCUMENTAR UM SOFTWARE?
A documentação do software é considerada pela maioria dos programa-
dores como a parte mais tediosa da criação do software [18]. Muitos a consideram
como perda de tempo com algo de menos valor no ciclo de desenvolvimento do
software, porém, uma boa documentação técnica além de facilitar o processo de de-
senvolvimento, pode salvar muitas horas de engenharia na hora da manutenção do
software, assim como uma boa documentação de uso irá salvar muitas horas de
atendimentos em pós-venda.
A documentação também auxilia na identificação de bugs durante o pro-
cesso de desenvolvimento, evitando que softwares com falhas de segurança ou de
requisitos sejam implementados.
Na Figura 2.1 podemos ver o framework fornecido pela norma ISO 12207
(Processos de Ciclo de vida do Software) [4]. Nos processos de apoio, podemos ver
que a documentação está presente.
19
Figura 2.2: Framework fornecido pela norma ISO 12207 [4].
A documentação é primordial em sistemas desenvolvidos com grande divi-
são de fases. A documentação pode ser vista como a “cola” que une os diversos ti-
mes que trabalham em fases diferentes colocando-os em sintonia.
Documentar as várias etapas de desenvolvimento desde a fase de análise
de requisitos torna os integrantes do projeto mais proficientes do objetivo do novo
sistema e das armadilhas que se escondem por trás das definições entre usuário e
desenvolvedores, bem como os torna mais cientes do planejamento das estratégias
de como chegar ao sucesso no fim do empreendimento.
20
2.4 IMPACTO FINANCEIRO DA DOCUMENTAÇÃO DO SOFTWARE
Obviamente, tudo que demanda horas de trabalho de programadores ou
engenheiros de software custa dinheiro. Mais do que os recursos materiais envolvi-
dos no desenvolvimento de software, os custos mais relevantes em qualquer projeto
são as horas despendidas por profissionais para gerar o produto final.
Quando falamos do custo de um sistema, em geral, nos referimos ao seu
Custo Total de Propriedade TCO (Total Cost of Ownership) [3]. O TCO é o custo to-
tal do sistema para organização. Logicamente, o custo da documentação está aí em-
butido, porém, existem também benefícios a serem considerados como: a facilidade
de manutenção, ganho de tempo em atualizações e evoluções do software, adapta-
ção rápida do usuário e dos administradores do sistema entre outras. Contudo, infe-
lizmente nem sempre é fácil traduzir esses benefícios em números, o que por muitas
vezes a título de economia, faz com que sejam minimizadas a quantidade e qualida-
de da documentação. É muito fácil imaginar que horas trabalhadas naquilo que não
se tornará produto final palpável serão horas desperdiçadas, por isso é muito impor-
tante antes de qualquer coisa traçar objetivos claros do que se pretende gerar como
produto final. Entender bem o que o desenvolvedor irá precisar como documentação
e também o que o cliente espera receber, é um balanço que deve ser detalhada-
mente realizado. O objetivo deste trabalho é chamar a atenção para a importância
da documentação de software, mas sem nunca inviabilizar projetos em função disso.
A utilização das ferramentas adequadas para geração da documentação,
bem como fazê-la em tempo hábil, é fundamental para minimização do impacto dos
custos que este processo gera. Por exemplo, uma boa documentação da arquitetura
do sistema é algo desejável, contudo, este tipo de documentação é pequena e obje-
tiva. Explicações de detalhes mais profundos podem ser conseguidas explorando o
projeto. Portanto, caso informações brutas possam guiar o engenheiro a conseguir
sua resposta em outra documentação, nem sempre é necessário empreender horas
de desenhistas para detalhar cada explicação sobre o projeto. Um grande e comum
erro é tentar preparar uma única documentação que seja abrangente e atenda todo
21
tipo de pesquisa e profissional. Não raro, este tipo de pretensão leva a documenta-
ções complexas e caras veja Figura 2.2 [12].
Figura 2.3: Creativity in Engineering (Paper Submission Guidelines – www.phd-
comics.com) [12].
Assim, o “bom senso” deve ser sempre utilizado, mas não é tudo; antes de
evoluir com o projeto é importante discutir com os envolvidos e interessados quais
sãos suas necessidades, definir o número de documentos a ser gerado, pesar qual o
custo destes documentos, escolher a mídia que será utilizada, estimar quantas ho-
ras os programadores gastarão em determinada tarefa, e decidir até qual deles está
mais bem preparado para um trabalho especifico. Este último faz-se de fundamental
importância quando o processo de produção de documentação é considerado, já
que os programadores sabem muito bem como programar, mas nem sempre têm
boa aptidão para redigir.
Seguir as diretrizes básicas [10] (Prazo, Escopo, Custo e Qualidade) e
manter em mente que escopo, prazo e custo podem e devem ser negociados no iní-
cio do projeto, mas que qualidade é inegociável (Figura 2.3) são algumas instruções
básicas para que se tenha um bom produto final.
22
Figura 2.4: Diretrizes básicas no projeto de Software [10].
Com o passar do tempo, os custos de manutenção de software cresceram
assustadoramente. Veja o Gráfico 1 que mostra o percentual do custo de manuten-
ção em relação ao custo do sistema [9].
Gráfico 2.1: Parte da manutenção no custo total de um software [9].
Portanto é significante já desenvolver o projeto com o pensamento voltado para
a facilidade de manutenção.
23
3 CLASSIFICAÇÃO DOS DOCUMENTOS DE SOFTWARE
O termo documentação de software possui diferentes significados para di-
ferentes pessoas ou grupos de pessoas. Neste capítulo, iremos abranger os dois
grupos mais significantes para os diversos profissionais. São eles:
A documentação técnica: que abrange a documentação da arquitetura, e
a documentação técnica propriamente dita,
A documentação de uso: que visa o atendimento das necessidades dos
usuários e administradores do sistema.
3.1 DOCUMENTAÇÃO TÉCNICA OU DOCUMENTAÇÃO AO USUÁRIO
Muitas vezes, a definição da documentação a ser gerada causa alguns er-
ros de avaliação devido à confusão entre qual documentação será utilizada. Na ver-
dade, não cabe uma decisão por tipo de documentação; as duas documentações
são necessárias, e cabe ao desenvolvedor adotar o tipo de documentação que será
utilizada.
No caso da documentação técnica, deve-se determinar qual será a abran-
gência da documentação, bem como quais as ferramentas são mais adequadas
para documentar o software que atenda o planejado.
Na documentação de uso, devem-se escolher qual a mídia e qual a lingua-
gem é mais adequada ao grupo de usuários que a utilizarão.
24
3.2 TIPOS MAIS COMUNS DE DOCUMENTAÇÃO PARA O USUÁRIO
Existe todo um universo de possibilidades quando falamos de documenta-
ção ao usuário, contudo, o importante é que a documentação seja coerente, comple-
ta e ágil. A documentação de uso deve proporcionar ao usuário uma visão completa
do sistema e de suas funcionalidades. Já a documentação do usuário, deve disponi-
bilizar uma sistemática de solução de problemas (troubleshooting) que permita ao
próprio usuário identificar erros e corrigi-los. Além disso, este tipo de documentação
deve possuir uma seqüência lógica para que o usuário possa evoluir com o desenro-
lar da leitura de forma autodidata. Adicionalmente, o manual do usuário deve exibir
um excelente índice com todas as possibilidades de referências cruzadas de modo a
permitir que o usuário encontre a informação desejada. Além de tudo, o manual do
usuário deve ter uma boa apresentação: a escolha de fontes, cores e gráficos deve
ser harmoniosa de modo a proporcionar conforto ao leitor.
Sem dúvida alguma, o modo de documentação do usuário é o mais conhe-
cido do público em geral, vamos a alguns deles:
Manual do usuário (User Guide): normalmente disponibilizado em papel
contendo as funcionalidades do sistema com objetivo de auxiliar o usuário a utilizar
estas funções. Hoje em dia, é comum que este documento seja também disponibili-
zado em CD´s ou DVD´s (Figura 3.1).
25
Figura 3.5: Manual do usuário em papel e CD/DVD.
No manual do usuário, encontram-se também informações sobre pré-re-
quisitos para implantação do sistema, bem como informações sobre o desempenho
esperado do mesmo.
Geralmente, no manual do usuário existe uma seqüência de screenshots
(imagens capturadas das telas) que tornam o manual o mais auto-explicativo possí-
vel.
26
Manual de acesso rápido (Quick start guide): muito comum em softwa-
res e sistemas de pequeno porte que são normalmente de uso genérico. Normal-
mente, este tipo de manual mostra os pontos básicos a serem configurados para ini-
ciar o uso do software. Assim, este manual possibilita a implantação do software de
modo rápido, o que permite que o usuário inicie o uso do sistema e o vá configuran-
do por completo durante o uso.
Figura 3.6: Manual de acesso rápido.
Em muitos casos, o manual de acesso rápido é disponibilizado na própria
embalagem do produto como apresentado na Figura 3.2. Geralmente, dispõe-se de
imagens ilustrando o uso do produto de modo a acelerar o entendimento do sistema.
Dispositivo de ajuda (Help): praticamente disponível em todos os siste-
mas. Trata-se de uma aba, guia ou link disponível no próprio software como mostra-
do na Figura 3.3.
27
Figura 3.7: Dispositivo de ajuda.
Estes links normalmente possibilitam o acesso a um manual do usuário
ou sistemas de busca robotizados que permitem ao usuário ir diretamente a uma in-
formação desejada. Em alguns softwares este recurso está disponível de modo on-
line permitindo que através de um link o usuário acesse uma página da web (Figura
3.4) que hospeda informações que podem auxiliar ao usuário sanar suas dúvidas.
Figura 3.8: Help on-line.
28
3.3 TIPOS MAIS COMUNS DE DOCUMENTAÇÃO TÉCNICA
Não diferente da documentação destinada ao usuário, a documentação
técnica abrange um vasto leque de possibilidades. A documentação técnica é em te-
oria a parte mais simples do processo de documentação, pois trata de mostrar o tra-
balho a ser desenvolvido (do modo como ele é feito) de um modo padronizado e in-
teligível. Na maioria dos casos, a documentação técnica não só objetiva a futura
compreensão do sistema desenvolvido, mas também é uma ferramenta útil para o
seu desenvolvimento.
A documentação técnica inicia-se na obtenção dos requisitos, seguindo
para a definição da arquitetura e percorre todo o caminho do desenvolvimento do
sistema, passando pela elaboração de casos de uso bem definidos, fluxogramas elu-
cidativos e comentários de códigos bem estruturados.
A documentação técnica não deve explicar porque uma determinada fun-
ção foi criada, mas sim quais os requisitos que motivaram a criação desta função. A
documentação técnica deve mostrar, de maneira geral, como a estrutura foi montada
e desenvolvida. Em alguns pontos, ela pode referenciar documentos que levam a
um maior detalhamento.
O processo para criação da documentação técnica está em freqüente evo-
lução, contudo, existem algumas ferramentas mais comumente utilizadas, vamos a
elas [13]:
Documentação de arquitetura: A função do arquiteto de software é esta-
belecer uma visão geral de todos os pontos da arquitetura do projeto, bem como
acompanhar e coordenar diversas atividades e artefatos técnicos durante o projeto
(Figura 3.5), portanto, a visão deste profissional é muito mais geral do que detalha-
da. Uma de suas atribuições é gerar a documentação de arquitetura [16].
29
Figura 3.9: Atribuições do Arquiteto de Software. Rational Software Corpora-
tion [47].
A documentação de arquitetura, que é gerada pelo arquiteto de software,
deve ser orientada a uma série de visões diferentes que visam compor o pacote do
projeto como um todo. Entre algumas visões mais usuais podemos destacar [11]:
Casos de uso: Descrevem o conjunto de cenários e/ou os casos de uso
que representam alguma funcionalidade central e significativa. Também descreve o
conjunto de cenários e/ou casos de uso que possuem cobertura arquitetural subs-
tancial (que experimenta vários elementos de arquitetura) ou que enfatizam ou ilus-
tram um determinado ponto complexo da arquitetura (Figura 3.6).
30
Figura 3.10: Exemplo casos de uso [11].
Visão lógica: Descreve as classes mais importantes, sua organização em
pacotes e subsistemas de serviço, e a organização desses subsistemas em cama-
das (Figura 3.7).
Figura 3.11: Visão lógica da documentação de arquitetura [11].
31
Visão de processo: Descreve os modos principais de comunicação entre
processos, como transmissão de mensagens e interrupções (figura 3.8).
Figura 3.12: Visão de processo da documentação de arquitetura [11].
Visão de implantação: Descreve uma ou mais configurações (hardware)
de rede física nas quais o software será implantado e executado. Para cada configu-
ração, ela deve indicar no mínimo os nós físicos (computadores, CPUs) que execu-
tam o software e as respectivas interconexões (barramento, LAN, ponto a ponto e
assim por diante.). Além disso, ela inclui um mapeamento dos processos da Visão de Processos nos nós físicos (Figura 3.9).
Figura 3.13: Visão de Implantação da documentação de arquitetura [11].
Modelos de dados: É um conjunto de ferramentas conceituais para des-
crição, relacionamento, semântica e restrições relativas aos dados. São modelos co-
32
nhecidos: modelos lógicos baseados em objetos (também conhecidos como mode-
los conceituais), modelos lógicos baseados em registros, e modelos físicos de dados
[5].O modelo de dados é um exemplo de documentação a ser criada antes do
inicio do desenvolvimento do projeto. A geração de representações gráficas do pro-
jeto como um todo pode evitar perda de tempo e desenvolvimento equivocado, além
de dar uma visão geral ao desenvolvedor e ao seu cliente final do que está sendo
considerado no projeto.
Um bom exemplo de modelo lógico baseado em objeto é o modelo entida-
de relacionamento (ER) como pode ser visto na Figura 3.10. Este modelo é baseado
em uma percepção do mundo real que traça relacionamento entre entidades que
nada mais são que os objetos do banco de dados e seus atributos. Neste tipo de di-
agrama, a visão imediata do relacionamento entre estes objetos permite uma avalia-
ção rápida do esquema entre o banco de dados proposto.
Figura 3.14: Modelo Entidade Relacionamento.
Modelos lógicos baseados em registro são muito parecidos com os mode-
los conceituais, porém, conseguem apresentar uma visão geral do banco de dados
da forma como os dados estão fisicamente armazenados. Ele não só provê uma es-
trutura lógica geral, mas também, fornece uma descrição de alto nível de implemen-
tação [14].
Podemos ver um exemplo deste modelo na Figura 3.11. A partir deste mo-
delo, podemos convertê-lo para estrutura final do banco de dados sem perda as ca-
racterísticas como no exemplo em SQL (Structured Query Language) na Figura
3.12.
33
Figura 3.15: Modelo lógico baseado em registros [14].
Figura 3.16: Modelo lógico convertido para SQL [14].
Os modelos físicos mostram conceitos que descrevem os detalhes de
como os dados encontram-se armazenados no computador. Representam informa-
ções como formato dos registros, ordenação dos registros e caminhos de acesso.
Os modelos físicos são poucos se comparados com os modelos conceituais e lógi-
cos. Dois dos modelos físicos mais utilizados são o modelo unificador (unifying mo-
del) e o modelo de estrutura de memória (frame memory).
34
Dicionário de dados: O dicionário de dados nada mais é que uma tabela
que descreve e define o significado de toda informação usada na construção de um
sistema. É uma listagem organizada de todos os elementos de dados pertinentes ao
sistema, com definições precisas e rigorosas para que se possam conhecer todas as
entradas, saídas, componentes de depósitos e cálculos intermediários. O dicionário
de dados permite a verificação de consistência entre vários modelos. O dicionário de
dados é composto por especificações de fluxo de dados, de arquivos e de proces-
sos, e cada ocorrência deve contemplar no mínimo os seguintes itens: nome, tipo,
descrição, pseudônimo, especificação e comentários significativos [15].
É possível apresentar o dicionário de dados de duas maneiras: como uma
lista e como uma tabela.
A representação em forma de lista é muito similar a um dicionário tradicio-
nal que utiliza símbolos especiais para definir o relacionamento entre os itens como
vemos na Tabela 3.1. A Figura 3.13 mostra um exemplo desta aplicação.
Tabela 3.1: Notação típica do dicionário de dados.
35
Figura 3.17: Exemplo de dicionário de dados.
A representação na forma de tabela (Tabela 3.2) torna as informações
mais simples de serem visualizadas. Este documento associado a um bom modelo
de dados torna a documentação coesa e muito completa, o que facilita tanto o traba-
lho de desenvolvimento quanto trabalho de manutenção.
Tabela 3.2. Modelo de dicionário de dados em tabela [18].
Fluxogramas: Expressam graficamente a seqüência lógica das informa-
ções de um processo ou sistema, utilizando para isso vários elementos de geometri-
as diferentes que indicam cada uma das partes do processo. Os fluxogramas talvez
sejam as mais antigas ferramentas para documentação do software. Antigamente,
fluxogramas eram utilizados como um mecanismo de representação gráfica de algo-
ritmos e seu fluxo de controle [29]. São excelentes ferramentas de fácil entendimen-
to tanto para o pessoal de desenvolvimento como os usuários. Quando associados a
outras ferramentas de documentação, apresentam um excelente conjunto de infor-
mações sobre o sistema, tornando clara a visualização das potencialidades e fraque-
zas do mesmo.
36
Na Figura 3.14 podemos ver alguns tipos de fluxogramas que podem ser
utilizados, porém existe uma infinidade de tipos e padrões disponíveis que podem
ser melhores adaptados a diversos casos.
Figura 3.18: Tipos de fluxograma [29].
Os fluxogramas possuem algumas limitações como, por exemplo, serem
utilizados como modelagem de alto nível, pois os fluxogramas representam uma ló-
gica procedimental de forma seqüencial, logo, é difícil representar processos assín-
cronos. Outra restrição é o seu uso como modelagem de processo, pois documen-
tam o processo a um nível muito baixo, quase que linha a linha no código, perdendo
sua função de abstração do processo [29].
Nada impede que um fluxograma complexo seja gerado para atender to-
das as necessidades, porém, o ideal é utilizar o fluxograma como ferramenta de
apoio as demais ferramentas e não concentrar as informações nesta ferramenta.
Documentação de código: Sempre que se fala em documentar um
software esta é a ferramenta que primeiro vêm à cabeça de qualquer programador.
Não existe um consenso de seu uso entre os programadores. Alguns
acreditam que um código estruturado fala por si só seu significado, outros acreditam
que cada linha deve ser comentada. O fato é que é praticamente impossível se pen-
sar em manutenção e reuso de software sem considerar esta documentação.
Existem basicamente duas maneiras de se documentar um código: man-
tê-lo documentado on-line, ou seja, no próprio programa fonte, ou gerar uma docu-
37
mentação externa. Ambas as ferramentas são importantes, mas para os programa-
dores, a documentação no próprio código é a mais facilmente realizada, pois ela
pode ser criada em conjunto com o software. Construir uma documentação posterior
a criação do software, além de tediosa pode ser falha. Hoje em dia, existem meca-
nismos automatizados (como o Sandcastle da Microsoft) que geram a documenta-
ção extraindo-a diretamente do próprio código fonte. Porém, isso claramente mostra
que depende única e exclusivamente do programador gerar uma documentação efi-
ciente do código fonte para que futuras manutenções possam ser feitas com mais fa-
cilidade.
A boa prática de documentação de código não exige quilômetros de li-
nhas de comentários, mas sim linhas oportunas que indiquem “o caminho das pe-
dras” ao próximo programador que tiver que atualizar ou manter este programa. A
Figura 3.15 exemplifica um pequeno código que mostra uma documentação simples
e efetiva.
Figura 3.19: Código fonte documentado [18].
Alguns programadores julgam que documentar o código fonte em portu-
guês não é o ideal, pois desvirtua o código. É muito provável que este tipo de pre-
conceito tenha nascido da comparação ao pseudocódigo (Figura 3.16). Pseudocódi-
go é uma forma genérica de escrever um algoritmo, utilizando uma linguagem sim-
ples, nativa a quem o escreve, de forma a ser entendida por qualquer pessoa, sem
necessidade de conhecer a sintaxe de nenhuma linguagem de programação [7].
38
Algumas linguagens como o Basic, por exemplo, se assemelham muito ao pseu-
docódigo em língua inglesa, o que fez com que a criação de pseudocódigo em portu-
guês aparentasse algo que destoa da programação em qualquer outra linguagem
que tem base na língua inglesa.
Figura 3.20: Pseudocódigo em português.
Isto não é verdade, a documentação deve ser sucinta, mas objetiva, deve
ainda descrever as partes mais importantes do código e mostrar sua usabilidade.
Qualquer que seja a língua utilizada o software estará bem documentado se atingir
estes objetivos. É claro que se o software se aplica de uma maneira globalizada, é
mais aceitável que se use uma língua mais difundida mundialmente, nesse caso o
inglês seria mais adequado.
3.4 A UTILIZAÇÃO DA DOCUMENTAÇÃO NO PROJETO DE SOFTWARE
A utilização da documentação no projeto de software é muito relativa e
pode ser “atacada” de diversas formas que variam principalmente em função da di-
mensão do projeto ou dos recursos do desenvolvedor. Contudo, apresento aqui al -
gumas diretrizes básicas que servem como orientação de organização de um plano
de projeto de software. São elas [20]:
39
Plano de projeto: Identificar o que o cliente espera do produto final, quais
os objetivos, bem como será o gerenciamento do software durante o desenvolvimen-
to. O plano de projeto pode também incluir o plano de gerenciamento da configura-
ção e o plano de qualidade assegurada.
Plano de gerenciamento de configuração: Especificam plataformas, sis-
temas operacionais e descreve detalhadamente o arquivo de sistemas, editando o
código fonte e mantendo o projeto atualizado em detalhes. O resultado esperado ao
se executar este plano é manter todo um histórico do que aconteceu durante o de-
senvolvimento do projeto.
Plano de qualidade assegurada: Programa um plano de controle de qua-
lidade e define métodos, métricas e verificações para garantir que os requisitos de
qualidade especificados sejam atingidos ou excedidos.
Especificação de requisitos: Descreve os requisitos funcionais de um
produto de software. O perfil do usuário e a metodologia do desenvolvimento são
apresentados neste documento, bem como o que está fora do escopo. Deve tam-
bém conter os requisitos de interface definidos pelo usuário. Requisitos como porta-
bilidade e usabilidade também devem ser definidos. Os requisitos são analisados e,
então, o software proposto é apresentado em um contexto mais abstrato como em
casos de uso e fluxogramas associados a dicionários de dados.
Documento e Projeto: Descreve o projeto de software em detalhes. A ar-
quitetura do sistema é descrita por fluxogramas e digramas em diversos níveis de in-
teração. Este documento contém um completo dicionário de dados onde são descri-
tos e definidos todos os nomes dos módulos, variáveis e nomes utilizados no código
fonte.
Documento de código: Contém o código fonte do software. Como uma
introdução sobre a arquitetura do sistema e um diagrama de interações com o usuá-
rio, os comentários do código fonte ajudam a esclarecer suas funções.
Plano de Testes: Apresenta uma classificação de erros para o software e
a filosofia por trás deles. Testes de software são programados em ambientes descri-
tos em detalhes, e procedimentos são aplicados para identificar possíveis falhas e
prever erros latentes. Os testes são executados até a aceitação final do produto.
40
Manual de Instalação: Apresenta instruções de como instalar o produto
bem como os pré-requisitos de hardware e software.
Manual do usuário: Descreve como usar o software. Tutorias de usuário
devem ser incluídas neste documento. O manual do usuário deve ser uma completa
referência para uma ajuda básica ao usuário, e deve fornecer um texto compreensi-
vo e uma ótima referencia cruzada entre os tópicos descritos nos tutoriais.
41
4 FERRAMENTAS PARA DOCUMENTAÇÃO DE SOFTWA-RE
Existe disponíveis no mercado uma série de ferramentas para geração de
documentação de software, algumas de uso gratuito, outras com altíssimos custos, e
até outras de código aberto onde o programador pode (caso tenha tempo e
domínio), adaptar a suas necessidades. Todas as ferramentas são boas se utiliza-
das corretamente, e se escolhidas de acordo com a documentação a ser gerada.
Muitas vezes o público alvo é quem define qual o refinamento a documentação de-
verá ter, porém, sem dúvida nenhuma, uma boa ferramenta também é sinônimo de
qualidade final e ganho de tempo no desenvolvimento do documento.
4.1 FERRAMENTAS PARA CRIAÇÃO DE DOCUMENTAÇÃO DO USUÁRIO
A documentação do usuário é a mais simples de ser gerada se falamos
em termos de ferramentas, já que, na maioria dos casos, um bom editor de textos
“dá conta do recado”. Contudo, existem muitas ferramentas disponíveis no mercado
que facilitam o projetista nas tarefas muitas vezes maçante de se escolher imagens
adequadas, ajustá-las, criar indexação nas buscas, etc. Também, não se pode es-
quecer-se dos sistemas de ajuda automatizados que são praticamente um pequeno
sistema à parte.
Algumas das ferramentas atualmente disponíveis podem ser separadas
em quatro grupos: escrita, desenho, help on-line e Web.
Escrita:
Word da Microsoft: Editor de texto, um dos mais conhecido mundialmente, fácil de
utilizar possui recursos de auto-índice, auto-paginação, inserção de imagens entre
outros. Logicamente qualquer bom editor pode substituí-lo, o Open Office possui fer-
ramentas tão boas quanto, mas os editores de texto são mais indicados para manu-
ais curtos e sem muitas exigências [21].
42
FrameMaker da Adobe: O Adobe FrameMaker é uma poderosa ferramenta de cria-
ção e publicação para comunicadores técnicos. É possível trabalhar em WYSIWYG
(What You See Is What You Get, que significa “o que você vê é o que você obtém”.
Esse recurso foi utilizado com muito sucesso na indústria gráfica e nos editores de
texto. As ferramentas WYSIWYG (como o MS Word e Adobe Acrobat) permitiram
que os designers gráficos economizassem bastante tempo e dinheiro na visualiza-
ção exata que os documentos teriam antes de serem impressos). Ambiente de cria-
ção com base em modelo, é possível trabalhar com conteúdo estruturado em XML e
SGML com DITA ou DocBook, variações de um único local do mesmo documento
por meio de uma saída condicional avançada e utilizando suporte para Unicode, 3D
e o conteúdo avançado para criar documentação interativa em vários idiomas. É
uma ferramenta a ser utilizada na geração de manuais maiores [22].
PageMaker da Adobe: O Adobe PageMaker é um programa de layout de páginas,
excelente para os pequenos empresários e para os que possuem escritório em casa,
que queiram criar publicações de alta qualidade como folhetos e boletins informati -
vos. Tem uma interface amigável que permite um começo rápido com modelos, ele-
mentos gráficos e ferramentas de design intuitivas; possibilita ótima produtividade
em todos os aplicativos da Adobe, facilitando o reaproveitamento de qualquer conte-
údo já existente para criar uma comunicação personalizada. Um dos mais populares,
um editor com extremos recursos e com ótimo resultado final [23].
Publisher da Microsoft: O Microsoft Office Publisher é um programa de
publicações comercial que ajuda a criar, desenhar e publicar materiais de marketing
e de comunicação profissionais. É possível criar materiais para impressão, para e-
mail e para a Web usando um ambiente intuitivo e com base em tarefas que o
orienta desde o conceito inicial até a entrega final, sem ajuda de profissionais para o
design e produção. Muito utilizado na produção de newsletters [24].
Desenho:
Illustrator da Adobe: O Adobe Illustrator é um ambiente gráfico de vetor abrangente
com transparência em gradientes e várias telas de pintura, possibilitando explorar
modos mais eficientes de criação. É um grande software de criação de gráficos veto-
43
riais e pode ser tanto utilizado para material impresso como para material para WEB
(use uma única forma no texto web, Web ou WEB) [25].
CorelDraw da Corel Corporation: O CorelDRAW possui ferramentas de precisão, a
compatibilidade de arquivos otimizada e o conteúdo atualizado de alta qualidade aju-
dam a transformar simples idéias em resultados profissionais: desde logotipos e an-
úncios de grande apelo visual excelentes materiais de marketing e atrativos gráficos
para a Web (ver comentário acima). Um dos mais poderosos softwares de desenho
do mercado, apesar de um software “pesado”, continua sendo um dos mais utiliza-
dos para trabalhos impressos [26].
Photoshop da Adobe: Aplicação que hoje em dia é referência em edição de ima-
gens, seu uso só não é mais difundido devido a seu alto custo. Possui uma infinida-
de de ferramentas entre elas: manuseio rápido de arquivos com o Adobe Bridge,
ponto de fuga revolucionário, distorção de imagem, redução avançada de ruído, Su-
porte para HDR (High Dynamic Range) de 32 bits, áreas de trabalho e menus perso-
nalizáveis, melhor automação, objetos inteligentes, controle de camadas múltiplas,
processamento de arquivo do Camera Raw com várias imagens, visualize seus grá-
ficos da forma como eles serão exibidos para o público-alvo, entre muitas outras fer-
ramentas [27].
Paintshop Pro da Corel Corporation: O PaintShop Pro é um dos mais conhecidos
pacotes "shareware" (conceito em nota de rodapé) de edição gráfica do mercado,
sendo um produto da empresa Jasc Software, Inc (hoje pertencente a Corel Corpo-
ration). Extremamente poderoso, sendo quase tão completo como o PhotoShop, per-
mite entretanto maior facilidade na criação e edição de imagens. Trabalha com a
maioria dos formatos gráficos conhecidos, e permite inclusive a conversão entre for-
matos. Na verdade o PSP trabalha com 46 diferentes tipos de arquivos gráficos,
sendo 34 do tipo RASTER e 12 do tipo META e VETORIAL. Tem poder de manipu-
lação muito extenso como por exemplo: Criação de imagens (bitmaped), Retoque
em imagens prontas, ou escaneadas, captura de imagens na tela, conversão entre
formatos de imagens, trabalho com LAYERS, trabalho com seleções de imagens,
aumento ou redução de nível de cores (profundidade de cores), alterando a orienta-
ção de imagens, adicionando bordas, Cropping de imagens, uso de filtros para alte-
44
rar/deformar imagens, uso de máscaras. Aplicativo de edição de imagem com exce-
lentes recursos e resultados finais, muitas vezes utilizado como uma alternativa ao
Corel Draw e o Photoshop por ser mais barato [26].
On-line Help:
RoboHelp da Adobe: Excelente software para criação de Help on-line. O Adobe
RoboHelp é um sistema completo, flexível e de fácil uso para criar, gerenciar e publi -
car bases de conhecimento, sistemas de ajuda de software e documentação para
aplicativos de desktop e Web. Ele proporciona toda a funcionalidade de desktop que
usuários precisam para criar conteúdo de ajuda avançada, incluindo tabela de conte-
údos, índices, glossários, gráficos, efeitos especiais e ajuda em relação ao contexto.
Também fornece potentes recursos de servidor que garantem o fornecimento de
conteúdo on-line atualizado, com rastreamento em tempo real de como usuários fi-
nais interagem com o sistema de ajuda, o que traz feedback valioso para ajudar o
desenvolvedor [28].
Doc-to-Help da ComponentOne: O Doc-To-Help é um software para criação de ar-
quivos de Help. O usuário cria seus arquivos no Word, conseguindo assim usar re-
cursos do Word mais os recursos do Doc-To-Help. Ele cria arquivos nos formatos
Windows Help, HTML (Hypertext Markup Language), Java Help, HTML Help e Mi-
crosoft Help 2.0, para fazer com que as aplicações sejam muito mais profissionais
com arquivos de Help para ajudar os usuários finais à utilização do programa [30].
Alternativa para RoboHelp.
WEB:
FrontPage da Microsoft: O Microsoft FrontPage é uma ferramenta de criação e de
gerenciamento de webs que, embora não requeira de seus usuários nenhum conhe-
cimento de programação, constitui-se um poderoso instrumento para o desenvolvi-
mento de web sites, apesar de um pouco ultrapassada, pois a Microsoft lançou em
sua substituição a ele duas ferramentas, o Microsoft Office SharePoint Designer e o
Microsoft Expression, ela continua muito utilizada [31]. Uma das mais populares fer-
ramentas de desenvolvimento de páginas da Internet.
45
Macromedia Dreamweaver da Adobe: O Macromedia Dreamweaver é uma ferra-
menta poderosíssima para designers e produtores. Uma de suas muito importantes
funções é o "poder" de conectar-se com um banco de dados e permitir-nos realizar
operações com ele com incrível facilidade. Isso também permite o uso de "server
behaviors", que são comandos pré-defindos que nos permitem realizar com poucos
cliques e quase nenhuma digitação ou queima de neurônios operações complexas
ou trabalhosas, como inserção em banco de dados a partir de formulário o que de-
mandaria um trabalho considerável para relacionar campo do formulário/campo da
tabela. Ferramenta para desenvolvimento de páginas da web, autodidática com ex-
celentes recursos e geram ótimos resultados finais [32].
Macromedia Flash da Adobe: O Macromedia Flash, ou simplesmente Flash, é um
programa gráfico vetorial utilizado para se criar animações interativas. Os arquivos
executáveis gerados pelo Flash, chamados de "SWF" (Small Web File), podem ser
visualizados em uma página web usando um navegador web ou utilizando o Flash
Player. Em versões recentes (a partir da 5), a Macromedia expandiu a utilização do
Flash para além de simples animações, mas também para uma ferramenta de de-
senvolvimento de aplicações completas. Isso graças aos avanços na linguagem Ac-
tion Script que é a linguagem de programação do flash e já se encontra em sua se-
gunda versão de ferramentas de desenvolvimento de páginas da Web animadas têm
sido amplamente utilizada ultimamente por fornecedor um resultado final muito atra-
tivo visualmente [33].
4.2 TIPOS MAIS COMUNS DE FERRAMENTAS PARA DOCUMENTAÇÃO TÉC-
NICA
Em termos de ferramentas, a documentação técnica ainda é a mais difícil
de ser gerada. Além da falta de padronização que ainda existe, muitas das ferra-
mentas disponíveis são caras e pouco amigáveis, entretanto, existe uma série de
ferramentas simples que podem ajudar muito o desenvolvedor a documentar seu
projeto e torná-lo mais completo. Em muitos casos, a documentação técnica auxilia
46
a fase de desenvolvimento trazendo uma melhor organização e uma melhor escolha
de arquitetura, o que melhora também a performance do sistema. Existem algumas
ferramentas que podem ser utilizadas durante todo o processo de desenvolvimento
em diversas etapas, outras são simples ferramentas de uso diário que podem ser
utilizadas para geração do documento, como por exemplo, podemos utilizar o Micro-
soft Excel para gerar um dicionário de dados criando apenas regras que devem ser
seguidas na geração das tabelas. Enfim, documentar tecnicamente também explora
a criatividade do desenvolvedor. Ferramentas de documentação para modelagem,
códigos fonte e fluxogramas são as mais utilizadas, assim, vamos a algumas delas:
Modelagem
Rational Rose da IBM: O Rational Rose é um conjunto de ferramentas visuais de-
senvolvidas para soluções robustas de negócios em um ambiente de empreendi-
mento distribuído para aplicações cliente/servidor [34]. Modelamento visual é o pro-
cesso de descrever o sistema a ser desenvolvido graficamente. Assim, este procedi-
mento lhe permite apresentar detalhes essenciais de um problema complexo e dis-
pensar detalhes desnecessários. Também provê um mecanismo para visualizar o
sistema a ser desenvolvido de perspectivas diferentes. O Rational Rose é sem dúvi-
da uma das mais poderosas ferramentas de modelagem, contudo, é uma ferramenta
paga, o que dificulta o acesso de estudantes e pequenos empreendedores.
Oracle Designer da Oracle: O Oracle Designer é uma ferramenta de altíssima pro-
dutividade para o desenvolvimento de aplicações em equipes. Um poderoso reposi-
tório compartilhado associado a diagramas gráficos permite a criação de complexos
aplicativos automaticamente gerados para diversas linguagens 4GL, tais como De-
veloper, Visual Basic, Web, entre outras. Tudo isto sem a necessidade da codifica-
ção manual e com altos índices de produtividade, redução de custos e tempo de de-
senvolvimento [35].
CA ERwin Data Modeler da CA (Computer Associates): Mais conhecido como
ERwin, é uma ferramenta case para modelagem de dados relacional e dimensional,
que permite a construção de modelos de dados lógicos (Diagrama de Entidade Rela-
47
cionamento) e modelos de dados físicos. Atualmente comercializado pela CA (Com-
puter Associates), caracteriza-se pelo fácil manuseio e rápido entendimento das fun-
cionalidades, sem, no entanto, deixar de disponibilizar recursos avançados para a
construção, documentação, padronização, disponibilização e consulta dos modelos
de dados [36].
Jude da ChangeVision: O Jude é uma das ferramentas case (explicar o conceito
na primeira vez que aparecer) mais utilizadas por desenvolvedores Java. O Jude
serve para criar todos os tipos de diagrama da UML (Unified Modeling Language), é
muito leve, rápido, capaz de gerar classes Java e fazer engenharia reversa das clas-
ses para UML. Ele está disponível em duas versões, a Community que é gratuita e a
Professional que é paga. A versão Community, apesar de gratuita, atende 90% das
atividades que são realizadas no dia-a-dia de um desenvolvedor [37].
Códigos Fonte
Javadoc da SunMicrosystems: O Javadoc é um sistema de documentação criado
pela Sun Microsystems para documentar a API dos programas em Java, a partir do
código-fonte. O resultado é expresso em HTML (Hypertext Markup Language). É
constituído, basicamente, por algumas marcações muito simples inseridas nos co-
mentários do programa [38]. Este sistema é o padrão de documentação de classes
em Java, e muitas dos IDEs desta linguagem irão automaticamente gerar um Java-
doc em HTML. Ele também provê uma API para a criação de doclets e taglets, que
permitem a análise da estrutura de um aplicativo Java.
ROBODoc licenciado GPL (General Public License): O ROBODoc é uma ferra-
menta de documentação similar ao JAVADOC licenciada pela GPL, ela é utilizada
para extrair a documentação direto dos códigos fonte. Pode ser usada com qualquer
linguagem que suporte cabeçalhos especialmente formatados. As documentações
geradas podem ser formatadas em HTML, DocBook, TROFF, ASCII, Látex, PDF ou
RTF [39].
SandCastle da Microsoft: O SandCastel da Microsoft (Ms-PL – Mircrosoft Public Li-
cense) é uma ferramenta de documentação licenciada pela Microsoft. Ela automati-
48
camente produz documentações de referência com comentários retirados diretamen-
te do código fonte, aproveitando os comentários em xml (eXtensible Markup Langua-
ge), gerando documentação no formato MSDN (Microsoft Developer Network que é
ferramenta on-line da Microsoft para desenvolvedores que trabalham coma Platafor-
ma Microsoft). Esta ferramenta possui uma interessante possibilidade, que é gerar a
documentação do usuário com referencias a documentação técnica [40].
KELP (open source code): O KELP é uma ferramenta utilizada para tomar notas
sobre o código fonte de arquivos de forma simples. É composto por um conjunto de
ferramentas de linha de comando em formato de arquivo de texto. Os arquivos con-
têm texto e anotações podem ser escritas usando qualquer editor de texto padrão. O
KELP possui ferramentas de recuperação de anotações e comentários que utilizam
um padrão de busca extremamente sofisticado tornando-o muito eficiente. As anota-
ções são armazenadas separadamente do código fonte que são descritas em outro
módulo [41].
Fluxograma
Visio: O Visio da Microsoft oferece uma ampla variedade de modelos — fluxogra-
mas de processo de negócios, diagramas de rede, diagramas de fluxo de trabalho,
modelos de banco de dados e diagramas de software — que você pode usar para vi-
sualizar e simplificar processos de negócios, controlar projetos e recursos, criar grá-
ficos de organizações, mapear redes, diagramar sites de construções e aperfeiçoar
sistemas [42].
Flowchart: é um serviço para criar fluxogramas com funções completas. Através de
uma interface amigável, é fácil inserir objetos e linhas, posicionando-as onde dese-
jar. Um recurso bastante interessante que Flowchart nos oferece é a possibilidade
de trabalhar com diversos usuários ao mesmo tempo em um projeto, e ainda comu-
nicar-se com eles usando mensagens instantâneas. Você ainda poderá salvar sua
criação no formato PDF ou PNG. Pode ser executado em Internet Explorer 5.x, Inter-
net Explorer 6.x, Internet Explorer 7.x, Firefox 1.x, Firefox 2 [43].
49
4.3 FERRAMENTAS LIVRES PARA MODELAGEM
No final dos anos 80 início dos anos 90 surgiu uma linguagem com objeti-
vo de unificar e padronizar a metodologia da representação gráfica de modelagem
dos projetos. Nascia ali a UML [47]. A UML é uma linguagem padrão para modela-
gem de projetos orientados a objeto. A maioria das ferramentas disponíveis para
modelagem abrange o UML. Contudo, estudantes de tecnologia, professores e até
mesmo pequenos empreendedores necessitavam de alternativas mais baratas ou
até mesmo sem custo para estudar e desenvolver a modelagem de seus projetos,
motivando assim esforços para desenvolvimento de ferramentas livres que pudes-
sem ser distribuídas sem custo e com possibilidade de desenvolvimento pelos pró-
prios usuários devido a sua natureza de código aberto. Algumas das ferramentas li-
vres hoje disponíveis possibilitam um alto nível de qualidade e produtividade che-
gando em muitos casos a fazer frente a ferramentas pagas sem nenhuma perda de
qualidade final. Existe uma série de iniciativas para geração de programas livres.
Vamos a algumas delas [17]:
Dia: [44] é um programa baseado em gtk+ para criação do diagrama, liberado sob a
licença do GPL (General Public License), (figura 4.1). É parte do projeto Gnome.
Atualmente tem objetos especiais de Lógica, entidade e relacionamento, diagramas
UML, fluxogramas, diagramas da rede, e circuitos simples entre outros. Existem
versões do Dia para Linux (GNU (GNU IS NOT UNIX)), Windows e algumas varia-
ções do Unix. Com o Dia podem ser criadas a maioria dos diagramas UML. Sua es-
trutura é simplesmente a união de componentes/objetos utilizados na modelagem
UML. Seus diagramas podem ter componentes/objetos de outras estruturas como
ER, fluxograma, rede, lógica etc.
50
Figura 4.21: Software de Modelagem dia [17].
O Dia ainda possui duas utilíssimas ferramentas para trabalhar com banco
de dados SQL, a saber: Agata (gerador de relatório) que pode gerar diagramas do
Dia através de Bases SQL e TeDia2SQL, e Dia2SQL, que Converte diagramas do
Dia para bases de dados do SQL (Sybase, PostgreSQL, oracle, DB/2, Mssql,
MySQL) [17].
ArgoUML: [45] é uma ferramenta CASE (uniformidade da notação, anteriormente
usou case) baseada na notação UML. Foi desenvolvido pela comunidade de desen-
volvedores de código livre Tigris vinculada a Universidade da Califórnia, Berkeley (fi-
gura 4.2). Sua interface é bem completa o que a torna um pouco complexa de mani-
pular. Dentre as muitas potencialidades do Argo estão: desenhar e imprimir diagra-
mas UML, gerar declarações de classes Java, exportar documentação para páginas
Web em Java, gerar arquivos gráficos, gerar comandos SQL, fornece uma estrutura
modular de engenharia reversa de classes Java, pode exportar dados para o padrão
XMI (baseado no formato XML).
51
Dentre os diagramas suportados estão: diagrama de classe, diagrama de
estados, diagrama de atividades, diagrama de casos de uso, diagramas de colabora-
ção, diagrama de utilização/componentes, diagrama de seqüência.
Como o Argo é totalmente escrito em Java, ele pode ser executado em
praticamente qualquer plataforma que suporte o JVM (Java Virtual Machine) [17].
Figura 4.22: Software de modelagem ARGO [17].
Umbrello: O Umbrello [46] é um software de modelagem UML que é integrado ao
projeto KDE (K desktop environment) (figura 4.3). Este software é utilizado para mo-
delar o próprio projeto do KDE por grande parte dos desenvolvedores que utilizam
UML. O Umbrello atualmente é recomendado para pequenos projetos. Seus desen-
volvedores vêm trabalhando para que o software tenha um suporte de desenvolvi-
mentos para médios e grandes projetos. Como o Argo, o Umbrello pode trabalhar
com uma série de digramas como: diagrama de classe, diagrama de estados, dia-
grama de atividades, diagrama de casos de uso, diagramas de colaboração, diagra-
52
ma de utilização/componentes, diagrama de seqüência. Apesar de relativamente pe-
queno, o Umbrello possui uma série de funcionalidades como: Desenhar e imprimir
diagramas UML, gerar declarações de classes Java, PHP, JavaScript, ActionScript,
C++, SQL, Ada, IDL, XMLSchema, Python,Perl e Ruby, gerar arquivos gráficos, pos-
sui ferramenta de engenharia reversa de classes, gera arquivos no padrão XMI (ba-
seado no formato XML), possui um wizard para criação de classes e para geração
de código fonte, possibilita configuração de cabeçalhos do código fonte, possui um
visualizador de Código Fonte, e também possui um recurso de refatoração (refacto-
ring) que segundo Martin Fowler significa: “Mudança interna de estrutura de um
software, que o torna mais fácil de se entender e mais barato de modificar , sem
causar alterações em seu comportamento observável”. Dentre as plataformas que
suportam o Umbrello estão: Linux (GNU (Gnu is Not UNIX)), Solaris e FreeBDS [17].
Figura 4.23: Software de modelagem Umbrello [17].
53
5 BOAS PRÁTICAS NA DOCUMENTAÇÃO DE SOFTWARE
Em seu artigo ‘A documentação de Software’ [18], o professor Paulino faz
uma pergunta extremamente relevante em nosso estudo: “Documentação. Necessi-
dade ou Preciosismo?”. Este questionamento é de suma importância em nosso estu-
do, pois é fato que a necessidade de documentação se fez presente em função do
aumento em tamanho e complexidade dos diversos tipos de projeto de software.
Nos dias de hoje, documentar bem um projeto chega a ser um ato de
“compaixão” para com aqueles que irão manter o sistema criado. Pela definição do
guia PMBOK [8]:Um projeto (português brasileiro) ou projecto (português europeu) é um esforço temporário empreen-dido para criar um produto, serviço ou resultado exclusivo. Os projetos e as operações diferem, princi -palmente, no fato de que os projetos são temporários e exclusivos, enquanto as operações são contí -nuas e repetitivas. Os projetos são normalmente autorizados como resultado de uma ou mais consi-derações estratégicas. Estas podem ser uma demanda de mercado, necessidade organizacional, soli-citação de um cliente, avanço tecnológico ou requisito legal. As principais características dos projetos são que eles são (1) temporários, possuindo um início e um fim definidos, (2) planejados, executado e controlado, (3) entregam produtos, serviços ou resultados exclusivos, (4) desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva, (5) realizados por pessoas e (6) com re-cursos limitados.
Por esta definição, um projeto é finito, mas sua manutenção pode perdu-
rar por um longo tempo. Além disso, é a documentação do sistema que vai manter
“viva a chama do sistema” que precisa ser mantido, adaptado e atualizado.
Em minha vida profissional, me especializei no desenvolvimento de
softwares de automação industrial. Não é raro deparar-me com softwares de mais
de 20 anos. Na empresa que atuo hoje, existe um grande sistema de controle de
vendas e estoque completamente desenvolvido em Clipper. Não é preciso dizer que
caso não existisse um mínimo de documentação, seria impossível manter esses
softwares.
Muitas vezes me deparo com funções repetidas, variáveis duplicadas, ro-
tinas em desuso alocadas no código do programa, tudo isso em função da não docu-
mentação, pois cada programador que trabalha sente-se incapaz de desvendar a
tempo todo o velho código que não possui documentação. Desse modo, os progra-
madores criam novas funções e variáveis deixando as antigas incrustadas na malha
do código.
54
Quando iniciei minha carreira como programador, não tinha a consciência
da necessidade de documentar. Sempre confiei em minha capacidade de lembrar
cada função e variável; o máximo que fazia era dar nomes sugestivos as variáveis
de forma a lembrar sua utilidade. Com o tempo e com a oportunidade de dar manu-
tenção em softwares desenvolvidos por outras pessoas e empresas, aliado com o
conhecimento da disponibilidade de técnicas e ferramentas de documentação, fui,
aos poucos, descobrindo esse “novo mundo” do software documentado. Percebi na
prática o aumento de minha própria produtividade e da melhoria de qualidade de
meus projetos quando usadas simples práticas de documentação.
Documentar é algo um tanto técnico, já que existem técnicas e padrões,
bem como ferramentas pré-estabelecidas, mas também depende do dom de cada
programador. Como toda prática pode ser desenvolvida com exercícios e conheci-
mento das normas e padrões, todo o profissional que julga a documentação algo te-
dioso e sem função prática, precisa revisar seus conceitos e iniciar um processo de
atualização de modo a absorver a consciência da necessidade da documentação,
bem como fazer das boas práticas de documentação algo tão natural quanto o pro-
gramar.
5.1 DOCUMENTAÇÃO DO CÓDIGO FONTE
Documentar o código fonte provavelmente é o que mais se aproxima do
trabalho do programador. A maneira mais prática de documentar o código fonte é fa-
zê-lo em conjunto com o desenvolvimento do próprio código. À medida que o desen-
volvimento vai acontecendo, a documentação vai tomando forma. É sempre impor-
tante que antes de iniciar o processo de documentação, o programador, em conjunto
com os outros membros do grupo de projetos, assuma premissas que vão nortear
esse processo. São algumas boas práticas:
Crie um padrão: Muitas vezes não é possível adotar algo previamente definido ou
um padrão genérico. Crie um padrão conhecido dos membros do projeto, e que faça
55
sentido no contexto da aplicação. Documente este padrão e o disponibilize na docu-
mentação final do projeto.
Preencha todos os campos disponíveis para documentação: Utilize todas as
possibilidades, não use “dois pesos para uma medida”, por exemplo, se um método
levanta erros preencha a “tag exception” de todos não somente de alguns.
Seja Objetivo: A objetividade é um grande trunfo, além de facilitar a execução do
trabalho de documentação, também diminui o tamanho do documento. Linhas de co-
mentários que descrevam trechos do código não necessitam ser extensas e detalha-
das. O comentário deve ser simples e deixar clara a função de cada trecho, e não
descrevê-lo por completo.
Não seja econômico: Ser objetivo não é ser econômico. Evite abreviações desne-
cessárias ou codificações que fazem sentido só para você, use frases completas e
evite uso de muitos símbolos gráficos. Use a quantidade de caracteres necessários
para fazer uma boa comunicação, nem mais nem menos.
Use o idioma mais adequado a sua audiência: Ao documentar o código de fonte
pense no projeto o que mais se identifica e principalmente quem vai precisar da do-
cumentação que você esta gerando. Só então decida que língua utilizar para docu-
mentar. Dependendo do projeto, documentações na língua nativa podem ficar sem
sentido ou perder o poder de abstração.
Enfim, como disse o professor Paulino Michelazzo em seu artigo [18] “se
estas simples linhas forem deixadas de lado, além de gerar um gasto desnecessário
de horas à procura de erros, aumenta-se o nível de estresse de todos que irão me-
xer no código e principalmente de quem paga por ele.”
56
6 CONCLUSÕES
A documentação de software é tão importante quanto o software. Ela se
torna extremamente importante com advento da globalização, já que, hoje, partes de
um programa são desenvolvidas em diversas partes do país e até do mundo. Falar
uma mesma língua de desenvolvimento e mantê-la registrada através da documen-
tação eficiente e objetiva, aumenta a produtividade dos programadores e a confiabili-
dade do software além estender a vida útil do software, tornando-o facilmente manti-
do, atualizado e reutilizável, seja quem for o mantenedor do sistema.
A comunicação é hoje a ferramenta mais eficaz em todos os seguimentos,
pois torna os produtos utilizáveis e comercializáveis em qualquer parte do mundo.
Sendo a documentação parte fundamental da comunicação entre os programadores
e desenvolvedores do mundo todo, percebe-se claramente a importância da docu-
mentação de software.
A documentação em todas as etapas do processo de desenvolvimento
possibilita ainda aos gestores dos projetos identificarem melhorias no gerenciamento
do projeto de modo a torná-lo mais rentável, além de minimizar a necessidade de
grandes estruturas de pós-venda técnicas.
A documentação não é mais preciosismo e sim uma preciosidade que
deve ser encarada como um bem de valor agregado a qualquer projeto moderno,
bem estruturado e de sucesso.
57
REFERÊNCIAS BIBLIOGRÁFICAS
1. HISTORIA DA ENGENHARIA DE SOFTWARE. Wikipédia, a enciclopédia li-
vre. <http://en.wikipedia.org/wiki/History_of_software_engineering>, Acesso
em 20/09/2008.
2. PRESSMAN, Roger S. Engenharia de Software. São Paulo : Makron, 1995.
3. XEXÉO, Geraldo. Modelagem de Sistemas de Informação: Da análise de requisitos ao modelo de interface, Rio de Janeiro, RJ, Creative Commons,
Agosto 2007, p.14-18 O desenvolvimento do software.
4. MACHADO, C. A. F., "Normas e Modelos de Maturidade," in da Rocha, A.
R. C., Maldonado, J. C., and Weber, K. C. (eds.) Qualidade de Software: Teo-
ria e Prática São Paulo: Prentice-Hall, 2001..
5. GONÇALVES, Leandro de Carvalho. Geração e uso de Base de Dados,
2002. Professor do Departamento de Computação da Universidade Federal de
São Carlos.
6. THERAC. Wikipédia, a enciclopédia livre.
<http://en.wikipedia.org/wiki/Therac_25>, Acesso em 28/09/2008.
7. PSEUDOCÓDIGO. Wikipédia, a enciclopédia livre.
<http://pt.wikipedia.org/wiki/pseudocodigo>, Acesso em 25/09/2008.
8. PMI – Project Management Institute. PMBOK – Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos. Edição 2000. New
Square, PA.: Four Campus Boulevard, 2002. cap.11, p.127-146.
9. PIGOSKI, T. M. Pratical Software Maintenance: Best Practices for Soft-
ware Investment. Wiley, 1997.
10.ALMEIDA, Rodrigo Rebouças de. Processos de desenvolvimento de software.
58
<http://rodrigor.com/_media/talks/pbjug_tech_day_processos_de_desenvolvi-
mento_de_software.pdf>, Acesso em 25/09/2008.
11.SOFTWARE ARCHITETURE DOCUMENT.
<http://www.wthreex.com/rup/examples/csports/ex_sad.htm>, Acesso em
28/09/2008
12. PHDCOMICS. <http://www.phdcomics.com/comics/archive.php?
comicid=178>, Acesso em 28/09/2008.
13.SOFTWARE DOCUMENTATION.
<http://www.uacoders.com/soft/software_documentation.html>, Acesso em
03/10/2008.
14.LUZ, Antonio da. Banco de Dados. Conceitos Básicos. ETF/Palmas -
UNED/ Paraíso.
<http://paraiso.etfto.gov.br/docente/admin/upload/docs_upload/material_f838b
95229.ppt>, Acesso em 19/09/2008.
15.GOMES, Gilene Borges, Dicionário de Dados. Questionário de Analise de Sistemas 1 – <http://www.gomeshp.com>, Acesso em 19/09/2008.
16.ALMEIDA, Raquel. Estudo do RUP – Rational Unified Process, Apresentação
TCC – UFPE, 1999 – Orientador Augusto Sampaio e Paulo Borba.
17.VIEIRA, Marcio Junior. Ferramentas Livres para UML – Palestra 7º Fórum
Internacional do Software Livre, 2006.
18.MICHELAZZO, Paulino. Artigo, A Documentação de Software. <http://imasters.uol.com.br/artigo/4371/gerencia/a_documentacao_de_softwar
e>, Acesso em 15/09/2008.
19.MELO, Lafaytte B. Análise e projeto de sistemas para Internet, 2005. Pro-
fessor do COINFO / CEFET – PB.
20.TECHNICAL DOCUMENTATION: THE HEART AND SOUL OF THE SOFT-
WARE MACHINE. <http://www.linneaco.com/techwr.html>, Acesso em
29/09/2008.
21.MICROSOFT WORD. <http://office.microsoft.com/pt-
br/word/FX100487981046.aspx>, Acesso em 28/09/2008.
22.ADOBE FRAMEMAKER. <http:// www.adobe.com/products/framemaker/>,
Acesso em 29/09/2008.
59
23.ADOBE PAGEMAKER. <http://www.adobe.com/products/pagemaker/>,
Acesso em 29/09/2008.
24.MICROSOFT PUBLISHER. <http://office.microsoft.com/pt-
br/publisher/FX100487821046.aspx>, Acesso em 28/09/2008.
25.ADOBE ILLUSTRATOR. <http://www.adobe.com/products/illustrator/>,
Acesso em 29/09/2008.
26.CORELDRAW. <http://www.corel.com.br/pt/>, Acesso em 28/09/2008.
27.ADOBE PHOTOSHOP. <http://www.adobe.com/products/photoshop/>,
Acesso em 29/09/2008.
28.ROBOHELP. <http://www.adobe.com/products/robohelp/>, Acesso em
29/09/2008.
29.SOUSA, Arthur Jorge Afonso de. Apontamentos Teóricos – Dicionário de
Dados. Escola Superior de Tecnologia de Viseu – Portugal, 2002.
<http://www.estv.ipv.pt/paginaspessoais/ajas/AS/Apontamentos%20Te
%C3%B3ricos/as_3_4.pdf>.
30.COMPONENTONE DOC-TO-HELP. <http://www.componentone.com/>,
Acesso em 29/09/2008.
31.MICROSOFT FRONTPAGE. <http://office.microsoft.com/pt-
br/help/HA100750411046.aspx>, Acesso em 28/09/2008.
32.MACROMEDIA DREAMWEAVER.
<http://www.adobe.com/products/dreamweaver/>, Acesso em 29/09/2008.
33.MACROMEDIA FLASH. <http://www.adobe.com/products/flash/>, Acesso em
29/09/2008.
34.RATIONAL ROSE. <http:// www.ibm.com/software/rational/>, Acesso em
29/09/2008.
35.ORACLE DESIGNER.
<http:// www.oracle.com/technology/products/designer/index.html>, Acesso
em 29/09/2008.
36.CA ERWIN DATA MODELER. <http://www3.ca.com/solutions/Product.aspx?
ID=260>, Acesso em 29/09/2008.
37.JUDE. <http://jude.change-vision.com/jude-web/index.html> , Acesso em
29/09/2008.
60
38.JAVADOC. <http://java.sun.com/j2se/javadoc/>, Acesso em 29/02/2008.
39.ROBODOC. Wikipédia, a enciclopédia livre.
<http://en.wikipedia.org/wiki/ROBODoc>, Acesso em 28/09/2008.
40.SANDCASTLE. <http://www.codeplex.com/Sandcastle/>, Acesso em
28/09/2008.
41.KELP. <http://sourceforge.net/projects/kelp/> , Acesso em 28/09/2008.
42.MICROSOFT VISIO. <office.microsoft.com/pt-br/vi-
sio/FX100487861046.aspx>, Acesso em 28/09/2008.
43.FLOWCHART. <http://www.flowchart.com>, Acesso em 29/09/2008.
44.DIA. <http:// www.gnome.org/projects/dia/>, Acesso em 29/09/2008.
45.ARGOUML. <http://argouml.tigris.org/>, Acesso em 29/09/2008.
46.UMBRELLO. <http://www.umbrello.org/>, Acesso em 29/09/2008.
UML. <http://www.uml.org/>, Acesso em 29/09/2008.
47.PAPEL: ARQUITETO DE SOFTWARE.
<http://www.wthreex.com/rup/process/workers/wk_archt.htm>, Acesso em
28/09/2008.
61