Escolar Documentos
Profissional Documentos
Cultura Documentos
CELSO LORENZETTI
incentivo.
AGRADECIMENTOS
Agradeço a todos os professores que tive o prazer de conviver durante minha vida
acadêmica e que me transmitiram muitas coisas boas, e aos outros que direta ou indiretamente
contribuíram para minha formação cultural.
Agradeço a minha esposa, pelo seu apoio e principalmente sua compreensão pela
minha ausência em muitos finais de semana, que foram dedicados ao desenvolvimento deste
trabalho.
A minha mãe, minha irmã e meu irmão, pelo apoio e incentivo que me deram durante
mais esta jornada.
A todos os amigos e colegas que de alguma forma contribuíram para que eu pudesse
chegar onde estou.
Muito obrigado!
RESUMO
The overall goal of this work is show the contributions that the construction of an
object persistence framework can bring to software development, mostly in what concerns the
flexibility, reusability and extensibility of the application.
Introdução................................................................................................................................. 14
1 Conceitos de Orientação a Objetos................................................................................... 18
1.1 Objetos.......................................................................................................................... 18
1.2 Classes .......................................................................................................................... 19
1.3 Herança versus Composição......................................................................................... 20
1.4 Polimorfismo ................................................................................................................ 21
1.5 Bibliotecas de Classes (toolkits) ................................................................................... 22
2 UML ................................................................................................................................. 23
2.1 Origem .......................................................................................................................... 23
2.2 Aplicação ...................................................................................................................... 24
2.3 Diagramas da UML ...................................................................................................... 25
2.3.1 Diagrama de Classes............................................................................................. 26
2.3.2 Diagrama de Objetos ............................................................................................ 26
2.3.3 Diagrama de Componentes................................................................................... 27
2.3.4 Diagrama de Implantação..................................................................................... 28
2.3.5 Diagrama de Caso de Uso .................................................................................... 29
2.3.6 Diagrama de Seqüência ........................................................................................ 29
2.3.7 Diagrama de Colaboração .................................................................................... 30
2.3.8 Diagrama de Estados ............................................................................................ 31
2.3.9 Diagrama de Atividade......................................................................................... 31
2.4 Diagramas e Ferramentas Utilizadas ............................................................................ 32
3 Padrões ............................................................................................................................. 34
3.1 Descrevendo Padrões de Projeto .................................................................................. 34
3.2 O Catálogo de Padrões de Projeto ................................................................................ 37
3.3 Organização do Catálogo.............................................................................................. 40
3.4 Metapadrões.................................................................................................................. 40
3.5 Padrões de Projeto e Frameworks ................................................................................ 42
4 Frameworks ...................................................................................................................... 44
4.1 Classificação dos Frameworks ..................................................................................... 45
4.2 Frameworks Caixa Branca X Caixa Preta.................................................................... 46
4.3 Vantagens e Desvantagens ........................................................................................... 48
4.4 Compreensão e Uso de Frameworks ............................................................................ 49
4.5 Personagens Envolvidos com o Desenvolvimento e Uso de Frameworks................... 50
4.6 Etapas da Construção de Frameworks ......................................................................... 52
4.7 Aprendendo como usar Frameworks............................................................................ 53
5 Análise e Modelagem do Framework .............................................................................. 54
5.1 Requisitos do Sistema................................................................................................... 54
5.2 Cenários ........................................................................................................................ 56
5.2.1 Acessar Formulário .............................................................................................. 56
5.2.2 Realizar Consulta.................................................................................................. 56
5.2.3 Incluir Registros ................................................................................................... 57
5.2.4 Copiar Registros ................................................................................................... 58
5.2.5 Modificar Registros .............................................................................................. 59
5.2.6 Excluir Registros .................................................................................................. 60
5.2.7 Consultar Chave Estrangeira ................................................................................ 60
5.3 Casos de Uso ................................................................................................................ 61
5.3.1 Acessar Formulário .............................................................................................. 62
5.3.2 Realizar Consulta.................................................................................................. 64
5.3.3 Incluir Registros ................................................................................................... 66
5.3.4 Copiar Registros ................................................................................................... 67
5.3.5 Modificar Registros .............................................................................................. 69
5.3.6 Excluir Registros .................................................................................................. 71
5.3.7 Consultar Chave Estrangeira ................................................................................ 72
5.3.8 Salvar .................................................................................................................... 75
5.4 Diagramas de Classes ................................................................................................... 76
5.4.1 Formulários........................................................................................................... 76
5.4.2 Componentes de Edição ....................................................................................... 80
5.5 Diagramas de Seqüência............................................................................................... 83
5.5.1 Realizar Consulta.................................................................................................. 83
5.5.2 Incluir Registros ................................................................................................... 84
5.5.3 Copiar Registros ................................................................................................... 85
5.5.4 Modificar Registros .............................................................................................. 86
5.5.5 Excluir Registros .................................................................................................. 87
5.5.6 Consultar Chave Estrangeira ................................................................................ 88
5.6 Diagrama de Estados .................................................................................................... 89
6 Prototipação ...................................................................................................................... 90
6.1 Aplicação Principal....................................................................................................... 90
6.2 Incluir Registros ........................................................................................................... 91
6.3 Copiar Registros ........................................................................................................... 92
6.4 Excluir Registros .......................................................................................................... 93
6.5 Consultar....................................................................................................................... 94
6.6 Visualizar Registros...................................................................................................... 95
6.7 Modificar Registros ...................................................................................................... 96
6.8 Consultar Chave Estrangeira ........................................................................................ 97
6.9 Salvar Informações ....................................................................................................... 98
Conclusão e Trabalhos Futuros ................................................................................................ 99
Referências Bibliográficas...................................................................................................... 101
INTRODUÇÃO
Lee (2001, p. 23) diz que software confiável, flexível e de fácil manutenção é difícil
de ser criado, pois os sistemas de software são complexos e essa complexidade faz parte da
essência do sistema. Isto também é citado por Bezzera (2002, p. 2) que diz que a
complexidade é uma característica intrínseca de sistemas de software e que essa
complexidade cresce, à medida que o sistema cresce.
• Aumento da produtividade;
Outros objetivos que se pretende com este trabalho e que podem ser citados são os
seguintes:
1
Notação para a elaboração da estrutura de projetos de software orientados a objetos
1 CONCEITOS DE ORIENTAÇÃO A OBJETOS
Programar um computador não é uma tarefa simples, pois mesmo com a ajuda de
muitas ferramentas, um programador deve ter inteligência, lógica, experiência, criatividade e
habilidade de localizar e utilizar abstrações para desenvolver software com qualidade. Neste
sentido, o paradigma2 da OO (Orientação a Objetos) busca mostrar um nova maneira para
descrevermos a nossa visão (modelo) da realidade (LEE, 2001, p. 24). Este capítulo apresenta
algumas das propriedades deste paradigma da OO que auxiliam a administrar a complexidade
encontrada no desenvolvimento de software.
1.1 Objetos
Programas orientados a objetos são feitos de objetos. Um objeto pode ser definido
como uma unidade de software que é formado por dados (atributos) e procedimentos
(métodos) que operam sobre estes dados. Os procedimentos são chamados de métodos
(operações) que são executados através de uma solicitação (mensagem) de um outro objeto.
O objeto que envia a mensagem é chamado de cliente e o que recebe de receptor. Os dados
dos objetos não podem ser acessados diretamente por outro objeto, a única maneira de mudar
os dados internos dos objetos é através dos métodos, por isso diz-se que o estado interno dos
objetos está encapsulado e sua representação é invisível do exterior do objeto (GAMMA,
2000, p. 27; LEE, 2001, p.24).
Os métodos que um objeto disponibiliza aos outros objetos para acessarem seus
dados internos, são chamados serviços públicos, porém um objeto possui outros métodos que
são restritos unicamente a outros objetos específicos e são chamados de serviços protegidos e
serviços privados (LEE, 2001, p. 25).
19
Todos os objetos tem uma identidade única e são distinguíveis. O termo identidade
significa que um objeto é identificado pela sua própria existência, embora dois objetos da
mesma classe podem conter dados iguais, eles são dois objetos distintos. Os dados de um
objeto representam o estado atual do objeto. (RUMBAUGH, 1994, p. 32).
Todos os objetos são criados a partir da instância de uma classe, portanto a definição
dos métodos e atributos de um objeto pertencem a classe a qual ele instancia. Diz-se que um
objeto é uma instância da classe. As instâncias podem ser criadas (geradas) ou destruídas
(eliminadas) em tempo de execução (LEE, 2001, p. 28).
1.2 Classes
Uma classe descreve um grupo de objetos com atributos idênticos, mesma semântica
e com comportamento e relacionamentos comuns. Cada objeto em um classe terá os mesmos
atributos e padrões de comportamento (LEE, 2001, p. 179; RUMBAUGH, 1994, p. 32). Uma
classe define o estado interno do objeto e a sua representação define as operações ou métodos
que o objeto pode executar (GAMMA, 2000, p. 30).
2
Paradigma é definido como um “conjunto de teorias, padrões e métodos que juntos representam um modo de
organizar conhecimento” (LEE, 2001, p. 24)
20
1.4 Polimorfismo
A palavra polimorfismo vem do grego e significa “várias formas”. Ela pode ser
definida como um dispositivo pelo qual o nome de um método pode ser definido sobre mais
de uma classe e pode assumir diferentes implementações em cada uma dessas classes (PAGE-
JONES, 1997, p. 34).
Cada operação declarada por um objeto é definida por um nome, os objetos que ela
aceita como parâmetros e o valor que ela irá retornar, a isto chama-se assinatura da operação.
O conjunto de todas as operações definidas por um objeto é chamado de interface do objeto.
Uma interface é denominada um tipo, portanto, quando diz-se que um objeto tem o tipo “x”,
por exemplo, significa que ele aceita todas as operações definidas na interface chamada “x”.
Um objeto pode possuir várias operações com mesmo nome, porém com assinaturas
diferentes, então quando uma solicitação é enviada a um objeto, a operação que será
executada depende da operação e do objeto receptor. A associação de qual operação será
executada é feita em tempo de execução e é chamada de ligação dinâmica (GAMMA, 2000,
p. 29).
22
A ligação dinâmica permite substituir objetos que tenham interfaces idênticas uns
pelos outros e é também conhecida como polimorfismo (Ibidem).
Em virtude dos toolkits terem que funcionar em muitas aplicações para serem úteis, o
projeto de toolkits é consideravelmente mais difícil que o projeto de aplicações. Isto porque o
autor do toolkit não está numa posição que lhe permita saber quais serão estas aplicações ou
suas necessidades especiais. Isto torna ainda mais importante evitar suposições e
dependências que podem limitar a flexibilidade do toolkit e consequentemente sua
aplicabilidade e sua efetividade (Ibidem).
3
A reutilização de código se dará principalmente nas aplicações que usarem o framework, embora na própria
construção do framework haverá reutilização de código.
2 UML
2.1 Origem
4
O método Booch era expressivo principalmente durante as fases de projeto e construção de sistemas.
5
O método OOSE (Object Oriented Software Engineering) fornecia excelente suporte para a análise e projeto
em alto nível
6
O método OMT (Object Modeling Technique) era mais útil para análise e sistemas de informações com o uso
intensivo de dados.
24
2.2 Aplicação
7
Uma entidade que fornece diretrizes para a indústria de software, através de especificações de padrões.
25
Embora a UML não seja uma linguagem visual de programação, pode ser utilizada
para a construção, pois seus modelos podem ser diretamente conectados a várias linguagens
de programação. Isso significa que é possível mapear os modelos da UML em linguagens de
programação tais como Java, C++, Visual Basic ou até tabelas de bancos de dados relacionais
ou o armazenamento de dados persistentes em um banco de dados orientado a objetos.
Enquanto as linguagens de programação representam o que é melhor expresso em termos
textuais, a UML é utilizada para representar tudo que possa ser melhor expresso em termos
gráficos (Ibidem).
Segundo Booch, quando uma pessoa realiza uma modelagem, ela simplifica a
realidade para um melhor entendimento do sistema em desenvolvimento. Em UML os
modelos são desenvolvidos a partir de blocos de construção básicos, como classes, interfaces,
colaborações, componentes, nós, dependências, generalizações e associações. Os diagramas
são meios utilizados para visualização desses blocos de construção (BOOCH, 2000, p. 89).
Diagrama de atividade
Uma classe em UML é representada por uma caixa retangular com três
compartimentos: o primeiro com o nome da classe, o do meio com a lista de atributos da
classe e o último com a lista de operações da classe. As associações representam
relacionamentos estruturados entre objetos de diferentes classes, e são representados
graficamente através de uma linha conectando as classes. Uma associação pode ter um nome,
e as extremidades da linha que representa uma associação pode ter nome de papéis mostrando
como a classe é vista pelas outras classes na associação, conforme mostra a figura 2-1
(BEZERRA, 2002, p. 97).
Conforme mostra a figura 2-6, os objetos são representados por linhas tracejadas
verticais, e a troca de mensagens entre dois objetos é representada por vetores horizontais
identificados pela mensagem que está sendo passada. As mensagens são desenhadas em
ordem cronológica do topo à base do diagrama (LEE, 2001, p. 52).
30
O estado é uma situação na vida de um objeto durante a qual ele satisfaz alguma
condição ou realiza alguma atividade. Um evento é a ocorrência de um estímulo capaz de
ativar uma transação de estado. Uma transição é um relacionamento entre dois estados e
indica que se ocorrer um determinado evento e as condições forem satisfeitas, o objeto
realizará certas ações e passará de um estado para outro (Ibidem).
A UML apresenta nove diagramas diferentes que podem ser utilizados para
representar a modelagem de um sistema. No entanto, neste trabalho serão utilizados apenas os
diagramas necessários para modelar o domínio do problema de forma consistente e que
facilite a sua compreensão, implementação e manutenção. Os diagramas utilizados foram os
seguintes: Diagrama de Caso de Uso, Diagrama de Classes, Diagrama de Estados e Diagrama
de Seqüência.
Para realizar a modelagem foi estudado a viabilidade de uma dentre três ferramentas
encontradas no mercado. As ferramentas pesquisadas foram as seguintes:
Optou-se por utilizar a ferramenta ModelMaker©, por ser integrada com o ambiente
de desenvolvimento Delphi© da Borland, com o qual foi implementado o protótipo para o
framework. Convém ressaltar que a Rational Rose Enterprise Edition©, é uma ferramenta mais
completa, porém é paga e sua utilização é permitida apenas por 30 dias. O Poseidon for
UML© é uma ferramenta freeware mais não foi adotada por deficiências da ferramenta em
disponibilizar um formato de arquivo que não utiliza-se muita memória para exportar os
diagramas e não possuir uma opção para gerar a documentação das classes no formato do
Microsoft© Word.
A origem dos padrões de projeto deu-se com o trabalho feito pelo arquiteto
Christopher Alexander no final dos anos 70, que além de exemplificarem, descrevem seu
método para documentação de padrões. O trabalho de Alexander, apesar de ser voltado para a
arquitetura, possui uma fundamentação básica que pode ser abstraída para a área de software
(GERBER, 1999, p. 24).
mesmos utilizem uma forma única de documentação de padrões. Os elementos utilizados para
descrever um padrão são muito importantes uma vez que eles contêm todas as informações
que se precisa para poder entendê-los e utilizá-los de forma apropriada em projetos.
Segundo Gamma (2000, p. 22) e Vlissides (1995, p. 2), os elementos que descrevem
um padrão de projeto são:
Estes elementos apresentados acima devem, segundo o livro da Gang Of Four, estar
Padrão Intenção
Padrão Intenção
Command Encapsula uma solicitação como um objeto, desta forma permitindo que
se parametrize clientes com diferentes solicitações, enfileire ou registre
(log) solicitações e suporte operações que podem ser desfeitas.
Factory Method Define uma interface para criar um objeto, mas deixa as subclasses
decidirem qual classe a ser instanciada. O factory method permite a uma
classe postergar a instanciação às subclasses.
Interpreter Dada uma linguagem, define uma representação para sua gramática
juntamente com um interpretador que usa a representação para interpretar
sentenças nesta linguagem.
Padrão Intenção
Sigleton Garante que uma classe tenha somente uma instância e fornece um ponto
global de acesso para ela.
State Permite que um objeto altere seu comportamento Quando seu estado
interno muda. O objeto parecerá ter mudado sua classe.
O critério escopo especifica se o foco do padrão é dado sobre classes ou objetos, que
podem ser class (classe) ou object (objeto). Em resumo, padrões com escopo classe trabalham
com relacionamentos entre classes e subclasses, através do mecanismo de herança, e padrões
com escopo objeto trabalham com relacionamentos entre objetos, obtidos através do
mecanismo de composição de objetos (Ibidem, p. 26).
3.4 Metapadrões
por exemplo, a questão do estado de um objeto ser alterado em função da mudança de estado
de outro objeto, tratada pelo padrão de projeto Observer. Os metapadrões trabalham em um
nível de abstração superior, em relação aos padrões de projeto. Definem como manter a
flexibilidade das classes, encapsulando a funcionalidade sujeita a alteração em métodos hook,
chamados por métodos template8 (Ibidem).
8
Um método template é um método que ao ser executado invoca pelo menos um outro método – um método
hook. O método template comporta a parte imutável de um procedimento. A flexibilização de um procedimento
ocorre através da troca do(s) método(s) hook invocado(s) (SILVA, 2000).
9
Esta noção de estabilidade se refere ao fato de que um framework que foi utilizado para gerar poucas
aplicações, possivelmente precisará ser alterado (a medida em que novas informações de domínio são obtidas, a
partir do desenvolvimento de novas aplicações). Apenas um framework usado para gerar muitas aplicações de
um domínio, chega a uma estrutura menos sujeita a alterações (GAMMA, 2000).
42
Frameworks estão se tornando cada vez mais comuns e importantes. Eles são a
maneira pela qual sistemas orientado a objetos conseguem um maior grau de reutilização.
Aplicações maiores orientada a objetos terminarão por constituir-se de camadas de
frameworks que cooperam uns com os outros. A maior parte do projeto e do código da
aplicação virá dos, ou será influenciada pelos frameworks que utiliza (Ibidem).
responsabilidades entre um conjunto de classes (ao invés de concentrar sobre uma classe)
procurando mantê-las o mais desacopladas possível. A flexibilidade proporcionada pela
utilização de padrões de projeto e metapadrões na construção do framework para persistência
de dados é outro benefício que será obtido com a utilização do framework para o
desenvolvimento de aplicações.
Ainda de acordo com a Gang Of Four '', o framework dita a arquitetura da aplicação.
Ele irá definir toda a estrutura, sua divisão em classes e objetos, as responsabilidades do
framework, como as classes e objetos colaboram, e o fluxo de controle. Um framework
predefine estes parâmetros de projeto, então o projetista/implementador da aplicação, pode se
concentrar nas especificidades da aplicação. Um framework captura as decisões que são
comuns ao domínio da aplicação. Frameworks então enfatizam o reuso de projeto mais do que
o reuso de código, ainda que um framework possa normalmente incluir subclasses concretas
que podem ser utilizadas imediatamente (Ibidem, p. 42).
Johnson afirma que o ideal é que cada framework caixa branca evolua para um
framework caixa preta, por isso os frameworks caixa branca devem ser vistos como uma fase
natural na evolução de um sistema, que será algum dia um passo na evolução de uma coleção
de métodos em um conjunto de componentes.
dentro de um mesmo domínio são distinguidas por um ou mais hot-spots. Eles representam as
partes do framework de aplicação que são específicas de cada sistema. Os hot-spots são
projetados para serem genéricos, mas podem ser adaptados às necessidades de cada aplicação
(MALDONADO, 2001, p. 23).
A figura 4-3 ilustra um framework caixa preta, também com um único hot-spot R.
Nesse caso, existem três alternativas (R1, R2 e R3) para implementação da responsabilidade
R. O desenvolvedor irá escolher uma delas para obter sua aplicação específica. Note que R1,
R2 e R3 fazem parte do framework e são as únicas alternativas possíveis de implementação do
hot-spot. Já no caso da figura 4-2 R3 não fazia parte do framework, mas, em compensação,
qualquer alternativa de implementação do hot-spot seria possível (Ibidem).
o framework caixa preta é mais fácil de usar, pois basta escolher a implementação desejada,
enquanto no caixa branca é necessário fazer essas implementações, além de conhecer a
estrutura interna do framework (FAYAD, 1997, p. 3; MALDONADO, 2001, p. 24).
Frameworks caixa branca podem evoluir para se tornar cada vez mais caixa preta
(JOHNSON, 1997, p. 3). Isso pode ser conseguido de forma gradativa, implementando-se
várias alternativas que depois podem ser utilizadas na instanciação do framework. Ao mesmo
tempo não se fecha totalmente o framework, permitindo ao usuário continuar usando-o como
caixa branca e após determinado tempo, que diversas alternativas estejam disponíveis pode-se
decidir tornar o framework caixa preta. A medida em que o framework vai se tornando mais
caixa preta, diminui o número de objetos criados, embora aumente a complexidade das suas
interconexões (MALDONADO, 2001, p. 24).
framework reage, no lugar de cada aplicação, invocando métodos pré definidos que executam
processos específicos, em resposta a eventos externos10.
10
Respostas do usuário a uma solicitação do sistema ou pacotes que chegam em portas de comunicação.
50
Frameworks
11
Documentação onde mostra exemplos passo a passo de como utilizar o framework.
51
Segundo Johnson (apud SILVA, 2000, p. 63) para se obter um framework com uma
estrutura de classes flexível é necessário seguir princípios de projeto orientado a objetos,
como o uso de herança para a reutilização de interfaces, ao invés do uso de herança para a
reutilização código (a delegação é mais adequada que o uso indevido de herança); reutilização
de código através de composição de objetos; preocupação em promover polimorfismo na
definição de classes e métodos, de modo a possibilitar acoplamento dinâmico, etc.
Este capítulo falará sobre as funções desempenhadas pelo sistema para os usuários
que utilizarão o framework. Apresentará também a modelagem realizada para a construção e
documentação do framework, que é composta por: cenários, diagrama de casos de uso,
diagrama de classes, diagrama de seqüências e diagrama de estados.
Outro usuário que será beneficiado com a adoção do framework, será o usuário que
utilizará a aplicação desenvolvida sobre a arquitetura deste framework. Para isto, alguns
requisitos devem ser atendidos, visando facilitar a interação do usuário com a aplicação.
Dentre os requisitos, pode-se citar os seguintes:
5.2 Cenários
Um cenário é uma pequena história que descreve uma seqüência esperada de ações e
respostas entre um usuário e o sistema. Ele é utilizado para apresentar como um usuário
emprega o sistema para atingir seu objetivo (LEE, 2001, p. 44).
Nos cenários abaixo, os passos serão descritos sempre através de uma opção. Cada
opção terá um botão e um item de menu correspondente no formulário, que poderá ser
acessado através do mouse ou pelo teclado através de uma tecla de atalho, que poderá ser
vista, posicionando-se o mouse sobre o botão.
Para realizar uma consulta, o usuário deverá acessar a opção de menu que
disponibiliza o acesso a tabela que ele deseja consultar. O método ChamaForm irá instanciar
um formulário que apresentará todos os campos disponíveis na tabela, para serem
preenchidos. O usuário irá entrar em modo de consulta, através da opção consultar.
para encontrar o(s) registro(s). Nesta operação não haverá validação dos valores informados
como características. Quando o usuário informar a(s) característica(s) do(s) registro(s) que
procura, irá executar a consulta através da opção executar. A última consulta executada é
mantida em memória e pode ser executada novamente através do menu Opções / Última
Consulta ou da tecla de atalho F12.
Caso o usuário queira cancelar a consulta e voltar ao modo de edição, fará através da
opção cancelar.
Para incluir registros, o usuário deverá acessar a opção de menu que disponibiliza o
acesso a tabela que ele deseja incluir novos registros. O método ChamaForm irá instanciar um
formulário, em modo normal, que apresentará todos os campos disponíveis na tabela, para
serem preenchidos. O usuário irá incluir um registro através da opção incluir. O registro virá
preenchido com os valores default de cada campo, que foram definidos no banco de dados.
Caso o usuário não conheça o valor a ser informado em um campo, que possua uma
chave estrangeira, poderá realizar uma consulta aos valores existentes na tabela referenciada,
através do botão BuscaFk. O botão BuscaFk está posicionado ao lado do campo, ou da tecla
58
de atalho F9. Uma vez encontrado o registro o usuário pode selecioná-lo e retornar para o
formulário de inclusão, concluindo a inclusão do registro.
Após ter sido informado os valores para o registro, o usuário poderá incluir novos
registros através da opção incluir, que chamará o método Append da classe TArea, que é
responsável por criar um novo registro e atribuir os valores default de cada campo.
Quando o usuário informar todos os valores, irá salvar o(s) registro(s) através da
opção salvar, que irá executar o método ApplyUpdates da classe ClDataSet. O método
ApplyUpdates é o responsável por inserir os registros no banco de dados. Caso ocorra algum
problema na inclusão do registro, as mensagens de erro serão apresentadas ao usuário e
nenhuma inclusão será realizada.
Para copiar um registro, o usuário irá efetuar os passos descritos no cenário 5.2.2
Realizar consulta. Após ter selecionado o registro que deseja copiar, irá realizar a cópia do
registro através da opção copiar. Nesta operação os valores de todos os campos serão
copiados, exceto a chave primária do registro, que deverá ser informada pelo usuário. O
usuário poderá alterar o valor de qualquer campo antes de salvar o registro.
Caso o usuário não conheça o valor a ser informado em um campo, que possua uma
chave estrangeira, poderá realizar uma consulta aos valores existentes na tabela referenciada,
através do botão BuscaFk. O botão BuscaFk está posicionado ao lado do campo, ou da tecla
59
de atalho F9. Uma vez encontrado o registro o usuário pode selecioná-lo e retornar para o
formulário de inclusão, concluindo a inclusão do registro.
Quando o usuário informar todos os valores, irá salvar o(s) registro(s) através da
opção salvar, que irá executar o método ApplyUpdates da classe ClDataSet. O método
ApplyUpdates é o responsável por inserir os registros no banco de dados. Caso ocorra algum
problema na inclusão do registro, as mensagens de erro serão apresentadas ao usuário e
nenhuma inclusão será realizada.
Para modificar um registro, o usuário irá efetuar os passos descritos no cenário 5.2.2
Realizar consulta. Após ter selecionado o registro que deseja alterar, entrará com os novos
valores. Não é permitido alterar a chave primária do registro.
Caso o usuário não conheça o valor a ser informado em um campo, que possua uma
chave estrangeira, poderá realizar uma consulta aos valores existentes na tabela referenciada,
através do botão BuscaFk. O botão BuscaFk está posicionado ao lado do campo, ou da tecla
de atalho F9. Uma vez encontrado o registro o usuário pode selecioná-lo e retornar para o
formulário de inclusão, concluindo a inclusão do registro.
Quando o usuário informar todos os valores, irá salvar o(s) registro(s) através da
opção salvar, que irá executar o método ApplyUpdates da classe ClDataSet. O método
ApplyUpdates é o responsável por alterar os registros no banco de dados. Caso ocorra algum
60
Para excluir um registro, o usuário irá efetuar os passos descritos no cenário 5.2.2
Realizar consulta. Após ter selecionado o registro que deseja excluir, irá realizar a exclusão
do registro através da opção excluir. Nesta operação será executado o método ExecutaExcluir
que irá definir se é permitido excluir o registro, com base nas regras de negócio
implementadas pelo desenvolvedor da aplicação.
Se for permitido excluir o registro, este será marcado para exclusão e não ficará
disponível para visualização do usuário. Caso não seja permitido a exclusão, será apresentado
uma mensagem ao usuário informando o motivo.
Quando o usuário marcar todos os registros que deseja excluir, irá efetivar a exclusão
no banco de dados através da opção salvar, que irá executar o método ApplyUpdates da classe
ClDataSet. O método ApplyUpdates é o responsável por excluir os registros no banco de
dados. Caso ocorra algum problema na exclusão do registro, as mensagens de erro serão
apresentadas ao usuário e nenhuma exclusão será realizada.
tabela que está sendo consultada, porém só é permitido restringir a consulta por um dos
campos. Após o usuário realizar a consulta é possível aplicar mais um filtro no resultado da
consulta para torná-la mais seletiva e/ou ainda classificar o resultado em ordem ascendente ou
descendente por qualquer campo da tabela que esteja sendo visualizado pelo usuário. Para
classificar basta clicar sobre o título de uma das colunas do browse.
Esta seção apresentará os casos de uso que descrevem as interações do usuário com
sistema, que busca através dos diagramas facilitar o entendimento de como funcionará o
framework.
62
3. Selecionar incluir.
4. Cria um novo registro com os valores
default informados no banco de dados.
5. Preenche os campos disponíveis na tela.
6. Valida as informações digitadas e arma-
zena em memória.
7. Salva as informações.
8. Iniciar “Salvar”.
Seqüência alternativa
Linha 5: Iniciar “Consultar Chave Estrangeira”.
Linha 6: Informações inválidas. Executar linha 5.
Linha 7: Cancela a inclusão do registro e volta ao status de normal.
Casos de uso relacionados
Consultar Chave Estrangeira
Salvar
Seqüência alternativa
Linha 5: Iniciar “Consultar Chave Estrangeira”
Linha 6: Informações inválidas. Executar linha 5.
Linha 7: Cancela a inclusão do registro e volta ao status de normal.
Casos de uso relacionados
Realizar Consulta
Consultar Chave Estrangeira
Salvar
5.3.8 Salvar
Segundo Johnson, um framework pode ser definido como “um projeto reutilizável de
uma parte ou de todo um sistema, que é representado por um conjunto de classes abstratas e
pelo modo que elas interagem” (JOHNSON, 1997, p. 39). Então nesta seção, serão
apresentadas as principais classes que compõem o framework. Para uma melhor apresentação,
elas foram dividas em duas categorias, segundo suas funcionalidades dentro do framework.
5.4.1 Formulários
12
Documentação eletrônica disponibilizada em CD, composta por: documentação das classes, script de criação
do banco de dados, executável e arquivos necessários para rodar a aplicação teste.
77
A classe TFrmBase, apresentada pela figura 5-11, é a classe mais genérica que foi
implementada, ou seja, é que está mais acima na hierarquia de classes e ela implementa um
método chamado Validar, que percorre o formulário procurando por objetos de edição de
dados, que são apresentados na figura 5-16, e executa o método onValida de cada objeto,
retornando se existe alguma inconsistência ou não nos objetos do formulário. Está é uma das
principais classes do framework porque todos os formulários deverão herdar dela, sendo
assim, se for necessário implementar novas funcionalidades no framework e que precisem ser
disponibilizadas em todos os formulários, esta será a classe que sofrerá as alterações. Outra
classe também muito importante é a TFrmCadastro, que é apresentada pela figura 5-15 e
herda de TFrmBase. As funções de inclusão, alteração, consulta e exclusão de registros foram
implementadas nesta classe, portanto os formulários de cadastro deverão herdar desta classe.
A outra classe é a TClDbEdit, que é mais genérica e aceita todos os tipos de valores,
porém não possui tratamento de erros para valores do tipo data e número. Esta classe deve ser
utilizada para receber valores do tipo caracter. Esta classe possui uma propriedade onde pode
ser informado uma máscara para o valor que será exibido, facilitando assim a visualização. As
máscaras disponíveis são para formatar: CNPJ, CPF, CEP, CFOP e telefone, porém outras
máscaras podem ser adicionadas. A figura 5-19 é um exemplo desta classe com uma máscara
para CNPJ.
Outras classes para edição dos dados foram implementadas, como a TClDbMemo,
TclDbCheck e a TClDbComboBox, e ainda outras classes auxiliares que podem ser vistas na
documentação eletrônica deste trabalho13.
13
Documentação eletrônica disponibilizada em CD, composta por: documentação das classes, script de criação
do banco de dados, executável e arquivos necessários para rodar a aplicação teste.
82
Este diagrama descreve a seqüência de eventos que ocorrerá para realizar uma
consulta ao banco de dados, através de um formulário de cadastro.
Este diagrama descreve a seqüência de eventos que ocorrerá ao ser incluído novos
registros no banco de dados, através de um formulário de cadastro.
Este diagrama descreve a seqüência de eventos que ocorrerá quando for alterado um
registro existente no banco de dados, através de um formulário de cadastro
Este diagrama descreve a seqüência de eventos que ocorrerá quando for excluído um
registro do banco de dados, através de um formulário de cadastro.
Este diagrama descreve a seqüência de eventos que ocorrerá quando o usuário estiver
em um formulário de cadastro e realizar uma consulta em uma tabela que possua referência
através de uma chave estrangeira.
A figura 6-1 apresenta uma sugestão de tela inicial para uma aplicação que seja
desenvolvida utilizando a arquitetura do framework. Ela é composta basicamente por uma
estrutura de menus (a esquerda) que identifica cada tabela do sistema e que conhece a classe
responsável pela manutenção das informações nesta tabela. Na parte superior direita possui
uma área (não implementado, apenas uma idéia), onde o usuário poderá criar atalhos para as
opções que mais utiliza no sistema e na parte inferior o sistema irá registrar as últimas opções
acessadas pelo usuário (não implementado, apenas uma idéia).
14
Documentação eletrônica disponibilizada em CD, composta por: documentação das classes, script de criação
do banco de dados, executável e arquivos necessários para rodar a aplicação teste.
91
Todos os passos para incluir novos registros foram descritos no capítulo 5 e podem
ser vistos no cenário 5.2.3 Incluir Registros.
O formulário apresentado pela figura 6-3, exibe um registro sendo copiado através da
opção copiar, onde todos os valores são automaticamente copiados para um novo registro e
apenas a chave primária do novo registro precisa ser informada pelo usuário. Esta
funcionalidade é útil quando se precisa incluir um registro muito semelhante a outro já
existente no banco de dados.
Todos os passos para se copiar um registro foram descritos no capítulo 5 e podem ser
vistos no cenário 5.2.4 Copiar Registros.
6.5 Consultar
Quando o código procurado não existir é possível incluí-lo sem sair do formulário,
através do botão cadastrar, que criará uma instância da classe responsável pela manutenção
dos dados da tabela, então o usuário cadastra e volta para a consulta.
Quando o usuário solicitar que um registro seja salvo no banco de dados, ele passará
pelo processo de validação que verifica se os valores informados atendem as regras de
negócio implementadas, se a integridade referencial é atendida e se algum campo deve ser
preenchido. Caso alguma inconsistência seja encontrada é apresentado um formulário com
todas as mensagem, conforme é apresentado na figura 6-9, e o registro não é salvo sem que
todas elas sejam atendidas.
Com frameworks bem projetados fica muito mais fácil fazer extensões, fatorar a
funcionalidade comum, promover a interoperabilidade e melhorar a manutenção e
confiabilidade do software.
100
Então, como trabalhos futuros é possível se criar pequenos frameworks, que são
chamados framelets (PREE, apud CRESPO, 2000, p. 22), e que complementariam as
funcionalidades básicas necessárias em um sistema de gestão empresarial.
Pode-se citar dois framelets que poderiam ser construídos: um para automatizar a
criação de relatórios cadastrais, onde o próprio usuário definisse o layout do relatório e os
filtros que seriam aplicados. Outro framelet poderia ser construído para servir como base para
a criação de formulários de consultas e de emissão de relatórios administrativos, onde fossem
implementadas funcionalidades para facilitar a interação do usuário com o sistema. É
importante lembrar que um dos objetivos é que estas funcionalidades não tragam mais
trabalho para o desenvolvimento das aplicações, pois se isso ocorrer, ficaria sem sentido o
desenvolvimento de tais framelets.
REFERÊNCIAS BIBLIOGRÁFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, Guia do Usuário. Rio de
Janeiro: Campus, 2000. 472p.
MALDONADO, José Carlos et al. Padrões e Frameworks de Software. São Paulo: 2001. 37
p. Instituto de Ciências Matemáticas e de Computação, USP, 2001. Disponível em:
<http://www.icmc.sc.usp.br/~rtvb/apostila.pdf>. Acesso em: 07 de nov. 2003.
VLISSIDES, John. Pattern Hatching: Perspectives from the “Gang of Four”. Mar 1995.
Disponível em: <http://www.research.ibm.com/designpatterns/pubs/pathatch.html>. Acesso
em: 02 nov. 2003.