...

Pequeno Manual da Escrita Técnica - UFPR

by user

on
Category: Documents
2

views

Report

Comments

Transcript

Pequeno Manual da Escrita Técnica - UFPR
Universidade Federal do Paraná
Departamento de Informática
Roberto A Hexsel
Pequeno Manual da Escrita Técnica
Relatório Técnico
RT-DINF 004/2004
Curitiba, PR
2004
Pequeno Manual da Escrita Técnica
Roberto A Hexsel
Departamento de Informática
Universidade Federal do Paraná
Centro Politécnico, C Postal 19081 – 81531-990 Curitiba, PR
[email protected]
Resumo Este texto foi escrito como uma tentativa de apontar um rumo queles que estão iniciando-se como escritores, e apontar-lhes os erros mais comuns
que são cometidos por neófitos. A pretensão é tentar reduzir a quantidade de
erros cometidos pelos meus orientados, minimizando assim o tempo perdido
em revisões. Minhas razões são portanto puramente egoı́stas, mas é provável
que o resultado seja útil também a outras pessoas. Evidentemente, o estilo é
peremptório e bem de acordo com o espı́rito de um manual.
Introdução
Muito se ouve sobre a dificuldade que as pessoas tem para escrever. A dificuldade é real
porque escrever demanda esforço e trabalho. Contudo, escrever é uma habilidade que se
adquire com a prática, que se aprende. O aprendizado se inicia pela leitura de muitos
livros técnicos e artigos, e progride com o exercı́cio.
Escrever um texto que descreve uma descoberta cientı́fica ou avanço técnico é uma tarefa
tão importante quanto o trabalho propriamente dito, cujos resultados merecem ser relatados. A tarefa principal do pesquisador é executar a pesquisa, mas esta de nada adianta se
os produtos da pesquisa não forem repassados para a comunidade. Uma das maneiras mais
eficientes de distribuir os produtos e resultados das atividades de pesquisa é justamente o
texto escrito.
Os objetos de pesquisa são inerentemente complexos e sua compreensão demanda uma boa
dose de esforço por parte de quem deseja compreendê-los. O texto técnico que descreve o
produto da pesquisa deve portanto ser escrito de forma a minimizar o esforço do leitor. Isso
é importantı́ssimo por conta de vários fatores, que incluem desde limitações do número de
páginas permitido pelo veı́culo, até diferenças de cultura técnica entre escritores. Textos
técnicos devem ser precisos e concisos, e mesmo que estes atributos sejam freqüentemente
conflitantes, a precisão não deve ser sacrificada em favor da concisão.
Vários dos pontos discutidos a seguir foram adaptados de outros documentos com recomendações quanto a estilo e conteúdo. Dentre eles destacam-se o livro de Lamport
sobre LATEX [4], e textos com recomendações a potenciais autores de artigos para conferências [3, 7, 5].
O texto está organizado como descrito a seguir. A Seção 1 contém recomendações gerais
quanto ao projeto, conteúdo e organização do texto. A Seção 2 aponta falhas e erros que
ocorrem com mais freqüência nos textos avaliados pelo autor, enquanto que a Seção 3
contém algumas atrocidades, e indicações de como evitá-las.
1
Pequeno Manual da Escrita Técnica
1
2
Projeto do Texto
Escrever textos técnicos é uma atividade muito trabalhosa e que demanda uma quantidade
enorme de tempo e esforço mental. Reserve tempo e prepare-se com bastante antecedência.
Estude com cuidado o tipo de texto que irá produzir. Prepare de antemão todo o material
necessário para ilustrar o texto, tal como gráficos, figuras e bibliografia.
1.1
Esqueleto
Defina o enfoque e a estrutura do texto. O texto é um artigo cientı́fico, manual, texto
informativo, ou um tutorial? Qual é o enfoque do texto? Ele é descritivo, informativo, de
nı́vel avançado ou introdutório? Dependendo do enfoque, mais ou menos espaço deve ser
reservado para material introdutório.
Esboce um projeto de seu texto, determinando quais e quantas seções o texto conterá.
Para cada subtı́tulo, determine o conteúdo e tamanho (número de linhas ou parágrafos).
As seções devem mostrar a seqüência lógica dos componentes do texto. Isso feito, escreva
o esqueleto do texto.
Qualquer processador de textos decente permite a construção de um ı́ndice ou sumário
com um mı́nimo de esforço. Use esta facilidade para verificar se o esqueleto de seu texto
foi bem projetado, se o seqüenciamento dos tópicos está adequado e se o aninhamento das
seções e sub-seções faz sentido.
Quais serão, e onde se situarão no texto, as figuras ou gráficos ou tabelas que contém as
informações mais relevantes do trabalho? Em seções introdutórias, use figuras e diagramas
para ilustrar os conceitos e definições, na medida em que são introduzidos.
Quais serão as referências? Como regra geral, devem ser usadas referências recentes dentre
os melhores livros e periódicos na sua área de pesquisa, embora algumas das contribuições
mais importantes possam estar em passado mais ou menos distante. Use referências fáceis
de encontrar, e na medida do possı́vel, evite relatórios técnicos, e não use publicidade. Documentos disponı́veis na Internet tendem a ser efêmeros, e portanto deveriam ser evitados.
Se isso não for possı́vel, as referências àqueles devem conter a data na qual o documento
foi acessado.
Revise o projeto do texto.
O quê o autor deseja que leitor aprenda ao ler o texto? O quê o leitor aprenderá no texto?
As respostas a estas perguntas devem ser claramente respondidas antes de que o autor
inicie a preparação do texto.
Revise o projeto do texto. Várias vezes.
1.2
Seções Introdutórias
Uma seção introdutória tem a função indicada pelo seu nome que é introduzir o material
que vai ser apresentado em mais detalhe nas seções subseqüentes. O(s) problema(s) são
descritos e contextualizados, as idéias associadas à(s) solução(ões) são apresentadas. Estas
seções apenas descrevem o problema e possı́veis soluções, tratando apenas do o quê e do
porquê, e nunca do como.
Pequeno Manual da Escrita Técnica
3
Em se tratando de artigo cientı́fico ou tese, é importante ter em mente o objetivo da
Introdução, que é contextualizar o problema, e mostrar porque vale a pena resolvê-lo. A
solução proposta deve ser apresentada e suas qualidades relativas com relação às demais
soluções já publicadas devem ser enfatizadas. A Introdução deve capturar a atenção do
leitor ao mostrar as boas qualidades do trabalho.
1.3
Seções Intermediárias
Estas seções retomam o apresentado nas seções introdutórias e acrescentam tantos detalhes
quanto necessário para a compreensão do exposto no restante do texto. Isso inclui a definição precisa e formalização das idéias, conceitos e modelos empregados nas explanações.
As seções iniciam pela descrição do seu conteúdo (o que da seção), seguido por todas
as definições necessárias (o que detalhado e o porquê da seção), só então seguido dos
detalhes dos problema e da solução (o como). A seção pode terminar com um parágrafo
de conexão para a seção seguinte.
Se o trabalho se baseia em algum modelo conceitual, este deve ser claramente definido e
suas limitações explicitadas. Um diagrama equivale a mil parágrafos de texto confuso. Use
o diagrama como uma ferramenta: ao descrevê-lo, certifique-se de que todo o texto está
coerente e que há uma correspondência estrita entre o texto e o conteúdo do diagrama.
A princı́pio, quanto maior a complexidade do modelo, maior o número de diagramas para
descrevê-lo.
1.4
Seções com Resultados
Estas seções descrevem os resultados propriamente ditos. As seções iniciam descrevendo os
experimentos, técnicas ou teoremas e explicando por que estes são relevantes, bem como o
que se aprendeu com os experimentos ou soluções. Os resultados são então apresentados e
discutidos. A relevância e originalidade devem ser enfatizados aqui, bem como possı́veis
limitações, melhorias e desenvolvimentos.
Os resultados devem ser apresentados de forma que os experimentos possam ser repetidos
e verificados por outras pessoas com mesmo grau de capacitação que o autor.
1.5
Seção Conclusiva
Descreva novamente o contexto do trabalho. Defina o problema e explique sua relevância
e grau de dificuldade da(s) solução(ões) existente(s). Esta definição pode ser tecnicamente
densa e empregar todos os conceitos já introduzidos. Apresente sua solução ou resultados
e discuta seus méritos e defeitos, além de possibilidades e desenvolvimentos futuros.
Na Conclusão nunca, mas nunca mesmo, podem ser apresentadas conclusões que não
tenham sido discutidas nas seções anteriores. Não podem haver surpresas na Conclusão!
Pequeno Manual da Escrita Técnica
1.6
4
Resumo
Existem duas maneiras de se escrever o resumo, antes ou depois do texto propriamente
dito. No primeiro caso, inicia-se pelo resumo, que em um parágrafo aponta todos os
aspectos importantes relativos ao problema e sua contextualização, e quanto a solução
proposta. Isso feito, o texto completo é produzido a seguir. No segundo caso, escreve-se
o texto completo e seus pontos mais importantes são então sintetizados no parágrafo do
resumo. O resumo tem a função de despertar a curiosidade do leitor e deve portanto ser
escrito com muito cuidado.
Leitores com alguma prática decidem se o texto completo vale a pena ser lido após lerem
o resumo, a introdução e a conclusão. Isso significa que estas seções devem ser escritas
para convencer o leitor da qualidade e originalidade do que é reportado no texto.
2
Estilo
Textos técnicos devem ser claros, mas principal e especialmente, precisos. Isso significa
que uma certa dose de repetição é necessária embora a qualidade lı́rica e a métrica fiquem
um tanto prejudicadas. O objetivo principal é transmitir um certo conjunto de idéias de
forma precisa, clara, concisa e sem ambigüidade.
Textos técnicos tendem a ser enfadonhos por sua própria natureza, mas existem exceções.
Representativos dentre meus prediletos são os livros de Halmos, Hennessy & Patterson, e
Peterson & Davie [1, 2, 6].
Observe as recomendações ou normas quanto a tamanho dos caracteres, margens, tı́tulos
e seções. Use um processador de textos que não tenha idéias próprias sobre a formatação
do texto, ou que mude de idéia a cada seção.
Evite órfãos, que são (a) uma única palavra na última linha de um parágrafo, (b) uma
única linha no topo de uma página, (c) um só parágrafo em uma seção, ou (d) uma única
subseção de uma seção. Não separe um (sub-)tı́tulo do texto que o segue porque um tı́tulo
no final de uma página deve ser seguido de algumas linhas de texto.
Toda vez que um termo técnico for introduzido e definido, o termo deve ser enfatizado
para sinalizar ao leitor quanto a sua importância. O parágrafo acima que define “órfãos”
é um exemplo desta prática. Em geral, tipos como itálico ou enfatizado tem um efeito
mais agradável do que negrito.
Gráficos devem conter os nomes dos eixos, abscissas e ordenadas. Evite gráficos pseudotridimensionais com colunas de 3 dimensões aos invés de barras simples. A pseudodimensão tem somente efeito cosmético e não acrescenta informação à figura. Evite gráficos
esparsos (poucas linhas) ou congestionados (muitas linhas).
O tı́tulo de uma (sub)seção pode, ou deve, ser repetido na primeira frase da seção, ao
invés de ser omitido porque estaria implı́cito pela proximidade ao tı́tulo.
Pequeno Manual da Escrita Técnica
5
Segue uma lista de recomendações quanto a erros freqüentes e alguns vı́cios, também
comuns. Os itens são numerados para facilitar referências a eles.
1. O texto deve ser compilável da mesma forma que um programa: nunca use um objeto sem que ele tenha sido definido anteriormente; se necessário, faça uma referência
para uma definição apresentada adiante.
2. Em função do enfoque do texto, algumas definições podem ser omitidas, desde que
elas sejam obviamente conhecidas da grande maioria dos possı́veis leitores. Na
dúvida, aponte para uma referência bibliográfica.
3. Não use definições por exemplo, nas quais um exemplo contém a definição de um
conceito ou termo. Primeiro defina e então dê um ou mais exemplos. Note que esta
é uma definição por exemplo.
4. Nunca introduza um termo pela sua abreviatura. A maneira correta é: A rede
padrão Fiber Distributed Data Interface (FDDI) é ... A FDDI interconecta ...
5. Use termos e abreviaturas consistentemente ao longo de todo o texto.
6. Evite anglicismos. Use uma expressão que melhor traduza O SENTIDO da expressão
em Inglês e cite o termo original entre parênteses, entre aspas ou em itálico (in
English ou “in English”).
7. Nomes próprios, em geral, não necessitam ser traduzidos (protocolos, interfaces padronizadas, etc).
8. Evite frases de aluno de primeiro grau, muito curtas ou infinitamente longas, e use
vocabulário de adulto.
9. O estilo do Hino Nacional é aceitável em poesia mas é ininteligı́vel para uma parcela
enorme da população, e portanto não deve ser usado em textos técnicos de Computação. Geralmente, frases no estilo do Hino Nacional decorrem da confusão do
autor enquanto as elabora, quando novas idéias lhe ocorrem e são imediatamente
inseridas no texto. O indefeso leitor é então obrigado a tentar seguir o tortuoso
fluxo de idéias do autor.
10. Como regra geral, textos técnicos devem ser escritos na voz passiva e no presente.
Voz passiva: O arquivo deve conter as seguintes informações...
O programa efetua as operações na ordem especificada em...
A implementação do protocolo examina os campos da mensagem e então...
Voz ativa: Devemos colocar as seguintes informações no arquivo...
As operações deverão ser efetuadas pelo programa...
O protocolo deverá examinar...
11. Ao inserir referências bibliográficas no texto, sempre que possı́vel tente colocar a
citação [Ruim00] em um ponto da frase que não interrompa o fluxo do texto [Bom00].
Na frase anterior, a primeira citação atrapalha a leitura e acrescenta pouco conteúdo
semântico. Em geral, é melhor empurrar a citação para o final da frase onde ela atrapalhará menos, embora isso nem sempre seja possı́vel. Se a citação causar dificuldade
de compreensão da frase, ela deve ser movida para um ponto no qual atrapalhe menos, mas sem desvincular a idéia de seu autor.
Pequeno Manual da Escrita Técnica
6
12. Ao descrever um programa, algoritmo ou método, tome muito cuidado para manter claramente separada a parte que descreve o quê da parte que descreve como.
Primeiro explique claramente “o que faz” sem nenhuma referência à implementação.
Somente após a descrição “do quê” é que se pode mostrar “como é feito”.
Se seu texto fala sobre Lex e Yacc, por exemplo, a descrição deve iniciar com
(a) “compilador de compiladores”, (b) análise e sı́ntese de código, (c) como Lex
e Yacc se relacionam, (d) o que Lex faz, (e) o que Yacc faz, (f) como os dois são
usados na sua aplicação. A parte mais importante é obviamente (f). Seu esforço ao
escrever esta parte, e o do leitor ao ler, será muito menor se as partes introdutórias
[(a) até (e)] estiverem bem estruturadas e contiverem todas as definições necessárias.
13. Na medida do possı́vel, evite listas iniciadas com dois pontos. Contra exemplo: uma
coisa, outra coisa, uma terceira coisa. Se a lista é realmente necessária, enumere os
itens: (a) uma coisa, (b) outra coisa, e (c) última coisa.
Se for necessário empregar uma lista de itens (“buletada”), os itens deveriam ficar
todos na mesma página, e cada item deve ocupar uma linha. Se os itens forem
longos, possivelmente uma separação em vários parágrafos resulta em layout que é
visualmente mais agradável. Note que esta lista é um contra exemplo.
IMPORTANTE Após escrever cada parágrafo, volte atrás e re-leia em voz alta o que
escreveu. Preste atenção no que você fala e observe se as sentenças fazem sentido. Após
escrever cada seção, volte atrás e verifique o encadeamento das idéias e descrições. Se
encontrar alguma frase solta, ou acrescente mais texto para contextualizá-la, ou mova-a
para o lugar apropriado. /dev/null geralmente é um bom lugar para prender idéias soltas.
Use e abuse de figuras para ilustrar seu texto. Uma figura equivale a 1K palavras. As
figuras são grandes e claras? O texto que acompanha a figura/tabela a explica completamente? É possı́vel diferenciar as várias linhas no gráfico? As linhas estão identificadas?
As tabelas são auto-explicativas? Na medida do possı́vel, o texto que descreve uma figura
ou diagrama deve anteceder o objeto descrito na ordem de leitura e no papel. As figuras
e diagramas devem ser completamente descritos no texto. As figuras, diagramas e tabelas
devem ser referenciadas no texto, caso contrário, elas podem ser movidas para /dev/null.
Leia o que escreveu! Leia em voz alta. Peça ajuda a alguém porque depois da décima
revisão, você possivelmente estará cansado demais para perceber os problemas, enquanto
o texto será lido com mais atenção por alguém que nunca o leu.
3
Bestiário
Exemplos que não devem ser seguidos. O tom dos comentários é um tanto sarcástico
porque estes exemplos foram produzidos por pessoas com curso superior (quase) completo.
Esta lista é numerada para que seus elementos possam ser referenciados por número,
simplificando o trabalho de apontar eventuais erros aos seus autores.
i. Este trabalho assume que X é o mesmo que Y...
Suponho que o autor quer dizer que seu trabalho pressupõe, considera, ou admite
que “X é o mesmo que Y”. Ou será que o trabalho vai assumir alguma outra
Pequeno Manual da Escrita Técnica
7
identidade, tal como faz o Super Homem? Cuidado com traduções erradas do Inglês:
assumption é presunção! Table entry é “elemento da tabela” e não “entrada na
tabela”. Performance é ‘desempenho’.
ii. O programa roda...
Programas são executados ou interpretados. Quem roda são as rodas.
iii. A Figura abaixo descreve...
Figuras não descrevem. Elas mostram, indicam, ilustram, equivalem a, e talvez
substituam 1024 palavras. Quem descreve é o autor.
iv. Estas expressões são freqüentes em trabalhos sobre avaliação de desempenho. Todas
são cacófonos pavorosos:
•
•
•
•
•
aumento no gargalo
[o autor teria bebido demais?];
cai com o aumento – inversamente proporcional?
decresce com o aumento – inversamente proporcional?
adicionar ao incremento – proporcional, com derivada positiva?
diminuição do incremento – derivada negativa?
v. As palavras abaixo não são sinônimos:
•
•
•
•
•
•
•
•
•
esquema;
modelo;
método;
polı́tica;
mecanismo;
metodologia;
algoritmo;
implementação; e
arquitetura.
vi. Expressões e frases hilárias:
• por cada [indefectı́vel auto-referência];
• O aumento da população de usuários em tamanho... [supõe-se todos os usuários
estão se alimentando adequadamente];
• serviço de coleção de erros do processador [possivelmente trata-se de uma
divisão da Intel];
• A métrica composta do TPC-H, o significado da energia e taxa de throughput,
tem uma razão de 88% em relação a Sun... [plágio do StarTrek];
• no inı́cio de um texto: A Terra, tecnicamente chamada de superfı́cie terrestre, tem sobre ela fatos observáveis - coisas. ... [no final do mesmo texto:] O
fenômeno, a interpretação do fato, a coisa no conceito objeto precisa ser disponibilizado e manipulado [erm...].
vii. Use Português corretamente. Pecados comuns são listados abaixo.
• Muito cuidado com concordância. Todas as suas formas.
• Não inicie sentença com conectivo. Contra exemplos: E a rede interliga... Mas a
interface...
Pequeno Manual da Escrita Técnica
8
• Não inicie a segunda frase com um verbo porque o sujeito está implı́cito na
primeira frase. FHC fala desta maneira mas este não é um exemplo que mereça
ser seguido: ...algo sobre X. É a modernidade chegando à produção de X.
viii. Ondismo – Uso inadequado de onde no lugar de ‘quando’, “no qual”, “em que”.
ix. Gerundismo – Uso do gerúndio em tı́tulos de seções (Escrevendo programas ou
Configurando o sistema). Estes tı́tulos são tı́picos de livros da série For Dummies,
o que já é razão suficiente para evitá-los.
x. Isto é – Uso inadequado de isto é em duas situações freqüentes. Na primeira, o isto é
tem função disjuntiva porque o autor descobriu ou elaborou nova e melhor definição
para o que escreveu à esquerda do isto é e ficou com preguiça de re-escrever a frase
toda. Na segunda situação, o isto é tem função conjuntiva porque o lado direito do
isto é acrescenta informação ao que consta no lado esquerdo. Nos dois casos, a frase
deve ser re-escrita e o isto é eliminado.
xi. Não-algo – Uso incorreto e preguiçoso do não à frente a uma palavra, geralmente
no objeto da frase, ao invés da palavra correta. Exemplos: a não necessidade (prescinde?), a não entrega (descumprimento do prazo, desobrigação, incompetência?).
xii. Foi feito – Uso indevido de linguagem coloquial, e de verbo auxiliar. Exemplo: O
monitor X é uma ferramenta gráfica que foi feita em Java.... Uma ferramenta pode
ser codificada, ou escrita, em Java.
xiii. Paroquialismo – Quando um sistema é implementado em uma certa plataforma,
o autor tende a prender-se àquela plataforma, implicitamente reduzindo o escopo de
utilização àquele ambiente. Note que isso é diferente da descrição de detalhes que
são fundamentais ao sistema.
3.1
Maus Exemplos
Exemplos a serem evitados mas que ocorrem com dolorosa freqüência. Para cada um dos
exemplos, o texto original é apresentado, os pecados nele contidos são apontados, e uma
versão melhorada é então apresentada.
Mau Exemplo I
Original
Largura de Banda
Esta é a métrica mais comum. Refere-se à taxa de dados na qual um link pode propagar
informação [citações]. Os valores são expressos em bits por segundo, ou bps abreviado, ou
Kbps, Mbps e Gbps abreviando Kilobits por segundo, Megabits por segundo e Gigabits
por segundo.
Pecados
Frases com sujeito implı́cito (Esta... Refere-se...). Uso de anglicismo (link). Confusão na
definição da unidade e suas abreviaturas. A primeira frase omite seu sujeito porque aquele
aparece no tı́tulo da seção.
Melhor
Largura de Banda
A Largura de Banda é a taxa na qual um enlace pode transportar dados, e é a métrica
de uso mais comum. A unidade da largura de banda é bits por segundo, ou bps. As
Pequeno Manual da Escrita Técnica
9
taxas tipicamente usadas são as potências de dez Kilo-, Mega- e Giga-bits por segundo,
abreviadas por Kbps, Mbps ou Gbps, respectivamente.
Mau Exemplo II
Original
O segundo desafio diz respeito à decisão quanto aos dados que caracterizam um atendimento, que deveriam, portanto, ser capturados, e às funcionalidades do sistema para o
profissional que o alimenta, de forma a possibilitar uma maior proximidade entre o sistema
e a forma como se dá o processo de trabalho numa unidade de saúde.
Pecados
Frase muito longa, e, com, quatro vı́rgulas, separando, sete palavras. Aparentemente, o
fluxo do texto foi interrompido pelas mudanças de idéia do autor no momento em que
escrevia a frase, demonstrando a Sı́ndrome do Hino Nacional.
Melhor
O segundo desafio está relacionado a dois fatores, que são o conjunto de dados que deveriam
ser capturados, e às funcionalidades do sistema. A escolha de quais dados são necessários
para caracterizar um atendimento não é tarefa simples porque sua coleta interfere no
próprio atendimento, mas deseja-se que o máximo de informações disponı́veis seja coletado.
As funcionalidades do sistema devem ser tais que aproximem a utilização do sistema do
processo de trabalho em uma unidade de saúde.
Mau Exemplo III
Original
Este protótipo foi construı́do em madeira pelos seguintes motivos: facilidade de manipulação, baixo custo e a não necessidade mão-de-obra especializada nem máquinas pesadas
para sua montagem, podendo ser trabalhada artesanalmente.
Pecados
A não necessidade significa prescinde, sujeito (protótipo) muito distante do advérbio (podendo...). Erro de concordância entre sujeito e trabalhada.
Melhor
A correção desta frase fica como exercı́cio para o leitor.
Mau Exemplo IV
Original
O primeiro passo foi o desenvolvimento de um simulador que foi feito através da replicação
do código, onde cada réplica continua a ser um processador igual ao original.
Melhor
A correção desta frase também é um exercı́cio para o leitor.
Agradecimentos
Agradeço a Cristina D Murta e a Tânia Marra pelas correções e sugestões. Agradeço
também a alguns incautos colaboradores, cujas produções motivaram este texto e o ilustram.
Pequeno Manual da Escrita Técnica
10
Referências
[1] Paul R Halmos. Naive Set Theory. Springer-Verlag, 1960. ISBN 038790092-6.
[2] John L Hennessy and David A Patterson. Computer Architecture: A Quantitative
Approach. Morgan Kaufmann, 3rd edition, 2003. ISBN 1-55860-724-2.
[3] Jim Kajiya. How to Get Your SIGGRAPH Paper Rejected. ACM SIGGRAPH 93, 1993.
www.siggraph.org/publications/instructions/rejected.html (em 24nov03).
[4] Leslie Lamport. LATEX: A Document Preparation System. Addison-Wesley, 1986. ISBN
020115790-X.
[5] Roy Levin and David D Redell. An evaluation of the ninth SOSP submissions, or
how (and how not) to write a good systems paper. ACM SIGOPS Operating Systems
Review, 17(3):35–40, July 1983. www.usenix.org/events/samples/submit/advice.
html (em 24nov03).
[6] Larry L Peterson and Bruce S Davie. Computer Networks: A Systems Approach.
Morgan Kaufmann, 2nd edition, 2000. ISBN 155860514-2.
[7] Alan J Smith. The Task of the Referee. IEEE, 1990. www.computer.org/tpds/
taskofreferee.html (em 03mar04).
Fly UP