Implementação de Código e Padrões de Organização

Prévia do material em texto

Codificaçação (IMPLEMENTAÇÃO)
“Implementação é o processo de converter o projeto detalhado em código.
Quando isso é feito por um único indivíduo, o processo é relativamente bem
compreendido. Porém, hoje em dia, a maioria dos produtos são muito
grandes para serem implementados por apenas um programador dentro das
restrições de tempo. Em vez disso, o produto é implementado por uma
equipe, com todos trabalhando ao mesmo tempo em diferentes componentes
do produto.”
Ainda que um projeto bem elaborado facilite sobremaneira a implementação, essa tarefa não é necessariamente fácil. Muitas vezes, os projetistas não conhecem em detalhes a plataforma de implementação e, portanto, não são capazes de (ou não desejam) chegar a um projeto algorítmico passível de implementação direta. Além disso, questões relacionadas à legibilidade, alterabilidade e reutilização têm de ser levadas em conta.
Deve-se considerar, ainda que, programadores, geralmente, trabalham em equipe, necessitando integrar, testar e alterar código produzido por outros. Assim, é muito importante que haja padrões organizacionais para a fase de implementação. Esses padrões devem ser seguidos por todos os programadores e devem estabelecer, dentre outros, padrões de nomenclatura, formato de cabeçalhos de programas e formato de comentários, recuos e espaçamento, de modo que o código e a documentação a ele associada sejam claros para quaisquer membros da organização.
var
 
otimo
, bom, regular, ruim, 
sem_resp
, idade, soma, total, pessoas : inteiro
pessimo
, 
percen
 : real
opniao
 : caractere
Inicio
para pessoas de 1 até 100 faça 
escreva "Digite sua idade"
leia idade
escreva "Digite sua 
opnião
", ,"A : 
Otimo
", , "B : Bom", ,"C : regular", ,"D : Ruim", ,"E : Péssimo", ,"F : não quis responder"
leia 
opniao
caso 
opniao
 
seja "A", "a" faça 
otimo
 <- 
otimo
 +1
seja "B", "b" faça bom <- bom +1
seja "C", "c" faça regular <- 
reguar
+1
seja "D", "d" faça ruim <- ruim +1
soma <- soma+ idade
media <- soma/ruim
seja "E", "e" faça 
pessimo
 <- 
pessimo
 +1
seja "F", "f" faça 
sem_resp
 <- 
sem_resp
 +1
senão 
escreva "Não existe essa alternativa, digite uma 
letra
 válida"
fim caso
fim para
total <_ 
otimo
+bom+regular+ruim+
pessimo
escreva "Quantidade de respostas 
ótimo
", 
otimo
percen
 <_ (bom+regular)*100/total
escreva "O percentual total de respostas bom e regular é", 
percen
, "%"
escreva A média de idade das pessoas que responderam ruim é", media
pessimo
<- 
pessimo
 *100/total
escreva "O percentual de respostas péssimo é ", 
pessimo
, "%"
escreva "Total de respondentes é", total
fim.linguagem pascalUm código péssimo:
Dados estatísticos mostram que de 47% a 62% do tempo gasto em manutenção de sistemas é despendido na tentativa de entender os aplicativos, e que ler código fonte, custa 3,5 vezes mais do que ler a documentação.
53% dos defeitos são descobertos em trechos tidos como corretos;
10% dos defeitos é de lógica;
79% dos defeitos são causados por entendimento incorreto.
Padrões para cabeçalho, por exemplo, podem informar o que o código (programa, módulo ou componente) faz, quem o escreveu, como ele se encaixa no projeto geral do sistema, quando foi
escrito e revisado, apoios para teste, entrada e saída esperadas etc. Essas informações são de grande valia para a integração, testes, manutenção e reutilização.
Além dos comentários feitos no cabeçalho dos programas, comentários adicionais ao longo do código são também importantes, ajudando a compreender como o componente é implementado. Por fim, o uso de nomes significativos para variáveis, indicando sua utilização e significado, é imprescindível, bem como o uso adequado de recuo e espaçamento entre linhas de código, que ajudam a visualizar a estrutura de controle do programa.
Exemplo de código comentado e documentado:
<?
php
//! Import the necessary classes
require_once
( "
AdminBase.interface.php
." );
require_once
( "
Storage.class.php
." );
/**
* Created on 01/01/2006
*
* Class that contains the methods that will 
* define rule business-oriented of application
* 
* @author 
SeuNome
 (seu.email@email.com.br)
* @version 1.0.0
*
*/
class Admin extends Storage implements 
AdminBase
{
var
 $name;
var
 $pass;
/**
* Request an instance of data base
* @return $storage Resource Id 
*/
public function 
getInstance
()
{
$storage = new Storage();
return $storage;
}
} 
//class
?>
Além da documentação interna, escrita no próprio código, é importante que o código de um sistema possua também uma documentação externa, incluindo uma visão geral dos componentes do sistema, grupos de componentes e da inter-relação entre eles.
Ainda que padrões sejam muito importantes, deve-se ressaltar que a correspondência entre os componentes do projeto e o código é fundamental, caracterizando-se como a mais importante questão a ser tratada. O projeto é o guia para a implementação, ainda que o programador deva ter certa flexibilidade para implementá-lo como código.
Como resultado de uma implementação bem-sucedida, as unidades de software devem ser codificadas e critérios de verificação das mesmas devem ser definidos.
Um exemplo de documentação externa:
Teste do Produto
O teste de produtos de software envolve basicamente cinco etapas:
planejamento de testes,
projeto de casos de teste,
implementação de testes,
execução
avaliação dos resultados 
Essas atividades devem ser desenvolvidas ao longo do próprio processo de desenvolvimento de software, e em geral, concretizam-se em três fases de teste:
de unidade,
de integração
de sistema.
O teste de unidade concentra esforços na menor unidade do projeto de software, ou seja, procura identificar erros de lógica e de implementação em cada módulo do software, separadamente.
O teste de integração é uma atividade sistemática aplicada durante a integração da estrutura do programa visando a descobrir erros associados às interfaces entre os módulos; o objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto.
O teste de sistema, realizado após a integração do sistema, visa a identificar erros de funções e características de desempenho que não estejam de acordo com a especificação [1]. 
Bibliografia
Codificação (implementação)
Engenharia de Software, prof. Ricardo Falbo, UFES, Departamento de Informática.
Engenharia de Software, livro, Roger Pressman, 2006.
Internet – 06-03-12 10:15
Testes
R. S. Pressman. Software Engineering - A Practitioner’s Approach. McGraw-Hill, 4th edition, 1997. 
J. C. Maldonado. Critérios Potenciais Usos: Uma Contribuição ao Teste Estrutural de 
Software. PhD thesis, DCA/FEE/UNICAMP, Campinas, SP, July 1991. 
G. J. Myers. The Art of Software Testing. Wiley, New York, 1979. 
B. Beizer. Software Testing Techniques. Van Nostrand Reinhold Company, New York, 
2nd edition, 1990.
Internet – 06-03-12 09:12