ISSN 1517 - 5111

ISSN online 2176-5081

Junho, 2009

260

CGPE 8348

Framework Orientado a
Objetos Aplicado ao
Desenvolvimento do
IrrigaCerrado

ISSN 1517-5111
ISSN online 2176-5081
Junho, 2009
Empresa Brasileira de Pesquisa Agropecuria
Embrapa Cerrados
Ministrio da Agricultura, Pecuria e Abastecimento

Documentos 260
Framework Orientado
a Objetos Aplicado ao
Desenvolvimento do
IrrigaCerrado
Danilo Santos Teodoro
Ozanival Dario Dantas
Lus Gustavo Barioni
Euzebio Medrado da Silva
Daniela Henrique de Oliveira Duarte

Embrapa Cerrados
Planaltina, DF
2009

Exemplares desta publicao podem ser adquiridos na:

Embrapa Cerrados
BR 020, Km 18, Rod. Braslia/Fortaleza
Caixa Postal 08223
CEP 73310-970 Planaltina, DF
Fone: (61) 3388-9898
Fax: (61) 3388-9879
http://www.cpac.embrapa.br
sac@cpac.embrapa.br
Comit de Publicaes da Unidade
Presidente: Fernando Antnio Macena da Silva
Secretria-Executiva: Marina de Ftima Vilela
Secretria: Maria Edilva Nogueira
Superviso editorial: Jussara Flores de Oliveira Arbus
Equipe de reviso: Francisca Elijani do Nascimento

Jussara Flores de Oliveira Arbus
Assistente de reviso: Elizelva de Carvalho Menezes
Normalizao bibliogrfica: Shirley da Luz Soares Arajo
Editorao eletrnica: Leila Sandra Gomes Alencar
Capa: Leila Sandra Gomes Alencar
Impresso e acabamento: Divino Batista de Sousa
Alexandre Moreira Veloso
1a edio
1a impresso (2009): tiragem 100 exemplares
Edio online (2009)

Todos os direitos reservados

A reproduo no-autorizada desta publicao, no todo ou em parte,
constitui violao dos direitos autorais (Lei no 9.610).
Dados Internacionais de Catalogao na Publicao (CIP)
Embrapa Cerrados
F813

Framework orientado a objetos aplicado ao desenvolvimento do

IrrigaCerrado/ Teodoro, Danilo Santos... [et al.]. Planaltina, DF :
Embrapa Cerrados, 2009.
33 p. (Documentos / Embrapa Cerrados, ISSN 1517-5111, ISSN
online 2176-5081 ; 260).
1. Software irrigao. 2. Cerrado. II. Santos, Teodoro Danilo.
III. Srie.
005.3 - CDD 21

Embrapa 2009

Autores

Danilo Santos Teodoro

Arquiteto de Sistemas da Eficincia TI
danilo@eficienciati.com.br
Ozanival Dario Dantas
Cientista da Computao, M.Sc.
Analista da Embrapa Cerrados
dario@cpac.embrapa.br
Lus Gustavo Barioni
Engenheiro Agrnomo, Ph.D.
Pesquisador da Embrapa Cerrados
barioni@cpac.embrapa.br
Euzebio Medrado da Silva
Engenheiro Agrnomo, Ph.D.
Pesquisador da Embrapa Cerrados
euzebio.medrado@gmail.com
Daniela Henrique de Oliveira Duarte
Tecnloga em Processamento de Dados
Analista da Embrapa Cerrados
daniela@cpac.embrapa.br

Agradecimentos

Ao Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico CNPq - Brasil pelo apoio financeiro ao projeto Economia Espacial no
Uso e Conflito da gua (Processo 555952/2006-1) do Programa de
Revitalizao da Bacia Hidrogrfica do Rio So Francisco.

Apresentao

A rea de tecnologia da informao vem procurando novas tcnicas

para padronizar e facilitar o desenvolvimento de sistemas. Nesse
sentido, foi criado o conceito de frameworks, que a criao de uma
estrutura de classes relacionadas, que constitui uma implementao
apenas iniciada para atender um conjunto de aplicaes de um
determinado domnio. A partir dessa estrutura inicial, podem-se incluir
novas classes herdadas das j existentes, com objetivo de atender
s necessidades especficas do domnio do negcio, nesse caso, os
sistemas de irrigao.
No desenvolvimento do software IrrigaCerrados, foi utilizada
uma framework que possibilitasse a generalidade, a flexibilidade
e a extensibilidade das classes. Com isso, ganhou-se: rapidez no
desenvolvimento; uma estrutura flexvel para atender os diversos tipos
de sistemas de irrigao; e a possibilidade de expanso para comportar
novos sistemas de irrigao.
Jos Robson Bezerra Sereno
Chefe-Geral da Embrapa Cerrados

Sumrio

Introduo.................................................................................... 9
Arquitetura................................................................................. 10
Modelo em Camadas................................................................... 11
Camada de viso.................................................................... 11
Camada de controle................................................................ 15
Camada de modelo.................................................................. 17
Framework Aplicado ao IrrigaCerrado............................................. 19
Camada de viso com o piv convencional................................. 19
Camada de controle com o piv convencional............................. 22
Camada de modelo com o piv convencional.............................. 23
Entendendo o Funcionamento das Camadas no IrrigaCerrado............ 23
Exibindo um Mdulo.................................................................... 24
Realizando uma Consulta.............................................................. 25
Persistindo uma Informao.......................................................... 26
Avaliando um Piv Convencional................................................... 27
Concluso.................................................................................. 29
Referncias................................................................................ 30
Abstract..................................................................................... 31

Framework Orientado
a Objetos Aplicado ao
Desenvolvimento do
IrrigaCerrado1
Danilo Santos Teodoro
Ozanival Dario Dantas
Lus Gustavo Barioni
Euzbio Medrado da Silva
Daniela Henrique de Oliveira Duarte

Introduo
O IrrigaCerrado um software, em desenvolvimento, que nasceu de
um projeto de pesquisa cujo objetivo avaliar e dimensionar, de forma
otimizada, o uso da gua no manejo da irrigao. Para tanto, deve
realizar as seguintes tarefas: avaliao do sistema de irrigao (seja
ele, piv convencional, piv lepa, gotejamento, asperso convencional,
asperso sob copa, etc.); avaliao do solo (utilizando tensiometria);
e manejo da irrigao (respondendo s perguntas: quando irrigar? e
quanto irrigar?).
De acordo com as tarefas descritas, o software deveria possuir uma
estrutura composta por cadastros (da propriedade, de equipamentos de
irrigao, de coletas e resultados de avaliaes, tanto da irrigao quanto
do solo, de culturas, entre outros) e por funes para realizar clculos
(rea relativa individual, rea total por grupo, lmina medida, rea
adequadamente irrigada, etc.). Adicionalmente, todas as informaes
geradas no sistema deveriam ser armazenas em um banco de dados.

Software desenvolvido na Embrapa Cerrados, para uso na irrigao, que busca responder as perguntas: quando irrigar e quanto irrigar.
1

12

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Ao analisar a estrutura necessria para o software, foi percebida a

ocorrncia de entidades semelhantes (entre cadastros, avaliaes,
conexes entre os mdulos, funes, etc.), o que permitiu a definio
de padres. A definio de padres importante para permitir a
reutilizao dos mdulos, facilitar o entendimento do projeto, melhorar
sua manutenibilidade e extensibilidade e, finalmente, fundamentar uma
base slida para o desenvolvimento do software (LOBO, 2009).
Dessa forma, a possibilidade de se padronizar grande parte do projeto
IrrigaCerrado permitiu a criao de uma framework2, a fim de se
estabelecer uma base para a construo do software e de outros
aplicativos com arquitetura fsica do tipo cliente x servidor. Com o
objetivo de realizar uma separao entre a apresentao do sistema e a
lgica de negcio e controle, a framework foi divida em trs camadas:
modelo (contm os dados relativos ao domnio), viso (tela de
apresentao e interao com o usurio) e controlador (define a forma
que a interface reage entrada do usurio e fluxo do sistema), tambm
conhecido como arquitetura MVC (modelo-viso-controlador) (GAMMA,
E. et al., 1995).

Arquitetura
Para facilitar a interoperabilidade de componentes e a separao dos
mdulos (dividir para conquistar), foi adotado o modelo em camadas
(KRUCHTEN, 2003). Baseado nessa sentena, existe um princpio que
diz:
1. No conecte ou acople objetos que no so Interface do usurio
(IU) diretamente a objetos de IU. Por exemplo, no faa um objeto
de software Venda (um objeto do "domnio" no-IU) ter referncia
a um objeto janela. Por qu? Porque as janelas esto relacionadas a
uma aplicao em particular, enquanto (idealmente) os objetos nojanela podem ser reusados em novas aplicaes ou ligados a uma
nova interface.
Conjunto de classes que cooperam entre si e compem um projeto reutilizvel para uma categoria
especfica de software (GAMMA, et al., 1995).
2

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

2. No coloque a lgica da aplicao (como um clculo de imposto)

em mtodos de objetos de IU. Objetos de IU devem apenas iniciar
elementos IU, receber eventos de IU (como um clique de mouse em
um boto) e delegar solicitaes de lgica da aplicao a objetos
no-IU (tais como, objetos de domnio) (LARMAN, 2002).

Modelo em Camadas
O modelo adotado est dividido em trs camadas: Modelo, Viso e
Controlador. A grande vantagem desse tipo de modelo a possibilidade
de realizar diferentes implementaes de componentes para cada
uma das camadas, tornando-as permutveis. Com isso, consegue-se,
ao mesmo tempo, uma interface padro para basear o aplicativo e
flexibilidade para fornecer uma implementao totalmente diferenciada,
que ainda assim se encaixar com o sistema (LOBO, 2009). Daqui
para frente, essa arquitetura ser chamada apenas de MVC, de acordo
com a Fig. 1.

GUI<<
Viso<<
TfrmPadraoCadastro
<<

ICadastro

<<

<<
Controlador<<
TControladorPadraoCadastro

IConsulta

Modelo <<
Regras<<
TdtmdlPadraoCadastro
<<
<<

Fig. 1. Componentes do MVC.

Camada de viso
Camada responsvel pela interface grfica, que dar acesso s
funcionalidades do sistema. Representada por um descendente de
TfrmPadraoCadastro ou at mesmo de TForm. Por padro, permite
consultar e cadastrar informaes, baseado no controlador associado.

13

14

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Alm das aes padro de consulta e cadastro, pode acessar

diretamente o controlador para ter acesso a servios diferenciados e
especficos da tela atual. Devido infraestrutura Delphi, a Viso deve
enxergar componentes do Modelo para lig-los aos seus componentes
visuais, mas ela nunca deve chamar os servios do modelo
diretamente, devendo para isso passar pelo Controlador, como em:
Viso (Form):

ContratoCadastro.GravarAlteracao.

Controlador (ICadastro):

ModeloCadastro.GravarAlteracao.

Modelo (DataModule):

clntdtstCadastro.ApplyUpdates(0).

Na Fig. 2, mostram-se as classes que compem a camada de viso do

framework.

Fig. 2. Classes que compem a camada "Viso".

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Essa hierarquia descreve as principais classes que compem a camada

Viso. A classe TForm a nica que no foi personalizada.
TForm: classe padro de janelas no Delphi, de onde se deve
herdar somente em ltimo caso, em que no h nenhuma janela
compatvel para herana.
TfrmPadraoDialogo: janela independente, geralmente aparece de
forma modal (exclusiva). No possui vnculo com controladores,
mas pode possuir. No contida dentro de um PageControl.
Utilizada quando necessrio perguntar algo ao usurio, pedir
feedback ou qualquer operao exclusiva.
TfrmPadraoJanela: tela padro para todas as janelas no sistema.
Basicamente define a aparncia das janelas, por isso no possui
barra de ttulo, j que dever estar contida dentro da aba de um
PageControl.
TfrmPadraoAba: janela que possui um PageControl, devendo ser a
tela padro (direta ou indiretamente) de toda viso que precisar de
abas (como consulta e cadastro, por exemplo).
TfrmPadraoCadastro: classe mais importante da camada de viso,
define o comportamento e aparncia da maioria das janelas.
Permite consulta e cadastro graas a sua associao com as
interfaces IConsulta e ICadastro. Por padro, quem implementa
essas interfaces o controlador. Implementa vrios mtodos
utilizados para cadastro e consulta, alm de rotinas de exportao
e impresso. Essa classe deve ser utilizada sempre que uma viso
que permita consulta e cadastro se fizer necessria. Na Fig. 3,
mostra-se a aparncia da tela de consulta e, na Fig. 4, exibe-se a
tela de cadastro dessa classe.

15

16

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 3. TfrmPadraoCadastro (aba consulta).

Fig. 4. TfrmPadraoCadastro (aba cadastro).

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Camada de controle
Essa a camada que deve conhecer as outras, servindo como
intermediador entre viso e modelo. Representada por um descendente
de TControladorPadraoCadastro ou, at mesmo, TObject em casos
em que a implementao muito diferente do restante do projeto. Por
padro, realiza as interfaces de Consulta e Cadastro, permitindo:
Criar um novo registro.
Alterar um registro existente.
Excluir um registro.
Realizar uma consulta.
Gravar alteraes.
Cancelar alteraes.
Um controlador tem como funo:
Controlar o fluxo do sistema.
Guardar referncia e instanciar a viso e o modelo.
Encaminhar chamadas da viso ao modelo, quando necessrio.
Realizar algum cdigo que no seja relacionado nem com a
apresentao (janela e controles do usurio), nem com os dados
propriamente ditos.
Preparar o local (recipiente) onde a viso ser exibida.
Um controlador deve sempre implementar o design pattern Singleton,
para permitir uma nica instncia do controlador no sistema e facilitar
o acesso a ela (sempre deve ser acessado usando <NomeDaClasse>.
ObterInstancia.<NomeDoMtodo>, como em:
TCategoria.ObterInstancia.MostrarConsulta;
Na Fig. 5, mostra-se a hierarquia das principais classes da camada de
controle (Controlador).

17

18

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 5. Classes que compe a camada "Controlador".

As classes TObject e TInterfacedObject so nativas do Delphi. A

seguir a descrio da hierarquia:
TObject: essa a classe ancestral de todas as classes. Deve-se
herdar dela somente quando no necessrio implementar uma
interface e quando no h outra classe mais completa compatvel.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

TInterfacedObject: classe do Delphi para ser herdada quando uma

dada classe implementa alguma interfaces.
TPadraoInterface: altera o comportamento da classe
TInterfacedObject para evitar algumas questes com classes
singleton e vises que utilizam interfaces. Usada internamente.
IConsulta: interface representando as operaes comuns
em uma tela de pesquisa. Qualquer classe que implementar/
realizar essa interface pode ser conectada a um descendente de
TfrmPadraoCadastro.
ICadastro: interface contendo as operaes comuns em uma tela de
edio. Qualquer classe que implementar/realizar ICadastro pode ser
conectada a um descendente de TfrmPadraoCadastro.
TControladorPadraoCadastro: classe mais importante da hierarquia
de controladores. Realiza as interfaces ICadastro e IConsulta,
gerencia (referencia, instancia, controla e acessa) sua prpria
viso e modelo, controla o fluxo da aplicao, etc. Deve ser
utilizada sempre que o mdulo em questo possuir o seguinte
comportamento: viso herda (direta ou indiretamente) de
TfrmPadraoCadastro, modelo herda (direta ou indiretamente) de
TdtmdlPadraoCadastro, contm consulta e cadastro.

Camada de modelo
Representa os dados e geralmente contm as regras de negcio que
tambm podem estar na base de dados. Os dados correntes no modelo
so visualizados atravs da viso, s vezes em forma de consulta,
s vezes em forma de cadastro, entre outros. representada por um
descendente de TdtmdlPadraoCadastro, ou at mesmo TDataModule,
quando os componentes variam muito do padro consulta &
cadastro. Por padro, implementa os seguintes servios:
Inserir registro.
Editar registro selecionado.
Excluir registro selecionado.

19

20

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Gravar alterao.
Cancelar alterao.
Consultar.
A diferena desses servios com os servios do controlador que,
enquanto o modelo realiza sua implementao diretamente nos dados,
o controlador apenas encaminha as chamadas aos respectivos servios
do modelo, com algumas poucas alteraes na viso.
Na Fig. 6, mostram-se as principais classes que compem a camada de
Modelo.

Fig. 6. Classes que compe a camada "Modelo".

A classe TDataModule, nativa do Delhi, a nica que no foi

personalizada:

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

TDataModule: repositrio de dados default do Delphi, deve

ser utilizado apenas quando no houver uma classe descendente
que seja compatvel. Deve ser usada quando o mdulo a ser
desenvolvido no seguir o padro dos demais, ou seja, se o mdulo
em questo no possuir uma lista e um cadastro. Essa classe, bem
como todas as suas descendentes, responsvel pela comunicao
junto ao SGBD e pelas regras de negcio.
TdtmdlPadraoCadastro: classe mais importante da hierarquia de
Modelos. Contm componentes de acesso aos dados para consulta
e cadastro; e codificao necessria para a realizao de consultas,
insero, alterao, excluso de registros, gravao, entre outros.
Sabe informar se h algum campo obrigatrio no preenchido.
Pode implementar servios para clculos e repositrios de regras de
negcio, que sero chamados pelo respectivo controlador.

Framework Aplicado ao
IrrigaCerrado
Com base no framework descrito anteriormente, o projeto IrrigaCerrado
ser implementado, utilizando como exemplo o mdulo avaliao de
piv convencional.

Camada de viso com o piv convencional

Na Fig. 7, mostra-se o relacionamento da camada de apresentao
da avaliao de Piv Convencional com o framework. Como existem
vrias avaliaes parecidas, foi definida a interface IAvaliacao, a
qual realizada pela nova classe TfrmPadraoAvaliacaoSistemaIrriga,
que serve como ancestral para todas as avaliaes do sistema.
As avaliaes possuem categorias como Piv Central, Localizada,
Asperso , por isso foi definida uma classe padro para cada
categoria (como TfrmPadraoAvaliacaoPivoCentral, por exemplo) com
o intuito de facilitar as futuras manutenes do software. A classe
TfrmAvaliacaoPivoConvencional representa a viso do mdulo.

21

22

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 7. Classes de apresentao da Avaliao de Piv

Convencional.

A seguir so mostradas as vrias abas da tela Avaliao de Piv

Convencional (Fig. 8 a 11).

Fig. 8. Aba de consulta do mdulo Avaliao de Piv Convencional.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 9. Aba de cadastro do mdulo Avaliao de Piv Convencional.

Fig. 10. Aba de coleta do mdulo Avaliao de Piv Convencional.

23

24

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 11. Aba de resultados do mdulo Avaliao de Piv Convencional.

Camada de controle com o piv convencional

As classes destacadas em amarelo, na Fig. 12, representam a herana
necessria para desenvolver o controlador referente ao mdulo
Avaliao de Piv Convencional.

Fig. 12. Classes do controlador da Avaliao de Piv Convencional.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Camada de modelo com o piv convencional

As classes destacadas em amarelo, na Fig. 13, representam a herana
necessria para desenvolver o modelo referente ao mdulo Avaliao
de Piv Convencional:

Fig. 13. Classes do modelo da Avaliao de Piv Convencional.

Entendendo o Funcionamento das

Camadas no IrrigaCerrado
A comunicao entre as camadas realizada pelo controlador. Quando
o usurio executa uma ao em uma tela qualquer como abertura
de um mdulo, consulta ou gravao , caso essa informao no
possa ser tratada pela prpria viso, enviada uma mensagem ao
respectivo controlador para que ele resolva o problema. O controlador,
cujo papel determinar o fluxo da aplicao, identifica se pode
resolver o problema ou pass-lo para outra classe ou camada. Se for
algo relacionado aos dados, enviada a devida mensagem ao modelo
associado ao controlador, que, em ltima instncia, executa a ao
como consultar um registro ou persistir uma informao. No exemplo
da Fig. 14, demonstrada uma situao em que o usurio requisita

25

26

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

o mdulo Propriedade, fazendo com que o controlador decida se

necessrio instanciar a viso e o modelo, para depois invocar um
servio que realize uma consulta. Devido forma de conexo (binding)
do Delphi, cada alterao no modelo refletida na viso, fazendo com
que o usurio veja as informaes, que so apresentadas em um grid.

Fig. 14. Diagrama de atividades mostrando o relacionamento entre camadas.

Exibindo um Mdulo
No diagrama da Fig. 15, so mostrados o relacionamento e a troca de
informaes entre objetos com o objetivo de consultar as propriedades
cadastradas.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Fig. 15. Mostrar Consulta Propriedade.

Essa a sequncia necessria para exibir a consulta do mdulo

Propriedade. Inicialmente, o pesquisador, pela tela principal
(frmPrincipal), clica na opo Propriedade. Com isso, o frmPrincipal
invoca o mtodo SetRecipiente, que trata de criar viso, se
necessrio, e indica que tanto a interface de Consulta quanto a
interface de Cadastro sero implementadas pela instncia da classe
TPropriedade (self). Com isso, se j no existir, criada uma nova
aba na tela principal. O fluxo termina quando o frmPrincipal chama o
mtodo MostrarConsulta da classe TPropriedade, que manda a viso
ativar a aba de consulta e mostrar sua tela (Show).

Realizando uma Consulta

No prximo diagrama (Fig. 16), demonstrada a interao entre
objetos/camadas para a execuo de uma consulta.
Aps o pesquisador ativar o mdulo Propriedade e clicar no boto
Consultar representado pela ao actnConsultaExecute , a viso,
atravs da sua superclasse TfrmPadraoCadastro, verifica se ela pode
realizar uma consulta e, em caso positivo, chama o mtodo Consultar
do objeto responsvel pela consulta o controlador do mdulo,
TPropriedade o controlador basicamente encaminha essa chamada
de mtodo ao modelo que efetivamente realiza a consulta na base de

27

28

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

dados. Ao faz-lo, os dados da consulta automaticamente aparecero

na viso (TfrmCadastroPropriedade).

Fig. 16. Consultando uma Propriedade.

Persistindo uma Informao

No diagrama da Fig. 17, mostram-se o relacionamento e a troca de
informaes entre objetos com o objetivo de gravar as alteraes
realizadas em uma dada propriedade.

Fig. 17. Gravar Propriedade.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Como na consulta, aps o usurio alterar uma informao e clicar

no boto Gravar (actnGravaAlteracaoExecute), a viso do mdulo
Propriedade verifica se a ela est apta a realizar cadastros
(VerificarContratoCadastro). Se estiver, manda o controlador gravar
alteraes. O controlador cria o modelo, se necessrio, e verifica se
existe algum campo obrigatrio no preenchido. Se houver campos
obrigatrios no preenchidos, o controlador exibe a mensagem
adequada e pra o fluxo. Se estiver tudo certo, pede para o modelo
enviar as alteraes ao banco de dados. possvel enxergar a diferena
de papis: o Modelo tem a funo de verificar se existem campos
obrigatrios no preenchidos, mas quem controla o fluxo ou seja, se
deve parar ou no o controlador.

Avaliando um Piv Convencional

No diagrama da Fig. 18, mostram-se o relacionamento e a troca
de informaes entre objetos com o objetivo de avaliar um piv
convencional.

Fig. 18. Avaliao do Piv-central.

29

30

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

A prxima sequncia mostra o ciclo completo de acesso, consulta e

alterao de um registro.
1. A partir da tela principal, pedido ao controlador que encontre um
recipiente (parent) para a viso. Note que nem a tela principal sabe
quem a viso, apenas o controlador.
2. Depois de exibir a consulta do mdulo Propriedade, o pesquisador
executa a ao Consultar, que verifica se existe um objeto que
implemente a interface IConsulta: se existir, chama seu mtodo
Consultar, passando os parmetros da consulta (uma lista do
tipo: nome_parametro=valor_parametro).
3. Isso faz com que o controlador crie, se necessrio, o modelo e
chame a funo Consultar deste datamodule recm-criado.
4. Com isso, caso a consulta retorne registros, eles sero exibidos na
viso (TfrmAvaliacaoPivoCentral).
5. O Pesquisador seleciona um registro e executa a ao
AlterarRegistro da interface ICadastro representada pelo
controlador TPropriedade.
6. Essa chamada, por padro, faz com que o controlador recupere
os valores que compe a chave-primria do registro selecionado
(ObterValorChavePrimaria).
7. Com esses valores em memria, chamado o mtodo
ConsultarCadastro, que faz uma pesquisa utilizando os valores
obtidos acima no componente de cadastro/edio a fim de editar o
registro selecionado.
8. Se a consulta retornar um registro, o componente de cadastro entra
em modo de edio e o controlador manda uma mensagem para a
viso ativar sua aba de cadastro e aparecer na tela.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

9. Aps alterar alguma informao, o Pesquisador executa a ao

Gravar, que chama o mtodo GravarAlteracao do controlador
TPropriedade.
10. A instncia da classe TPropriedade verifica se existem campos
obrigatrios no preenchidos. Se houver algum, o controlador exibe
uma mensagem para o Pesquisador e pra o fluxo, do contrrio,
chamado o mtodo GravarAlteracao do modelo, que persiste as
alteraes do registro na base de dados.
11. Em seguida, o controlador TPropriedade manda uma mensagem
para o modelo atualizar sua consulta.
12. Como houve alteraes no piv-central, necessrio executar
alguns procedimentos no SGBD para atualizar alguns valores.
Isso feito quando o controlador manda o modelo executar
LaminaMedida.
13. Para finalizar, a tela de Avaliao de Piv-central contm
um controle que exibe os dados que foram calculados pelo
procedimento anterior. Para mostrar os dados atuais, o controlador
chama o mtodo AtualizarDistribuicaoLaminaAgua.

Concluso
A definio de um conjunto de classes padronizadas e documentadas
que seguem um modelo consistente como o MVC traz diversos
benefcios a um projeto: padronizao; facilidade e agilidade na
manuteno; melhoria no entendimento do projeto, inclusive para novos
membros; o cdigo fica mais legvel; reutilizao de entidades; habilita
o trabalho em equipe, pois os mdulos so divididos em, no mnimo,
trs arquivos.
A partir da presente framework, podem ser desenvolvidos diversos
tipos de aplicativos que tenham as seguintes caractersticas: arquitetura
do tipo cliente x servidor; armazenamento e consulta em banco

31

32

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

de dados relacional; desenvolvimento baseado em mdulos, como

cadastros, consultas, avaliaes, etc; seja baseado na linguagem delphi
a partir de 2005 (por causa de algumas caractersticas da linguagem)
desktop.
A ferramenta RAD Studio (Delphi) foi escolhida pela sua produtividade,
principalmente em projetos desktop de pequeno e mdio porte, cliente/
servidor e com acesso a banco de dados. O framework, por sua vez,
privilegia padronizao e rapidez na programao, ou seja, tenta utilizar
o melhor da orientao a objetos e a forma rpida de desenvolvimento.
A diviso em camadas possibilitou a separao de responsabilidades do
cdigo e uma maior facilidade de manuteno.

Referncias
GAMMA, E.; JOHNSON, R.; VLISSIDES, J.; HELM, R. Design Patterns: elements of
reusable object-oriented software. 2. ed. Boston: Addison-Wesley, 1995.
KRUCHTEN, P. The Rational unified process: an introduction. Boston: Addison Wesley,
2003.
LARMAN, C. Applying UML and patterns. 2. ed. Upper Saddle River: Prentice Hall, 2002.
LOBO, E. J. R. Guia prtico de engenharia de software. So Paulo: Digerati, 2009.

Framework Orientado a Objetos Aplicado ao Desenvolvimento do IrrigaCerrado

Object Oriented Framework

Applied to the Development
of IrrigaCerrado Software

Abstract
The IrrigaCerrado software is a product under development to facilitate
the irrigation users to decide the moment and the quantity of water
to apply based on soil-water measurements. Following the directions
given by the irrigation specialist, it was realized that the software
would have a structure based on information about properties,
irrigation equipments, evaluation of irrigation performance, soilwater measurements and water irrigation planning to guide irrigation
users. Furthermore, all generated information should be stored in a
database. Based on the analysis of the necessary structure to devise
the software, it was realized the occurrence of various similar entities,
which could be reorganized by using the technique of designing
patterns. This allowed to develop a framework with the objective to
establish a base for constructing software with physical architecture of
the type client-sever. In this case, the framework was subdivided into
three layers: model, which contains the data related to the business
domain; vision, graphical interface for users; and controllers, which
define the way as the interface interact with the users and how the
system must deal with the information given.
Index terms: client-server, three-layer architecture, developing
architecture.

33