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