0
ORGANIZAÇÃO SETE DE SETEMBRO DE CULTURA E ENSINO
FACULDADE SETE DE SETEMBRO - FASETE
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
CLEILSON SANTANA GOMES
UM ESTUDO COMPARATIVO SOBRE A
EFICÁCIA DA PROGRAMAÇÃO INTUITIVA
PAULO AFONSO – BAHIA
JULHO - 2008
1
CLEILSON SANTANA GOMES
UM ESTUDO COMPARATIVO SOBRE A
EFICÁCIA DA PROGRAMAÇÃO INTUITIVA
Monografia apresentada ao curso
de graduação em Sistemas de
Informação da Faculdade Sete de
Setembro
–
FASETE,
como
requisito para obtenção do título de
Bacharel
em
Sistemas
de
Informação, sob a orientação do
professor Alberto César C. França.
PAULO AFONSO – BAHIA
JULHO - 2008
2
DEDICATÓRIA
Dedico este trabalho primeiramente a Deus, pois sem
ele, nada seria possível.
Em especial aos meus pais, irmãs e sobrinhos, ao meu
amor, Nayane Santos, pelo esforço, dedicação e
compreensão, em todos os momentos desta e de outras
caminhadas.
3
AGRADECIMENTOS
A Deus, aos meus pais, Marlene Santana Gomes e João Batista Gomes, a
minha família e a minha noiva Nayane Santos e sua família, agradeço
eternamente com todo amor possível.
Ao professor César França, pelo apoio, orientação, incentivo, confiança,
paciência, compreensão, deste trabalho o que me levou a um grande
enriquecimento profissional e intelectual. Bem como, aos professores: Igor
Medeiros, Juliana Motta, Ricardo Azevedo, Ryan, Leobson, Síllas Félix,
Marcília, Wendell Veras, entre tantos, que agradeço por estarem comigo
nesses 4(quatro) anos, onde puderam me dar um melhor encaminhamento no
curso.
Aos colegas de trabalho, Rodrigo Fonseca, Mardo David, Kennedy Noia,
Fabiano Vaz, Marcus Carneiro, Emmanuel Monteiro e toda equipe da
Assessoria de informática, em especial Verlânio Gallindo, por terem colaborado
neste processo.
Agradecimentos especiais aos amigos e colegas (alunos) do curso de Sistemas
de Informação que contribuíram direta ou indiretamente com a minha formação.
Não poderia deixar de agradecer a todos que fazem a Freire Informática LTDA
e Softwell Solutions, em especial à: Wellington Freire, Wedson Freire, Cláudio
Oliveira,Thiago Costa, Iuri Souza e Silvia Uchoa.
4
RESUMO
Com o crescimento do mercado de desenvolvimento de software e o alto grau
de competitividade entre as empresas, procura-se maneiras de entregar
produtos de qualidade no mínimo tempo possível, e para se obter isto existem
diversos fatores que podem influênciar, tendo como um dos principais a
tecnologia adotada. O que quando não há a escolha certa, pode gerar dentre
outros problemas, altos custos de manutenção e barreiras para atender ao
cronograma de desenvolvimento. Software é um dos principais componentes
de muitas organizações, sendo assim, é importante que sejam confiáveis,
seguros e flexíveis. Esse estudo visa levantar informações que possam
despertar o interesse dos profissionais de TIC, buscando meios de tornar o
desenvolvimento de software mais intuitivo (de alto nível). Por fim, é realizado
experimento comparativo entre os paradigmas Procedural, Orientado a Objetos
e Programação Intuitiva, a fim de verificar a produtividade e as vantagens
competitivas em termos de custo de tempo do desenvolvimento de soluções.
Categorias: Paradigmas de Programação, engenharia de software,
produtividade de software.
Palavras-chave: Programação Intuitiva, desenvolvimento de software.
5
ABSTRACT
With the growth of the market for software development and high degree of
competition between companies, is looking for ways to deliver quality products
of the least time possible, and to achieve this there are several factors that can
influence, and as one of the main technology adopted. What if there is the right
choice, can generate among other problems, high maintenance costs and
barriers to meet the schedule of development. Software is a key component of
many organizations, so it should be reliable, secure and flexible. The study aims
to raise information that may arouse the interest of the TIC professionals,
seeking ways to make software development more intuitive (high level). Finally,
comparative experiment is performed between the paradigms Procedural, the
Object Oriented Programming and Intuitiva to verify the performance and
competitive advantages in terms of time cost of the development of solutions.
Category: Paradigms of programming, software engineering, productivity
software.
Keywords: Intuitive programming, software development.
6
SUMÁRIO
CAPÍTULO 1 .................................................................................................... 12
INTRODUÇÃO ................................................................................................. 12
1.1 CONSIDERAÇÕES INICIAIS ................................................................. 13
1.2 OBJETIVOS............................................................................................ 15
1.2.1 GERAL ............................................................................................. 16
1.2.2 ESPECÍFICOS ................................................................................. 16
1.3 ESTRUTURA DO TRABALHO ............................................................... 16
CAPÍTULO 2 .................................................................................................... 17
REFERENCIAL TEÓRICO............................................................................... 17
2.1 PARADIGMAS DE PROGRAMAÇÃO .................................................... 18
2.1.1 DEFINIÇÃO...................................................................................... 18
2.1.2 PARADIGMA PROCEDURAL OU IMPERATIVO............................. 19
2.1.3 PARADIGMA ORIENTADO A OBJETOS ........................................ 19
2.1.4 COMPARAÇÃO ENTRE OS PARADIGMAS ................................... 21
2.2 PROGRAMAÇÃO INTUITIVA................................................................. 25
2.2.1 DEFINIÇÃO...................................................................................... 25
2.2.2 USO DE FLUXOGRAMAS PARA TORNAR A PROGRAMAÇÃO
MAIS INTUITIVA ....................................................................................... 26
2.3 OUTROS ESTILOS DE PROGRAMAÇÃO............................................. 31
2.3.1 LINGUAGEM DE DOMÍNIO ESPECÍFICO ...................................... 31
2.3.2 LINGUAGEM NATURAL CONTROLADA ........................................ 33
2.4 PRODUTIVIDADE DE SOFTWARE ....................................................... 34
2.5 FRAMEWORK PARA PRODUTIVIDADE ............................................... 37
2.5.1 CAKEPHP ........................................................................................ 37
2.5.2 JPA/NETBEANS .............................................................................. 38
2.5.3 MAKER ............................................................................................ 38
CAPÍTULO 3 .................................................................................................... 40
ASPECTOS METODOLÓGICOS .................................................................... 40
3. METODOLOGIA ....................................................................................... 41
3.1 DELIMITAÇÃO DA PESQUISA........................................................... 42
7
3.2 COLETA DE DADOS .......................................................................... 42
3.3 FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO DOS
SOFTWARES ........................................................................................... 42
3.4 HARDWARE E SISTEMA OPERACIONAL UTILIZADO..................... 43
CAPÍTULO 4 .................................................................................................... 44
APRESENTAÇÃO E INTERPRETAÇÃO DOS DADOS ................................. 44
4.1 RESULTADO DO EXPERIMENTO REALIZADO COMPARANDO AS
LINGUAGENS DE PROGRAMAÇÃO PROPOSTAS ATRAVÉS DE UMA
ANÁLISE QUALITATIVA .............................................................................. 45
4.2 ANÁLISE DAS APLICAÇÕES ................................................................ 46
4.2.1 COM O CAKEPHP, UTILIZANDO O PARADIGMA PROCEDURAL 46
4.2.2 NO JPA/NETBEANS, UTILIZANDO O PARADIGMA ORIENTADO A
OBJETOS ................................................................................................. 48
4.2.3 NO MAKER, UTILIZANDO A PROGRAMAÇÃO INTUITIVA............ 49
4.3 RESULTADO GERAL............................................................................. 50
CONSIDERAÇÕES FINAIS ............................................................................. 52
CONCLUSÃO ............................................................................................... 53
TRABALHOS FUTUROS.............................................................................. 54
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................. 55
APÊNDICE....................................................................................................... 60
APÊNDICE A – CASO DE USO DO SISTEMA DESENVOLVIDO ............... 61
APÊNDICE B – ROTEIRO DE ANÁLISE DOS SOFTWARES
DESENVOLVIDOS ....................................................................................... 65
APÊNDICE C – FORMULÁRIO COM OS TEMPOS DE DURAÇÃO DE CADA
APLICAÇÃO ................................................................................................. 66
8
LISTA DE ILUSTRAÇÕES
1. Ilustração 1 Programa em pascal para calcular a área e o perímetro de
um Retângulo ........................................................................................ 22
2. Ilustração 2 Programa em Java para calcular a área e o perímetro de um
Retângulo, utilizando o paradigma procedural ...................................... 23
3. Ilustração 3 Objeto Retangulo, que servirá para calcular a área e o
perímetro de um Retângulo, quando invocado pelo objeto Janela, no
paradigma orientado a objetos .............................................................. 24
4. Ilustração 4 Objeto Janela, servirá para ler os dados e se comunicar com
o objeto Retangulo, quando invocado pelo objeto Janela, no paradigma
orientado a objetos ................................................................................ 24
9
LISTA DE FIGURAS
1. Figura 1 Abstração em camadas........................................................... 26
2. Figura 2 Exemplo de uma árvore de expressão .................................... 27
3. Figura 3 Outra representação para uma expressão .............................. 28
4. Figura 4 Fluxograma de uma rotina bancária ........................................ 30
5. Figura 5 Tela de cadastro da aplicação desenvolvida em CAKE .......... 47
6. Figura 6 Tela de cadastro da aplicação desenvolvida em JAVA ........... 49
7. Figura 7 Tela de cadastro de cliente no Maker...................................... 64
10
LISTA DE GRÁFICOS
1. Gráfico 1 Tempos de desenvolvimento dos softwares .......................... 46
2. Gráfico 2 Bugs da aplicação em CAKEPHP.......................................... 47
3. Gráfico 3 Bugs da aplicação em JPA/NETBEANS ............................... .48
4. Gráfico 4 Bugs das aplicações desenvolvidas...................................... .51
11
LISTA DE TABELAS
1. Tabela 1 Vantagens e Desvantagens da Programação Intuitiva ........... 30
2. Tabela 2 Vantagens e Desvantagens da Linguagem de domínio
específico .............................................................................................. 32
3. Tabela 3 Vantagens e Desvantagens da Linguagem Natural Controlada
.............................................................................................................. 34
4. Tabela 4 Ferramentas/Framework utilizado em cada paradigma.......... 42
5. Tabela 5 Hardware e Software utilizando no desenvolvimentos dos
softwares ............................................................................................... 43
12
CAPÍTULO 1
INTRODUÇÃO
13
1.1 CONSIDERAÇÕES INICIAIS
Nos últimos anos, preenciou-se um grande progresso da computação. Ele
trouxe um computador em cada residência, ferramentas para trabalho e
diversão, jogos eletrônicos e redes que as interligam com outras residências
e/ou empresas de forma a proliferar a vasta quantidade de informações e
entretenimento. Esse progresso tem sido possível devido ao fato dos
computadores terem se tornado cada vez mais baratos e mais eficientes.
Segundo a previsão de Gordon Moore, fundador da Intel, o poder de
processamento dos microships deve duplicar a cada ano (MOORE, 1965).
Porém, a flexibilidade e utilidade dos sistemas computacionais são limitados
pela vagarosa evolução dos softwares, isso não visto tanto atualmente, pois
principalmente não se há a duplicação do processamento dos microships,
como previsto. Já para Niklaus Wirth, a evolução do hardware é mais rápida do
que
a
evolução
do
software
(BOSZORMENYI
&
GUTKNECHT
&
POMBERGER, 2000).
Afirmações que justificam-se pelo motivo que desde os primórdios da
computação, a criação de software vem sendo tratada do ponto de vista do
computador,
ou
seja,
preocupou-se
em
desenvolver
funções
e/ou
procedimentos complexos a serem realizados pela máquina, mas não se estes
serão facilmente interpretados pelo desenvolvedor. Em razão disso, a principal
evolução do software se deu pela criação das linguagens de programação
(MACLENNAN & BRUCE, 1987). Uma linguagem é um conjunto de regras
ordenadas, sistemáticas e metódicas para comunicar idéias coerentemente
(ALMEIDA, 2005). Uma linguagem de programação é um conjunto de regras
que possibilita a criação de um programa, elas existem para definir os
comandos que queremos que o computador execute (JAMSA & KLANDER,
1999). Também pode ser entendida como uma linguagem para ser usada por
pessoas para expressar um processo que o computador pode entender.
Por serem voltadas para uma visão do computador, as linguagens de
programação não possuem detalhes sobre o problema proposto, ou seja, se é
14
para calcular juros, somar valores entre outros. Isso pode parecer sensato se
apenas a visão do computador for considerada, porém, evidentemente, isto não
é a realidade. Implicando com isso problema ná necessidade de mudança
(manutenção ou extensão), pois esta deve ser realizada através dos mesmos
meios utilizados em seu desenvolvimento (ex, linguagem de programação) os
quais não expressam claramente o que foi resolvido, tornando assim, qualquer
mudança um processo custoso.
Não é de hoje que muitos tentam descrever o que é um Software. Existem
vários conceitos, Segundo PRESSMAN (1995), “Software é um conjunto de
instruções que quando executadas, produzem a função e o desempenho
desejados”, já SOMMERVILLE define que “São programas de computadores e
sua documentação associada”. Este, em alguns casos, é um dos maiores
componentes
do
orçamento
das
organizações.
Segundo
BJARNE
STROUSTRUP, conhecido como o pai do C++, nossa civilização roda em
software.
Atualmente presencia-se o desenvolvimento de softwares ultrapassando
orçamentos, estourando prazos, além disso, algumas vezes os softwares: são
inseguros, desacreditados e difíceis de utilizar. Sempre que uma empresa
pretende introduzir um novo sistema ou atualizar um sistema legado1, isto se
torna um risco considerável. O THE STANDISH GROUP REPORT (1995),
afirma que dois terços dos projetos ultrapassam prazos, orçamentos ou os
dois.
Para CHARLES SIMONYI (2008), ex-arquiteto chefe da Microsoft, o
desenvolvimento de software requer recursos consideráveis de talento e tempo
de forma a barrar a inovação em algumas organizações, o que pode ser visto
também
em
ROSENBERG
(2007),
visto
que
tais
organizações têm
necessidades que somente podem ser supridas pelo processo custoso de
1
Sistema legado é o termo utilizado em referência aos sistemas computacionais de uma
organização que, apesar de serem bastante antigos, fornecem serviços essenciais. Geralmente
utilizam bancos de dados obsoletos. (CAGNIN, 1999)
15
desenvolvimento de software que, conforme dito, está com uma imagem
desgastada.
Imaginasse o cenário em que uma empresa deseja fazer uma mudança em
uma rotina de um software de um determinado domínio. Tal empresa então
teria que contatar a empresa responsável pela manutenção do seu software
que, então, faria um levantamento dos requisitos e, enfim, faria as modificações
desejadas. Tais modificações, porém, podem não condizer exatamente com o
que foi inferido na análise de requisitos e, então, parte do processo poderia ser
refeito. Esse processo envolve, em alguns casos, especialista do domínio,
arquitetos de software, programadores e engenheiros de teste.
Esta divisão de tarefas pode deixar o especialista do domínio frustrado já que
analistas de sistemas e programadores também se frustram com as constantes
mudanças nas especificações (SOFTWELL, 2008). Dessa forma, o seguinte
questionamento surge: como o especialista do domínio poderia contribuir mais
diretamente com o software? A resposta certamente seria que seus
conhecimentos nem sempre são da área técnica, assim, ficam impossibilitados
de escreverem códigos já que estes não são de fácil compreensão. Assim,
procuram-se iniciativas ou métodos de programação que possam resolver este
problema.
1.2 OBJETIVOS
A proposta da pesquisa é realizar um estudo literário sobre Programação
Intuitiva, seu conceito, como funciona, de onde surgiu entre outros aspectos.
Visando verificar o impacto desse paradigma no processo de desenvolvimento
de software e por fim, analisar como uma ferramenta que usa os conceitos da
Programação Intuitiva, pode impactar na produtividade do processo de
produção de software. Na seqüência estão descritos o objetivo geral e os
objetivos específicos, apresentando uma visão refinada dos objetivos do
projeto de pesquisa.
16
1.2.1 GERAL
Analisar se Programação Intuitiva pode impactar na produtividade do processo
de desenvolvimento de Software, utilizando de frameworks e paradigmas
diversos para realizar a pesquisa.
1.2.2 ESPECÍFICOS
•
Realizar revisão literária sobre a Programação Intuitiva;
•
Elaborar um experimento a fim de comparar a produtividade da
construção de softwares nos diferentes paradigmas e ferramentas
(Procedural, utilizando CAKEPHP; Orientado a Objetos, utilizando
JPA/Netbeans; Intuitivo utilizando o Maker), para verificar qual a mais
eficiente.
1.3 ESTRUTURA DO TRABALHO
A fim de se atingir os resultados esperados, este trabalho está estruturado
segundo os capítulos a seguir:
1. No capítulo 2 será composto do embasamento teórico, para o
esclarecimento do objeto de estudo e da pesquisa;
2. O capítulo 3 será composto da metodologia aplicada ao estudo;
3. Já no capítulo 4 será apresentado o resultado da pesquisa;
4. E por fim, será apresenta as considerações finais da pesquisa,
identificando os trabalhos futuros acerca do tema.
17
CAPÍTULO 2
REFERENCIAL TEÓRICO
18
2.1 PARADIGMAS DE PROGRAMAÇÃO
2.1.1 DEFINIÇÃO
PAPERT apud BARANAUSKAS (1994) define que paradigma de programação
como um “quadro estruturador” que é subjacente a atividade de programar,
colocando que sua escolha pode mudar notavelmente a forma de como o
programador pensa sobre a atividade de programar.
O paradigma de programação é tratado por BARANAUSKAS (1994) como um
“modelo” de representação de um problema a ser resolvido pela máquina.
Ainda segundo BARANAUSKAS (1994), o entendimento destes modelos é
fundamental no design de metodologias para desenvolvimento de programas
em uma dada linguagem.
Segundo ASCENIO & CAMPOS (2007, p. 12) “é o paradigma que permite ou
proíbe a utilização de algumas técnicas de programação. Ele é capaz, ainda,
de mostrar como o programador analisou e abstraiu o problema a resolver.”.
Uma das principais motivações para a criação das linguagens de montagem e
seus montadores, foi que em meados das décadas de 40 e 50, com a
inexistência de software e pela falta de linguagens de montagem ou mesmo
linguagens de alto nível, a programação era feita através de linguagem de
máquina o que tornava os programas ilegíveis além da grande dificuldade do
seu processo de manutenção. Não bastando, as necessidades das aplicações
numéricas da época requeriam certas facilidades não existentes nos hardwares
da época, como: números reais e acesso a elementos de um conjunto através
de índices, esta necessidade foi que fez surgir as linguagens de mais alto nível
que continham estes recursos. (BARANAUSKAS, 1994).
Existem vários paradigmas de programação, sendo eles: procedural ou
imperativo, orientado a objetos, funcional, lógico e outros (ASCENIO &
CAMPOS, 2007). Mas nesse tópico iremos analisar apenas os paradigmas
Procedural e o Orientado a objetos, visto que serão utilizados no experimento.
19
2.1.2 PARADIGMA PROCEDURAL OU IMPERATIVO
Este paradigma procura seguir os mesmos conceitos da arquitetura de von
Neumann, onde os programas contém comandos que manipulam posições de
memória por meio de variáveis, definindo assim uma seqüência de instruções
que o computador deve executar. (BARANAUSKAS, 1994).
Partilha-se a idéia de Maria Baranauskas, quando ela descreve a solução do
problema.
O conceito central para representação da solução do problema
é o conceito de “variável” como uma abstração para uma
posição de memória na máquina, para a qual se pode atribuir
um valor. O fluxo de controle da execução pela máquina é
ditado por sequenciação e por comandos de repetição.
(BARANAUSKAS, 1994, p. 4).
O paradigma procedural é considerado o que possui a maior quantidade de
linguagens, ao exemplo de Fortan, C, Pascal. Existem vários motivos que
comprovem está afirmação, voltando no tempo e vê que elas foram muito
utilizadas em aplicações numéricas e também dentro do domínio da ciência da
computação. Segundo a tabela TIOBE (2008) das 20(vinte) linguagens mais
utilizadas atualmente, 10(dez) são procedurais e, além disso, 41,5% do total
das linguagens pesquisadas são procedurais.
E não se pode esquecer que estas linguagens são desenvolvidas por
especialistas em computação focando o uso por especialistas em computação.
Pode-se afirmar ainda que a quantidade de linguagens disponíveis continuará a
crescer enquanto a arquitetura de computadores for a de von Neumann.
(BARANAUSKAS, 1994).
2.1.3 PARADIGMA ORIENTADO A OBJETOS
Para BOO apud ROCHA (2002) sistemas orientados a objetos são “um
conjunto de agentes autônomos que colaboram entre si para a realização de
um comportamento de alto-nível”.
20
Para onde quer que olhe no mundo real, vê-se objetos, eles são:
computadores, carros, motos, televisões, telefones e etc. Segundo DEITEL &
DEITEL (2004, p. 67):
Seres humanos pensam em termos de objetos. Temos a
maravilhosa habilidade da abstração, que nos permite
visualizar imagens numa tela, como pessoas, aviões, árvores
e montanhas, como objetos, em vez de ver pontos coloridos
isolados.
Por simular o mundo real, as linguagens provenientes da orientação a objetos
devem conter um modelo de objetos que possam enviar e receber mensagens
bem como reagir a mensagens recebidas. Dessa forma, procura-se fornecer
um ambiente onde objetos podem co-existir e trocar mensagens entre si.
(BARANAUSKAS, 1994).
SEBESTA (1989, p.471) explica os conceitos de troca de mensagens
demonstrando o significado da expressão 21 + 2:
In the first message, the receiver object is the number 21, to
which is sent the message + 2. So the message 21 + 2 passes
the parameter object 2 to the + method of the object 21. The
code of that method uses the object 2 to build a new object, in
this case, 23. If the system already contains the object 23, then
the result is a reference to it rather than to a new object.
Para um melhor entendimento da expressão 21 + 2, o objeto receptor é o
número 21, para o qual é enviada a mensagem “+ 2”. Essa mensagem passa o
objeto 2 para o método “+” do objeto 21. O código desse método usa o objeto 2
para construir um novo objeto, o 23 (SEBESTA, 1989) . Essa explicação nos
faz entender claramente o funcionamento de troca de mensagens dos objetos.
Considerando a Orientação a Objeto como um novo paradigma, devemos levar
em conta também uma nova maneira de pensar, pois apesar da escrita do
código continuar a ser procedural, a estrutura do modelo computacional não é
a mesma. Basicamente o que se procura é reutilização de código e
21
modularidade2 de escrita, o que torna esse paradigma imbatível em relação ao
paradigma procedural. Este paradigma se distancia da estrutura de von
Neumann, pois os conceitos de processador, memória e dispositivos de I/O
(entrada e saída), já que possui conceitos mais reais, o de objeto. (LEITE &
RAHAL, 2008)
Segundo o índice de TIOBE (2008) este paradigma é o mais utilizado
atualmente, com 56 % do total das linguagens pesquisadas, percebe-se ainda
que em 1(um) ano o crescimento da utilização desse paradigma foi de 3,9%,
enquanto o procedural teve o declínio de 2,4%.
2.1.4 COMPARAÇÃO ENTRE OS PARADIGMAS
Do ponto de vista do programador, ao analisar um problema proposto nos
paradigmas procedural e orientado a objetos, pode-se afirmar que o
programador ao desenvolver um software no paradigma procedural pensa logo
em como as ações podem ser executadas e/ou como modulá-las. Já ao
programar no paradigma orientado a objetos, o desenvolvedor procura
identificar os objetos do problema e como estes se comunicaram. (ASCENIO &
CAMPOS, 2007)
Não se pode afirmar que programas desenvolvidos em linguagens com suporte
a orientação a objetos estejam sempre utilizando o paradigma orientado a
objetos, pois como visto, o paradigma está associado a forma de pensar do
programador, dessa forma, pode-se desenvolver programas em JAVA que não
sejam considerados no paradigma orientado a objetos. Assim, pode-se afirmar
que um software desenvolvido em uma linguagem que seja essencialmente de
um paradigma, a exemplo do JAVA com Orientação a Objetos, não
necessariamente este paradigma foi utilizado no desenvolvimento do
mesmo.(ASCENIO & CAMPOS, 2007).
2
Modularidade: é o termo para o projeto de um sistema que é composto de várias partes que
podem ser trocadas. Desta forma o sistema pode ser dividido em vários subsistemas (incluindo
neste as diversas opções resultantes de trocas). Os sistemas podem ser processos ou
produtos. Cada parte que pode ser trocada é um módulo. (WIKIPEDIA, 2008)
22
Segundo ASCENIO & CAMPOS (2007, p. 14), “Alguns autores consideram que
qualquer paradigma pode ser implementado em qualquer linguagem (inclusive
assembly), pois depende apenas da forma de pensar do programador e de sua
habilidade de programar.”
Será demonstrado abaixo um exemplo de um problema (retirado de ASCENIO
& CAMPOS (2007, p. 12, 13, 14)), onde primeiramente será desenvolvido no
paradigma procedural utilizando a linguagem Pascal, depois no mesmo
paradigma, porém utilizando a linguagem JAVA e por fim no paradigma
orientado a objetos novamente com a linguagem JAVA, a fim de se comprovar
que se pode desenvolver nos dois paradigmas usando a mesma linguagem.
O problema é calcular a área e o perímetro de um retângulo. Para isso, deverá
existir uma janela, pela qual serão informadas as medidas dos lados do
retângulo e poderão ser vistos os cálculos realizados. Trata-se de um problema
simples. Como resolvê-los?
Em pascal a solução do problema ficaria como na ilustração 1 (retirado de
ASCENIO & CAMPOS (2007, p. 13):
Ilustração 1 Programa em pascal para calcular a área e o perímetro de um Retângulo
23
O programa foi desenvolvido em 3(três) módulos, uma função para calcular a
área do retângulo, outro para calcular o perímetro e o módulo principal, que é
responsável por obter os dados, calculá-los através das funções e por fim
apresentar o resultado dos cálculos.
Na ilustração 2 é mostrado o mesmo software escrito em JAVA utilizando o
paradigma procedural (retirada de ASCENIO & CAMPOS (2007, p. 13):
Ilustração 2 Programa em Java para calcular a área e o perímetro de um Retângulo,
utilizando o paradigma procedural
Ao comparar os códigos da ilustração 1 e 2, percebe-se grande semelhança
entre os mesmos, o que comprova a teoria que um software desenvolvido em
uma
linguagem
que
seja
essencialmente
orientado
a
objetos
não
necessariamente utilizará o paradigma orientado a objetos, ao exemplo da
ilustração 2. O que é questionável, pois no exemplo do ilustração 2, se vê a
utilização de objetos, a exemplo das linhas “entrada = new Scanner
(System.ini)” e “altura = entrada.nextFloat()”.
Já nas ilustrações 3 e 4, é apresentado o código do mesmo programa
desenvolvido em Java utilizando o paradigma Orientado a Objetos (retirada de
ASCENIO & CAMPOS (2007, p. 14). Onde antes do desenvolvimento, pensouse em quais objetos seriam necessários para utilização do problema,
identificando assim o Retângulo e a Janela de coleta dos dados.
24
Ilustração 3 Objeto Retangulo, que servirá para calcular a área e o perímetro de um
Retângulo, quando invocado pelo objeto Janela, no paradigma orientado a objetos
A ilustração 3, demonstra a classe (objeto) “Retangulo”, que será invocado
através do objeto Janela, que será apresentado na ilustração 4.
Ilustração 4 Objeto Janela, servirá para ler os dados e se comunicar com o objeto
Retangulo, quando invocado pelo objeto Janela, no paradigma orientado a objetos
Além de tudo, observa-se que esses paradigmas trabalham em conjunto, pois a
lógica dos objetos contém o paradigma procedural. (ASCENIO & CAMPOS,
2007, p. 14).
25
2.2 PROGRAMAÇÃO INTUITIVA
2.2.1 DEFINIÇÃO
O objetivo da Programação Intuitiva é propor uma técnica de desenvolvimento
de rotinas de software, utilizando as mesmas técnicas do WYSIWYG 3, ou seja,
abstrair a complexidade das rotinas de software em uma camada de mais alto
nível. (WIKIPEDIA, 2008)
Ao raciocinar, imagina-se o ideal de se comunicar com o computador que
chegaríamos à utilização da linguagem natural, ou seja, o programador pode
instruir o computador como ele deve se comportar através da fala natural ou da
escrita natural. Entretanto, esse é um futuro ainda remoto que depende de
diversas áreas de estudos, tais como Inteligência Artificial (RUSSELL &
NORVIG, 2005), Processamento de Linguagem Natural (BOLSHAKOV, 2004),
entre outras.
A proposta é um formato comum e intermediário entre uma camada de
abstração de alto nível e as complexas linguagens de programação. Tal
formato deve conter instruções organizadas de forma que possa ser traduzida
de maneira rápida para qualquer linguagem de programação (vide Figura 1
retirada de SOFTWELL (2008)).
3
WYSIWYG é o acrônimo de “What you see is what you get”. É um adjetivo utilizado
para se referir a processadores de textos que apresentam uma constante
representação final do texto ao editor. (WIKIPEDIA, 2008)
26
Diferentes meios de interação
(fala, textos, programação visual, entre outros)
Formato comum proposto
Diferentes linguagens de programação
Figura 1 Abstração em camadas
A vantagem disso está no fato de que camadas de alto nível estarão
disponíveis em diversos formatos e editarão um formato único em comum.
Esse formato poderá, então, ser traduzido para qualquer linguagem de
programação. Essa camada de alto nível deverá ser apresentada segundo um
contexto de um domínio ou conjunto de domínios de forma que o especialista
do domínio possa entender de maneira simples e intuitiva o seu significado.
2.2.2 USO DE FLUXOGRAMAS PARA TORNAR A PROGRAMAÇÃO MAIS
INTUITIVA
Um Fluxograma é um tipo de diagrama que procura representar um processo,
que se utiliza de gráficos para ilustrar de forma clara as informações de cada
elemento desse processo. O que pode ser resumido como a documentação de
todos os passos necessários para execução do dado processo. (WIKIPEDIA,
2008).
Como meio de interação, é proposto, inicialmente, o uso de fluxogramas
juntamente com árvores de expressões para tornar a programação do software
mais intuitiva.
Segundo UCCI citado por SANTIAGO & DAZZI (2003) “o perfil de um
fluxograma é constituído por um conjunto de estruturas de programação, cada
qual com uma representação distinta”. E para SOUZA apud SANTIAGO &
DAZZI (2003, p. 2):
27
Com a utilização de figuras geométricas, os fluxogramas
representam estruturas lógicas de seqüência, desvio
condicional e repetição condicional e o fluxo de seqüência
representado por setas direcionais, o que facilita
sensivelmente a visualização da solução.
Árvores de expressões facilitam o entendimento de complexas expressões.
Elas são compostas por funções matemáticas (ex: soma, multiplicação),
funções do domínio (ex: calcula CPMF, calcula juros), constantes (ex: 1, 2) e
variáveis (ex: A, B). Funções do domínio são funções como qualquer outra,
porém estão dentro de um contexto de um determinado domínio. Basicamente,
árvores de expressões são árvores, cujas funções, constantes e variáveis são
representadas em seus nós. Os argumentos de uma função de domínio são
filhos diretos do nó em que ela está representada que também podem ser
outras funções. O nó raiz pode ou não retornar um resultado que pode ser
utilizado de várias maneiras no sistema.
Para ilustrar uma árvore de expressão, considere a expressão matemática
abaixo:
A = B / (C + D)
Tal expressão é representada através de uma árvore de expressão, da forma
apresentada na figura 2, retirada de SOFTWELL(2008).
A
=
Divisão
B
Soma
C
D
Figura 2 Exemplo de uma árvore de expressão
28
Por ser uma expressão matemática, podemos representar como mostra a
figura 3, retirada de SOFTWELL (2008).
B
A
=
______________
C
+
D
Figura 3 Outra representação para uma expressão
O uso do fluxograma torna o programa bastante simples de manter. Junto com
utilização de funções do domínio, o especialista do domínio é capaz de manter
e evoluir um software. A prova disso podemos encontrar nos fundamentos do
aprendizado, mais especificamente no aprendizado em lógica de programação.
Partilha-se a idéia de Rafael e Rudimar Luís, quando eles relatam a facilidade
de interpretação com a utilização de fluxogramas.
Obtendo a idéia principal de estruturar a programação através
de fluxogramas e posterior detalhamento em português
estruturado, ambos utilizando as mesmas estruturas de
controle, facilita o processo de aquisição do conhecimento e
principalmente a consolidação deste. (SANTIAGO & DAZZI
,2003, p. 2)
No curso de Ciência da Computação da Universidade do Vale do Itajaí se
utiliza de fluxogramas para na disciplina de programação, esse método vem
tendo bons resultados, pois é empregado o uso de gráficos para ensinar a
lógica do problema, o que facilita o aprendizado dos estudantes. (SANTIAGO &
DAZZI, 2003). Para melhor entendimento, ler-se abaixo:
Os fluxogramas quando usados para descrever a lógica de
solução, sem levar em consideração detalhes de linguagem de
programação ou de interface, costuma gerar bons resultados,
pois os aprendizes conseguem direcionar seus esforços
apenas nos passos que levarão a solução do problema. Só
depois disso é que vem a preocupação com os demais
detalhes de refinamento para gerar o efetivo programa.
(SANTIAGO & DAZZI, 2003, p. 2)
29
Existem diversos trabalhos, tais como (REZENDE & GARCIA, (1995); JANDL&
ZUCHINI,
(1999);
BROWN,
(1988);
BROWN,
(1991)),
que
procuram
sedimentar o aprendizado de lógica de programação, utilizando elementos
visuais, tais como fluxograma. Tais trabalhos visam o fomento de conceitos
básicos, principalmente, em alunos de programação. Imaginando que todo
especialista
do
domínio
não
tem
conhecimentos
avançados
em
desenvolvimento de software, então o coloca em um nível similar de
conhecimento a um aluno iniciante de computação. Sendo assim, a mesma
técnica utilizada para compreensão de computação pode ser aplicada a ambos
os casos.
Um exemplo de uma solução em fluxograma é mostrado logo abaixo (retirada
de SOFTWELL (2008)).
Considere uma rotina fictícia de um software de um domínio bancário.
Considere também a pré-existência de algumas funções de domínio que são
descritas abaixo:
Domínio Bancário
Função 1 - Aplica Juros: função que recebe três parâmetros: um valor e uma
taxa de juros e o tempo. A função deve devolver o valor corrigido no tempo
solicitado.
Função 2 - Aplica CPMF: função que recebe um valor e aplica a taxa do
imposto CPMF.
Função 3 - Tipo da Conta: função que retorna se a conta é especial ou
normal.
Na Figura 4 é demonstrado a rotina utilizando fluxogramas.
30
Início
Conta
Saldo Base
Meses
Não
Sim
Sim
Não
Tipo da Conta é especial
Aplica Juros de 0,43%
Aplica Juros de 0,37%
Aplica CPMF
Fim
Saldo Corrigido
Figura 4 Fluxograma de uma rotina bancária
Analisando o fluxograma, é simples e direto descrever a rotina. Ela deverá
calcular o valor corrigido que poderá ser sacado pelo proprietário. Para isso, a
rotina recebe o número da conta, o saldo original e a quantidade de meses
passados. Caso a conta seja especial, a rotina aplica juros de 0,37%, caso
contrário, ela aplica juros de 0,43%. No final, ela deve aplicar o CPMF e
devolver o valor corrigido.
As características da Programação Intuitiva podem ser vistas resumidamente
na tabela 1, onde é demonstrado as suas vantagens e desvantagens.
VANTAGENS
DESVANTAGENS
•
Fácil compreensão;
•
Limitada;
•
Linguagem mais próxima
•
Específica.
do domínio;
•
Simples manutenção.
Tabela 1 Vantagens e Desvantagens da Programação Intuitiva
Baseado na tabela 1, pode-se afirmar que a programação intuitiva proporciana
ao desenvolvedor faciidados no desenvolvimento de software, o que por outro
lado faz com que o produtos desenvolvidos limitem-se a determinados
31
aspectros, pois a capacidade de transformar a linguagem de alto nível em
linguagem de programação pode esbarrar na capacidade desta metodologia.
2.3 OUTROS ESTILOS DE PROGRAMAÇÃO
2.3.1 LINGUAGEM DE DOMÍNIO ESPECÍFICO
Devido a dificuldade existente nos softwares atuais, está se tornando prática
estender linguagens de programação de grande espectro com o objetivo de
apoiar o desenvolvimento de softwares em domínios específicos. Fato este
vem acontecendo por que as linguagens atuais estão ficando cada vez mais
difíceis de se programar, do ponto de vista do apreendizado, devido a
existencia de uma grande quantidade de comandos, bibliotecas e funções.
(SILVA & PINHEIRO, 2004).
Essas linguagens são bastante úteis para se obter uma maior produtividade em
ambientes que são desenvolvidos vários software para um mesmo domínio, a
exemplo de um ambiente de uma fábrica de software4, não bastando, ela por
possuir uma linguagem de fácil entendimento faz com que a interação e
integração entre usuário e desenvolvedor seja facilitada. (C.E.S.A.R, 2008)
SILVA & PINHEIRO (2004, p. 1) define a linguagem de domínio específico ou
LDE como:
Uma linguagem de programação ou linguagem de
especificação executável que oferece, por meio de notações e
abstrações apropriadas, poder expressivo focado e
usualmente restrito a um domínio particular.
4
FABRICA DE SOFTWARE: É “Um processo estruturado, controlado e melhorado de forma
contínua, considerando abordagens de engenharia industrial, orientado para o atendimento a
múltiplas demandas de natureza e escopo distintas, visando à geração de produtos de
software, conforme os requerimentos documentados dos usuários e/ou clientes, da forma mais
produtiva e econômica possível”. (FERNANDES & TEIXEIRA, 2004, p. 117)
32
FRECHOT citado por SILVA & PINHEIRO (2004) acrescenta que “estas
linguagens são geralmente pequenas, mais declarativas do que imperativas, e
menos expressivas do que uma linguagem de propósito geral”.
As LDEs possuem várias vantagens em relação as linguagens convencionais,
estas são: permitir que as expressões sejam feitas no idioma e no nível de
abstração do problema, o que permite que os conhecedores do domínio
possam validar, modificar e até mesmo desenvolver programas; facilidade para
validar e otimizar os programas no nível do domínio; auto-documentação e
incorporação do conhecimento sobre o domínio. O que possibilita um ganho de
produtividade, confiabilidade, portabilidade e manutenibilidade dos softwares.
(DEUSEN apud SILVA & PINHEIRO, 2004)
Mas o alto custo para projetá-las, mantê-las, custo de adaptação dos usuários
e disponibilidade limitada, fazem com que a linguagem de domínio específico
se torne um problema quando implementada. (SILVA & PINHEIRO, 2004)
As características da Linguagem de Domínio Específico podem ser vistas
resumidamente na tabela 2, onde é demonstrado as suas vantagens e
desvantagens.
•
•
VANTAGENS
Incorporação de
•
DESVANTAGENS
Disponibilidade limitada;
conhecimento do domínio;
•
Dificuldade de encontrar
expressão de soluções no
•
Custo para projeta-las,
idioma e no nível de
implementa-las e mantê-
abstração de domínio do
las;
problema;
•
seu escopo próprio;
Possibilidade da
A possibilidade de validar
•
Custo de adaptação dos
usuários.
e otimizar os programas no
nível de domínio.
Tabela 2 Vantagens e Desvantagens da Linguagem de domínio específico
33
Analisando a tabela 2, percebe-se que a linguagem de domínio especifico
proporciona, principalmente aos especialistas de domínio, facilidades de
compreensão do que se esta sendo desenvolvido, especialmente por
possibiitar que seja escrita em qualquer idioma e por estar mais próxima do
domínio, porém o seu alto custo para projetá-las, aliado a dificuldade de
adaptação dos usuários, pode dificultar a sua implantação.
2.3.2 LINGUAGEM NATURAL CONTROLADA
Os principais motivos para a criação da Linguagem Natural Controlada foram: a
necessidade de se obter um alto nível de abstração que seja compatível com a
fase de projeto, ser processável pela máquina e de complementar as
especificações da UML5.(LEAL, 2006).
Para LEAL (2006, p. 34) “A utilização de linguagens naturais controladas está
vinculada ao alto nível de abstração (melhorar a legibilidade por humanos) e à
possibilidade de processamento computacional.” O principal objetivo é permitir
que especialistas do domínio especifiquem o negócio utilizando apenas seus
conhecimentos, utilizando uma metodologia compatível com a modelagem do
domínio. (LEAL, 2006)
No trabalho de SILVA & PINHEIRO (2004) a linguagem natural controlada é
utilizada para definir a linguagem específica de domínio (vide seção 2.3.1), a
regra principal é que a gramática da linguagem defina somente a formatação,
os termos que não são palavras reservadas devem ser representados como
referência aos elementos da UML (classes, atributos e operações) por meio
das suas descrições. (LEAL, 2006).
Segundo LEAL (2006) a proposta do alto nível de abstração, como uso de
conceitos
de
domínio
específico,
oferece
algumas
vantagens,
como:
especificação é mais legível, do que outras; melhoria da qualidade de código,
5
UML: “É a abreviação de Linguagem de Modelagem Unificada (Unified Modeling Language),
uma notação (principalmente diagramática) para modelagem de sistema, usando conceitos
orientados a objetos.” (LARMAN, 2000, p. 28)
34
já que o código é gerado automaticamente; concentração de esforços na
modelagem do domínio. (LEAL, 2006)
A Linguagem Natural Controlada (LNC) possibilita desenvolver um sistema em
um nível mais elevado, gerando código automaticamente, acima da
implementação, o que permite redução da diferença conceitual do código e do
problema proposto. O que se assemelha com os compiladores no processo de
transformação do código das linguagens em código de máquina. (LEAL, 2006)
As características da Linguagem Natural Controlado podem ser vistas
resumidamente na tabela 3, onde é demonstrado a sua vantagem e
desvantagem.
VANTAGENS
•
DESVANTAGENS
•
Deduz a diferença
Limitação.
conceitual entre o domínio
do problema e o código;
Tabela 3 Vantagens e Desvantagens da Linguagem Natural Controlada
Na Linguagem natural controlada, por utilizar a UML no seu desenvolvimento,
faz com que torne mais fácil a sua compreensão, porém assim como na
Programação Intuitiva e na Linguagem de Domínio Específico, a sua limitação
pode torna-la inutiizável para certos problemas.
2.4 PRODUTIVIDADE DE SOFTWARE
Economicamente, a produtividade de software está diretamente relacionada
com o total de produtos produzidos e as despesas de sua produção. (JONES
1996).
A produtividade é o melhor indicador do progresso econômico de uma
empresa, é através do aumento da produtividade que se obtêm melhores
preços,
melhor
competitividade,
melhor
prestação
de
serviços
e
35
consequentemente maiores salários, resultando em um aumento do nível de
vida dos profissionais envolvidos, aproximando-se dos países desenvolvidos.
(ZICARELLI apud BARBARÁN & FRANCISCHINI, 1998).
Segundo CHIANG & MOOKERJEE (2004) a melhoria na produtividade no
desenvolvimento de software se dá através do balanceamento de três pilares
do gerenciamento de software: tecnologia, pessoas e processo. E para
BEHRENS (1983) em estudo realizado com vinte e cinco projetos afirma que “o
tamanho do projeto, o ambiente de desenvolvimento e linguagem de
programação impactam na produtividade”.
Percebe-se que a escolha da tecnologia (linguagem) é relatada pelos dois
autores como ponto importante para se obter uma melhor produtividade de
software.
Para se medir a produtividade de software é levado em consideração o que ele
é capaz de fazer, e não a quantidade de códigos ou mesmo da sua
documentação. O que significa que o valor econômico do software não pode
ser medido da mesma forma que os bens e serviços. (SIDLER, 2002).
Existem algumas métricas para se avaliar softwares, as principais são:
•
Linha de Código (LOC)
Relacionada com o tamanho da saída sobre a quantidade de esforço
para se produzir software, onde é considerado a quantidade de
linhas codificadas, e seu esforço, o que é medido pela quantidade de
pessoas. Para JONES citado por BARBARÁN & FRANCISCHINI
(1998) essa maneira de ser medir não é considerada a melhor, pois
pode existir programas sofisticados com poucas linhas de código e
outro nem tanto sofisticado e com muitas linhas produzidas.
•
Pontos de Função (FP)
Essa métrica mede o tamanho do software através da quantidade de
funcionalidades existentes, tomando como base o projeto lógico ou o
36
modelo de dados Para se calcular os FP de um software deve ser
observado cinco pontos importantes: números de entradas; números
de saídas; números de consultas; números de arquivos e a
quantidade de interfaces externas. A cada uma é se atribuída um
grau de complexidade: simples, média e complexa. Depois se avalia
as características que avaliam a funcionalidade geral da aplicação,
atribuindo uma pontuação de 0 a 5. E por fim, multiplica-se um pelo
outro
e
se
obtém
o
Ponto
de
Função.(BARBARÁN
&
FRANCISCHINI, 1998)
•
COCOMO (Construtive Cost Model)
Segundo BOEHM citado por BARBARÁN & FRANCISCHINI (1998)
existem três modelos para se estimar esforço, prazo, custo e
tamanho da equipe para um projeto de software. Barry, criador desse
método os descreve os modelos como:
•
Básico
Esse modelo se assemelha com o LOC, pois ele leva em
consideração a quantidade de linhas de códigos existentes.
(BARBARÁN & FRANCISCHINI, 1998)
•
Intermediário
Neste modelo é considerado o tamanho do software, bem
como
os
aspectos:
avaliações
subjetivas
do
produto,
hardware, pessoal e dos atributos existentes no projeto.
(BARBARÁN & FRANCISCHINI, 1998)
•
Avançado
Engloba todos os aspectos do modelo intermediário e também
a avaliação do impacto dos custos em cada passo do
processo do desenvolvimento de software. (BARBARÁN &
FRANCISCHINI, 1998)
Para se calcular o COCOMO, deve seguir os passos: Escolher o modo do
projeto, podendo ser: orgânico, difuso e restrito; Determinar a quantidade de
instruções existentes no projeto, podendo se utilizar o modelo FP para se
37
definir as instruções; E por fim, se aplicar a equação das instruções existentes
e o esforço para se elaborar o software. (BARBARÁN & FRANCISCHINI,1998)
Partilha-se dos comentários de BOEHM apud BARBARÁN & FRANCISCHINI
(1998) sobre COCOMO:
Atualmente, um modelo de estimativa de custos de software
se sai bem se puder estimar os custos de desenvolvimento do
software dentro de 20% dos custos reais em 70% do tempo e
dentro de seu próprio campo de ação (isto é, dentro das
classes de projetos para as quais ele foi calibrado). Isso não é
tão preciso quanto gostaríamos, mas é exato o bastante para
nos oferecer alguma ajuda na análise econômica de
engenharia de software e nas tomadas de decisões.
2.5 FRAMEWORK PARA PRODUTIVIDADE
Como visto, um dos principais fatores que influenciam na produtividade no
desenvolvimento de software é a tecnologia utilizada, o que inclui linguagem de
programação e frameworks (ferramentas), nessa sessão será apresentado
algumas ferramentas que proporcionam ganhos de produtividade, baseados
nos paradigmas Procedural, Orientado a Objetos e da Programação Intuitivo,
nessa ordem.
2.5.1 CAKEPHP
O CakePHP é um framework desenvolvido na linguagem PHP (acrônimo
recursivo de “Hypertext Preprocessor” ), que proporciona aos programadores
dessa linguagem, iniciantes ou experientes, uma estrutura de desenvolvimento
para aplicações complexas, que sejam concluídas rapidamente, sem que haja
prejuízo a flexibilidade do código. (CAKEPHP, 2008).
Para utilizar o CAKEPHP, basta copiar sua estrutura hierárquica de pastas e
arquivos para dentro da aplicação, e depois utilizar os recursos disponíveis
pela ferramenta de acordo com a estrutura do Banco de dados. (CAKEPHP,
2008).
38
O CAKEPHP possui a facilidade de rodar em qualquer servidor que suporte
PHP, além disso, dá suporte aos principais bancos de dados existentes, mas
se recomenda a utilização do MySql, alé disso, possui recursos dos mais
famosos frameworks e também uma grande comunidade que auxilia no
suporte. (CAKEPHP, 2008).
2.5.2 JPA/NETBEANS
O NetBeans é um projeto open source fundado pela Sum Microsystems, criado
para que desenvolvedores possam criar softwares nas mais diversas
linguagens, como: Java, Ruby, C++ entre outras Sua IDE6 é escrita em Java,
porém
pode
ser
utilizada
por
qualquer
linguagem
de
programação.
(NETBEANS, 2008)
A IDE NetBeans possui uma grande quantidade de extensões que podem ser
facilmente adicionadas, além disso o produto não possui limitações de como e
por quem pode utilizado.
A Java Persistence API (JPA) baseado no conceito Plain Old Java Object
(POJO), incorpora as melhores práticas de frameworks de persistência,
buscando padronizar o mapeamento do objeto/relacional da plataforma Java.
(INTEGRATOR, 2008).
2.5.3 MAKER
O Maker é uma ferramenta de desenvolvimento de sistemas para Web,
utilizando de técnicas que proporcionam aumento de produtividade sem que o
desenvolvedor tenha que escrever linhas de código. Possui uma interface que
interagi facilmente com o usuário através de recursos intuitivos proporcionados
pelos assistentes, ajudas e componentes de desenvolvimento. (SOFTWELL,
2008)
6
IDE: “do inglês Integrated Development Environment ou Ambiente Integrado de
Desenvolvimento, é um programa de computador que reúne características e ferramentas de
apoio ao desenvolvimento de software com o objetivo de agilizar este processo.” (WIKIPEDIA,
2008)
39
A ferramenta disponibiliza um conjunto de componentes visuais para
construção de formulários. A partir de tais elementos, os desenvolvedores
podem criar novos componentes a depender de sua necessidade. A criação de
um novo componente, assim como todo tipo de evolução na ferramenta, é feita
utilizando a própria ferramenta. Para isso, a ferramenta disponibiliza um
domínio específico para evolução de uma IDE. Isso garante que a ferramenta
possa evoluir independente do fabricante, garantindo a reutilização dos
componentes. (SOFTWELL, 2008)
As aplicações geradas pelo Maker são interpretadas por um software em
JAVA, mas seu código fonte pode ser exportado em sua totalidade. Possui
ainda assistentes que auxiliam na criação de formulários e menus, contribuindo
ainda mais com a produtividade dos seus produtos finais. (SOFTWELL, 2008)
40
CAPÍTULO 3
ASPECTOS
METODOLÓGICOS
41
3. METODOLOGIA
Primeiramente, foi realizada uma revisão bibliográfica, a fim de conhecer os
paradigmas de programação Procedural e Orientado a Objetos, bem como
linguagens de programação que se assemelham com a metodologia da
Programação Intuitiva, a exemplo da Linguagem de Domínio Específico e a
Linguagem Natural Controlada. Como objetos de estudo foram utilizados,
principalmente, livros, artigos, teses, dissertações e páginas da Web.
No segundo momento, foi selecionada uma equipe de 3 (três) programadores
para utilizarem os frameworks: CAKEPHP, JPA/Netbeans e Maker, os quais
possuem o objetivo de impactar na produtividade do desenvolvimento dos
softwares, para desenvolver o Cadastro de Clientes, como base no caso de
uso descrito no apêndice A, a fim de avaliar qualitativamente os produtos finais
utilizando uma abordagem comparativa. Esse método de pesquisa foi escolhido
por atender aos objetivos da pesquisa, obtendo com isso melhores parâmetros
no comparativo dos softwares. Os requisitos foram escolhidos conforme
padrões de interface. Esse experimento foi realizado no dia 25 de junho de
2008.
Para a seleção dos frameworks utilizados foi levado em consideração os
paradigmas Procedural e Orientado a Objetos, já que estes são considerados
como: o que mais possui linguagens de programação e o mais utilizado
atualmente, como descrito no capítulo 2.
Os softwares foram analisados com base os produtos finais, pois como dito na
sessão sobre produtividade, apesar das dificuldades em se avaliar um
software, essa é a melhor maneira.
Após obter os tempos de conclusão dos softwares, foi realizada a avaliação
qualitativa com base em um roteiro de testes descrito no apêndice B, o qual foi
dividido em dois grupos de requisitos a serem analisados: layout e
programação.
42
3.1 DELIMITAÇÃO DA PESQUISA
Com base no experimento, foi realizada uma análise dos softwares
desenvolvidos a fim de coletar informações como: Tempo de Produção, bugs
existentes, com o objetivo de tentar responder as questões propostas na
problemática.
A pesquisa foi realizada na Assessoria de Modernização e Informática da
Prefeitura Municipal de Paulo Afonso, sediada na Av. Apolônio Sales, 924 –
Centro – Paulo Afonso-BA.
3.2 COLETA DE DADOS
Para a coleta dos dados do experimento foram utilizadas planilhas, as quais
colaboraram no preenchimento dos horários de início e fim de cada projeto,
bem como, auxiliar na identificação de bugs dos softwares. Com base em um
Caso de Uso, especificado no Apêndice A, foi traçado um roteiro a ser seguido
por cada programador, sendo assim todos iniciaram o processo sendo marcado
o tempo de início e após a conclusão o tempo de término.
3.3 FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO DOS
SOFTWARES
As ferramentas e/ou frameworks utilizados no desenvolvimento dos softwares
são descritos na tabela 4.
FRAMEWORK (VERSÃO)
CAKEPHP (1.1.19.6305)
JPA/NETBEANS (5.5.1)
MAKER (2.4.0.25)
PARADIGMA
PROCEDURAL
ORIENTADO A OBJETOS
INTUITIVO
Tabela 4 Ferramentas/Framework utilizado em cada paradigma
Importante salientar que os programadores escolhidos são capazes de
desenvolver o software proposto utilizando estas ferramentas.
43
3.4 HARDWARE E SISTEMA OPERACIONAL UTILIZADO
O desenvolvimento dos softwares foi feito em um ambiente homogêneo, com
hardware e Sistema Operacional iguais para todos os desenvolvedores, na
tabela 5 os mesmos são relacionados:
HARDWARE /
SOFTWARE
Processador
Memória
HD
Placa de Vídeo
Sistema
Operacional
CONFIGURAÇÃO / DESCRIÇÃO
AMD Athlon(tm) 65 X2 Dual
Core Processor 4000+ 2.1 GHz
1 GB DDR2
160 GB SATA
ATI Radeon Xpress 1150 Series
Windows XP Professional Service Pack 2
Tabela 5 Hardware e Software utilizando no desenvolvimentos dos softwares
44
CAPÍTULO 4
APRESENTAÇÃO E
INTERPRETAÇÃO DOS
DADOS
45
4.1 RESULTADO DO EXPERIMENTO REALIZADO COMPARANDO AS
LINGUAGENS DE PROGRAMAÇÃO PROPOSTAS ATRAVÉS DE UMA
ANÁLISE QUALITATIVA
Nessa seção serão mostradas algumas variáveis levantadas pelo pesquisador
para a descoberta do objetivo específico que trata sobre um experimento para
comparar a eficácia da programação intuitiva através de um produto
desenvolvido, utilizando de gráficos, figuras, tabelas e suas respectivas
análises, os dados analisados têm como base o experimento realizado,
confrontando os fatores que os diferenciam.
Como citado na metodologia, para o experimento foi selecionada uma equipe
de 3 (três) profissionais, todos experientes nas ferramentas/frameworks
utilizados.
No primeiro momento foi marcada a hora inicial de cada projeto em um
formulário, contendo as colunas: início, fim e total do tempo percorrido. Como
demonstra o Apêndice C.
De acordo com os resultados apresentados no gráfico 1, a ferramenta que
obteve melhor resultado foi a que utiliza os conceitos da Programação Intuitiva,
ficando em segundo o software desenvolvido no paradigma Orientado a
Objetos, terminando com uma diferença de 14 minutos, o que se considerando
o experimento, esse tempo somado a 3 minutos, seria suficiente para a
conclusão de outra aplicação com o mesmo nível de complexidade da proposta
utilizando a Programação Intuitiva.
Assim, com a finalização dos aplicativos, nota-se claramente a diferença de
tempo existente no desenvolvimento de um mesmo software utilizando
frameworks e paradigmas diferentes. Para exemplificar melhor, isso é
demonstrado no gráfico 1.
46
Gráfico 1 Tempos, em minutos, do desenvolvimento dos softwares
Para que seja possível extrair alguma conclusão do experimento, analisar
somente o tempo de término de cada software não é o suficiente, pois não
adiantaria ser rápido se os requisitos solicitados não fossem atendidos, bem
como se existissem bugs, dessa forma, houve a necessidade de analisar o
roteiro de teste apresentado no apêndice B em cada um dos softwares, a fim
de se obter dados mais precisos sobre a eficiência dos mesmos. O roteiro foi
dividido em requisitos de layout e de programação, dessa forma idenfiticou-se o
que precisa ser modificado para que os softwares atendam todos os requisitos.
4.2 ANÁLISE DAS APLICAÇÕES
4.2.1 COM O CAKEPHP, UTILIZANDO O PARADIGMA PROCEDURAL
O CAKEPHP utilizado no experimento apresentou alguns bugs, que totalizaram
em 50%. Como apresentado no Gráfico 2.
47
Gráfico 2 Bugs da Aplicação usando o CAKEPHP
A quantidade de bugs encontrados na aplicação foi 9 (nove), o que significa a
metade dos quesitos analisados, percebe-se através do gráfico 2 que os
maiores bugs são de layout, o que pode ser justificado pela dificuldade
encontrada pelo desenvolvedor implementar estes requisitos, mas o framework
possibilita fazer isto
A maior parte dos bugs (66,67%) estão diretamente ligados as regras básicas
no desenvolvimento de software, como por exemplo: campos somente leitura,
limitação dos campos não implícita na digitação, tamanho dos campos
compatíveis com o tamanho máximo permitido no banco de dados, entre
outros, onde alguns destes problemas podem ser vistos na figura 5.
Figura 5 Tela de cadastro da aplicação desenvolvida em CAKEPHP
48
Contudo, o CAKEPHP, é bem aceito pela comunidade PHP, e apesar de não
ter atendido em tempo comparativamente satisfatório as necessidades do
experimento de pesquisa possui inúmeras vantagens o que pode tornar uma
boa opção para desenvolvedores.
4.2.2 NO JPA/NETBEANS, UTILIZANDO O PARADIGMA ORIENTADO A
OBJETOS
Com o framework NetBeans utilizando o JPA o desempenho no atendimento
dos requisitos foi similar ao do CAKEPHP, com 2 bugs a menos. As principais
diferenças foi que no software desenvolvido com o JPA/NetBeans a validação
dos campos obrigatórios é feita e a facilidade para modificar o tamanho dos
campos é maior. Como se pode identificar no gráfico 3 as diferenças com o
gráfico anterior são muito poucas e sua critica e analise torna-se paralela a
anterior, onde com o JPA/Netbeans houve 7 bugs.
Gráfico 3 Bugs e Requisitos Atendidos da Aplicação usando o JPA/NETBEANS
Na figura 6 abaixo, é apresentado o cadastro do cliente, onde podem ser
observados alguns dos requisitos atendidos.
49
Figura 6 Tela de cadastro da aplicação desenvolvida em JAVA
O tempo para conclusão da aplicação em JPA/NETBEANS foi um ponto forte a
se considerar, além disso, o fato de ser criado automaticamente as classes e
páginas JSP foi um ponto que resultou no segundo melhor tempo, porém teve
uma perda de 15 minutos ao ter que modificar as páginas para que possibilite
atender os requisitos referentes ao layout do programa, o que poderia ser feito
automaticamente pelo framework.
4.2.3 NO MAKER, UTILIZANDO A PROGRAMAÇÃO INTUITIVA
O framework Maker obteve o melhor resultado entre as ferramentas e
linguagens utilizadas, onde em 17 minutos o software foi desenvolvido sem
haver a existência de bugs.
Como
dito,
na
programação
intuitiva
não
houve
bugs,
isso
ocorre
principalmente porque o Maker já possui a maioria dos requisitos solicitados já
embutidos, o que evitou perda de tempo desnecessários no desenvolvimento
de softwares, na figura 7 é mostrado a tela de cadastro.
50
Figura 7 Tela de cadastro de cliente no Maker
A figura 7 pode ser comparada com uma aplicação desktop, porém, trata-se de
uma aplicação web, o que para muitos pode facilitar na navegação e
visualização dos campos. Tornando assim o cadastro mais intuitivo para muitos
usuários.
4.3 RESULTADO GERAL
Ao comparar os softwares, percebe-se que os bugs existentes são decorrentes
de requisitos básicos, como: Tamanho de campos, descrição, digitação
indevida de caracteres, entre outros (vide Apêndice B). Estes, como podem ser
vistos no gráfico 5, não foram apresentados no software desenvolvido com o
Maker, pois este possui os requisitos já embutidos, pois por seguir o conceitos
da programação intuitiva, possibilitou que estas configurações fossem
automáticas, baseadas no tipo de dado e domínio dos campos da base de
dados.
51
Gráfico 4 Bugs das aplicações desenvolvidas
Percebe-se então, que o uso da programação intuitiva, pôde proporcionar
redução do tempo na produção de software, visto que os outros teriam/tiveram
que ser configurados para atender a todos os requisitos, o que demandaria
tempo, este fator é a cada dia mais importante nas organizações e segundo o
THE STANDISH GROUP REPORT (1995), é um dos principais para atrasos
em projetos de software.
O resultado está associado, dentre outros fatores, ao alto nível de abstração
proposto pela programação intuitiva, o que possibilitou ao desenvolvedor
ganhos consideráveis de tempo. Além disso, como este estilo de programação
tem como objetivo principal reduzir o custo de tempo no processo do
desenvolvimento de software, a ferramenta utilizada continha padrões de
interface para as telas a serem criadas, assim contribuiu para a redução do
tempo total de desenvolvimento.
A utilização de fluxogramas na programação intuitiva poderia resultar em
melhores resultados comparando com outros produtos, porém não houve a
necessidade de se implementar regras de negócio pelo motivo que o software
proposto tratava apenas de um cadastro simples, sem validação alguma.
52
CONSIDERAÇÕES FINAIS
53
CONCLUSÃO
Durante a pesquisa levantou-se toda a bibliografia disponível sobre o tema e
constatou que apesar dos grandes benéficos da programação intuitiva pouco
se produziu neste campo de estudo. E também que os estudos nesse sentido
estão diretamente ligados a iniciativa privada. Ainda foi indentificar que existem
inciativas ao exemplo da Linguagem de Domínio Específico e da Linguagem
Natural Controlada, que se assemelham com a metodologia da Programação
Intuitiva, o que pode ser resumida em uma proporcionar redução de tempo na
producão de software, em conjunto com a facilidade do desenvolvimento.
Com isto, verificou-se que a programação intuitiva, busca reduzir tempo de
desenvolvimento de software e com isso reduzir custos de sua produção. A sua
metodologia proporciona um alto nível de abstração, possibilitando que haja um
menor nível de especialização da equipe de desenvolvimento. Aliado a técnicas
de WYSIWYG em conjunto com fluxogramas e árvores de expressão, faz com
que se obtenha grande impacto na produtividade da produção de software.
O experimento realizado revelou que no comparativo da construção dos
softwares com os seguintes frameworks (CAKEPHP, JPA/NetBeans e Maker),
o mais eficaz com menor taxa de bugs foi o MAKER, destacando-se também
com o menor tempo de conclusão e qualidade do produto final. O que serve
como hipótese para o uso de tecnologias e/ou metodologias que visão
aumentar a produtividade do desenvolvimento de software, ao exemplo da
Programação Intuitiva, podem significar em ganhos de produtividade sem que
haja dano a qualidade dos produtos de software.
Conclui-se ainda que o experimento, tratando-se de uma análise de software, e
por este modivo existirem fatores como: ambiente, hardware, sistema
operacional, desenvolvedor e entre outros, não pode servir de parâmetro para
afirmar que a programação intuitiva é mais eficaz ou não que outros
paradigmas, pois, as variáveis analisadas, como: tempo e bugs, podem mudar
ao se modificar estes fatores. Porém, em se tratando deste experimento, a
Programação Intuitiva, por meio do Maker, proporcionou melhores resultados.
54
TRABALHOS FUTUROS
Para trabalhos futuros sugere-se um estudo sobre comparativo entre
frameworks que utilizam os conceitos da Programação Intuitiva, ao exemplo do
Maker e Genexus, no sentido de construir uma base de conhecimento para
melhor aplicabilidade no ambiente de desenvolvimento com o auxílio da
Programação Intuitiva, obetendo parâmetros para se definir qual dos produtos
desenvolvidos tive melhor resultado.
Nesse estudo, pretende-se estipular um tempo para se desevolver um
software, como por exemplo 24 horas, sem que haja uma definição do que
deverá ser feito, deixando na responsabilidade do desenvolvedor a escolha do
produto a ser desenvolvido, podendo ser: cadastro de clientes, sistema
acadêmico, sistema de contabilidade, entre outros, a partir daí será avaliado
fatores como: Pontos por Função do Software, se ultrapassou o tempo definido
e
bugs
existentes
baseando-se
no
que
foi
idealizado
pelo
próprio
desenvolvedor seguindo padrões de interface de software, bem como se as
rotinas idealizados estão funcionando como deveriam. Assim, será observado a
complexidade do produto final, se foi possível terminar o software em tempo, e
a partir daí analisar os bugs existentes.
55
REFERÊNCIAS BIBLIOGRÁFICAS
ASCENCIO, Ana F. G. & CAMPOS, Edilene A. V. Fundamentos da
Programação de computadores: Algoritmos: Pascal, C/C++ e JAVA. 2ª ed.
– São Paulo: Pearson, 2007.
ALMEIDA, Napoleão Mendes de. Gramática metódica da língua portuguesa.
São Paulo: Saraiva, 2005.
BARANAUSKAS, M. C. C. Procedimento, Função, Objeto ou Lógica?
Linguagens de Programação vistas pelos seus paradigmas. Depto. de
Ciências da Computação – IMECC – UNICAMP, 1991.
BEHRENS, C A. Measuring Software Productivity of Computer System,
1983.Development Activities with Point Functions. IEEE Trans. Soft. Engr. SE9(6), pp. 648-652.
BOLSHAKOV, A. I. & GELBUKH, A. Computational Linguistics: Models,
Resources, Applications. IPN-UNAM-FCE, 2004.
BOSZORMENYI, L. & GUTKNECHT, J. & POMBERGER, G.. The School of
Niklaus Wirth. Eds. D-Punkt Verlag, 2000.
BROWN, M. . Exploring algorithms using BALSA-II. IEEE Computer. V 21
No. 5, 1988.
BROWN, M.H. Zeus: A System for Algorithm Animation and Multi-view
Editing, Research Report n. 75, DEC Systems Research Center, Palo Alto, CA,
1991
CAGNIN, M. I. – Avaliação das vantagens quanto à facilidade de
manutenção e expansão de sistemas legados sujeitos a engenharia
reversa e segmentação. Dissertação de Mestrado – Departamento de
Computação, UFSCar. São Carlos, 1999.
56
CAKEPHP.
Disponível
em
http://www.cakephp.com.br/.
Acessado
em
24/06/2008.
C.E.S.A.R. C.E.S.A.R realiza palestras sobre linguagens de domínio específico
e
verificação
e
validação
de
sistemas.,
Disponível
em
http://www.cesar.edu.br/noticia_15.html. Acessado em 25/06/2008.
CHIANG, R. & MOOKERJEE, S. Improving Software Team Productivity.
Communications of the ACM, 2004. volume 47, p. 89 a 93.
DEITEL, H. M. & DEITEL, P. J. Java como programar. 4ª ed. - Porto Alegre:
Bookman, 2003.
FERNANDES, Aguinaldo A. & TEIXEIRA, Descartes de S. Fábrica de
Software: Implantação e Gestão de Operações. São Paulo: Ed. Atlas, 2004.
LARMAN, Craing. Utilizando UML e padrões: uma introdução à análise e ao
projeto orientado a objetos; Tradução Luiz A. Meirelles Salgado – Porto Alegre:
Bookman, 2000.
INTEGRATOR. Disponível em http://www.integrator.com.br/ . Acessado em
25/06/2008.
JAMSA, K. & KLANDER, L. Programando em C/C++: A Bíblia. São Paulo:
Makron Books. Tradução e revisão técnica: Jeremias René D. Pereira dos
Santos,1999.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books,
1995.
JANDL, P. J. & ZUCHINI, M. H. IC: Um Interpretador de Linguagem C. IN
Projeções - USF, Bragança Paulista, V. 17, 1999, pp. 101-112.Kurnia, A., Lim,
A e Cheang, B. (2001) Online Judge. Computer & Education, v. 36 p. 299-315.
57
JONES, C. Software Assesments, Benchmarks and Best Practices.
Addison Wesley, 1999.
LEAL, Luciana Nunes. Natural MDA: Uma linguagem de especificação de
ações baseada em linguagem natural controlada. 2006. Dissertação
(Mestrado em Informática), Núcleo de Computação Eletrônica Universidade
Federal do Rio de Janeiro, Rio de Janeiro-RJ.
LEITE, M. & RAHAL, N. A. S. Jr. Programação Orientada ao Objeto: uma
abordagem
didática.
Disponível
http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html.
em:
Acessado
em 25/06/2008.
MACLENNAN & BRUCE J. Principles of Programming Languages. Oxford
University Press, 1987.
MAKER, Softwell Solutions, 2008, 1 cd room. Homepage Institutional.
MALTA, S. & LAGO, E. & MOURA, G. & MOURA, M. F. Manual de Orientação
para Normalização de Trabalhos Científicos. Paulo Afonso: Faculdade Sete
de Setembro, 2006.
MICROSOFT OFFICE 2003. Microsoft Corporate, 2008, 1 cd room. Homepage
Institutional.
MOORE, G.. Cramming more components onto integrated circuits.
Electronics Magazine, Volume 38, Número 8. Abril, 1965.
NETBEANS. Disponível em http://www.netbeans.org. Acessado em 24/06/2008
PAPERT, S. New Images of Programming: in search of an educationally
powerful concept of technological fluency. (A proposal to the National
Science Foundation). Cambridge, MA:MIT Technology Laboratory, 1991.
58
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books,
1995.
REZENDE, P.J. & GARCIA, I.C. Astral: Animação Gráfica de Algoritmos e
Estruturas de Dados - Uma Abordagem Construtiva, VIII Simpósio Brasileiro de
Computação Gráfica e Processamento de Imagens, 1995.
ROCHA, Camila Ribeiro. Estudo do Paradigma de Orientação a Objetos no
Desenvolvimento de Sistemas de Informação. 2002. Iniciação Científica.
(Graduando em Bacharelado Em Ciência da Computação) - Universidade
Federal de Goiás, Instituto de Informática.
ROSENBERG, S. Anything You Can Do, I Can Do Meta. Technology.
Disponível em http://www.technologyreview.com/Infotech/18047/. Acessado em
26/05/2008.
RUSSELL, S. & NORVIG, P. Artificial Intelligence: A Modern Approach.
Segunda Edição, 2005.
SANTIAGO, Rafael de & DAZZI, R. L. S. Ferramentas que auxiliam o
desenvolvimento da lógica de programação. In: XII SEMINCO - Seminário
de Computação, 2003, Blumenau. Anais do XII SEMINCO. Blumenau : Furb,
2003. p. 113-120.
SEBESTA, R. W. Concepts of Programming Languages. California: The
Benjamin Cummings Publishing Company Inc.,1989.
SIDLER, R. Software Productivity, 2002.
SIMONY,
Charles,
Intentional
Software,
http://www.infoq.com/interviews/simonyi-on-intentional.
15/04/2008.
disponível
em
Acessado
em
59
SILVA, S. R. P. & PINHEIRO, J. M. . Um Framework para Criação de
Linguagens de Domínio Específico. In: 8o Simpósio Brasileiro de Linguagens
de Programação, Rio de Janeiro, 2004.
SOFTWELL
Solutions.
Simplificamos
a
Tecnologia,
disponível
em
http://www.softwell.com.br. Acessado em 25/04/2008.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Pearson, ,
2003.
SUN, Java Technology. Disponível em http://java.sun.com/. Acessado em
26/05/2008.
THE STANDISH GROUP REPORT. The CHAOS Report, 1995.
TIOBE
SOFTWARE,
disponível
em
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html, acessado em
22/06/2008.
WIKIPEDIA,
FLUXOGRAMAS.
Disponível
em
http://pt.wikipedia.org/wiki/Fluxograma. Acessado em 26/05/2008.
WIKIPEDIA. Wysiwyg. Disponível em http://pt.wikipedia.org/wiki/WYSIWYG,.
Acessado em 26/05/2008.
60
APÊNDICE
61
APÊNDICE A – CASO DE USO DO SISTEMA DESENVOLVIDO
uc001 – CADASTRO DE CLIENTES
Atores
•
Usuário do Sistema;
•
Cliente
Descrição Sucinta
Cadastrar os Clientes da empresa, a fim de manter seus dados em uma base
de dados informatizada.
Pré-Condições
Ter em mãos os dados do cliente
Fluxo Principal
Cadastrar Cliente
1. Selecionar no menu ou clicar em botão para abrir a tela de Cadastro de
Clientes;
2. Incluir os dados;
3. Clicar em Cadastrar
<Campos do Formulário>
Campo
Obrigatório? Editável?
Formato
ID
S
N
INTEIRO
NOME
S
S
VARCHAR(100)
CPF
N
S
CHAR(11)
RG
N
S
VARCHAR(15)
ENDERECO
N
S
VARCHAR(100)
62
NUMERO
N
S
VARCHAR(10)
BAIRRO
N
S
VARCHAR(50)
CIDADE
N
S
VARCHAR(50)
ESTADO
N
S
CHAR(2)
<Opções do usuário>
Opção
Descrição
Incluir
Incluir um novo registro
Alterar
Alterar o registro
Excluir
Excluir o registro
Atalho
Fluxos Alternativos
FA01–Alterar
Alterar o cadastro do cliente
•
Selecionar opção ou clicar em botão para alterar o Cadastro de Clientes;
•
Incluir os novos dados;
•
Clicar na opção de gravar;
FA02–Excluir
Excluir o cadastro do cliente
•
Selecionar a opção ou clicar em botão para excluir o registro
selecionado;
•
Perguntar se realmente deverá excluir (MS01);
•
Confirmar ou cancelar o procedimento;
63
Mensagens de Tela
MS01
Antes de exclusão do usuário, deverar ser perguntado ao usuário se
realmente deseja excluir o registro
Requisitos
RT01 – Não permitir ser informado o campo código, o mesmo deverá ser
comente leitura.
RT02 – Os campos numéricos devem ser bloqueados para digitação de
caracteres não numéricos.
RT03 – A quantidade máxima de caracteres permitidos para cada campo
deve-se limitar ao tamanho máximo no banco de dados.
RT04 – O tamanho do campo na tela deverá ser compatível com seu
tamanho no BD.
RT05 – O campo referente ao Estado deverá ser escolhido em uma lista.
RT06 – A tabulação dos campos deverá ser de acordo a seqüência
informada no fluxo principal.
RT07 – Os campos obrigatórios deverão ser validados.
Protótipo
PT01 – Cadastro de Cliente
64
Figura 1 Protótipo da tela de cadastro
65
APÊNDICE B – ROTEIRO DE ANÁLISE DOS SOFTWARES
DESENVOLVIDOS
66
APÊNDICE C – FORMULÁRIO COM OS TEMPOS DE DURAÇÃO DE CADA
APLICAÇÃO
FERRAMENTA /
PARADIGMA
CAKEPHP /
PROCEDURAL
JPA/NETBEANS /
ORIENTADO A OBJETOS
MAKER / PROGRAMAÇÃO
INTUITIVA
TEMPO
INÍCIO
FIM
09:53
10:27
34
09:37
10:09
31
09:41
09:58
17
(minutos)