Академический Документы
Профессиональный Документы
Культура Документы
Desenvolvimento
SpeedCASE i
Apresentação
Neste documento você encontrará material de apoio para conhecimento dos fundamentos da
ferramenta SpeedCASE.
Tecn
TecnoSpeed TI
TecnoSpeed Tecnologia da Informação Ltda
Avenida João Paulino Vieira Filho, 672, Sala 305
87020-015 – Zona 7 – Maringá – PR
Tel. (44) 3225-7788
E-mail: speedcase@speedcase.com.br
Web Site: http://www.speedcase.com.br
Sumário
1. Framework SpeedCASE
Esta seção descreve os principais aspectos do framework de aplicações empresariais SpeedCASE™.
GUI BO OPF
Apresentação Objetos de Negócio Persistência dos Dados
(Interação com usuário) (Regras de Negócio) (Banco de dados)
1.1.1 Apresentação
Essa camada encarrega-se de pegar os dados vindos dos objetos de negócio e apresentá-los ao usuário, é
responsável ainda por controlar a interação entre o cliente (o usuário-final) e o sistema (objetos de negócio).
nesta camada encontramos o GUIBuilder, construtor de objetos gráficos (botões, caixas de texto etc) e o
Layout organizador de objetos gráficos (disposição dos controles nas telas).
Camada responsável pela captura das regras de negócio da aplicação. Essa camada é composta por
classes básicas como: TboClass e TboAttribute, que permitem por meio de sua especialização (herança)
que o desenvolvedor defina suas classes e codifique suas regras para o domínio de suas aplicações.
Como uma camada intermediária ele interage entre a GUI e o OPF é responsável pelas funcionalidades do
sistema, suporta a criação de objetos voláteis (não armazenados) e persistentes (armazenados em banco).
Podemos considerar que os Objetos de Negócio são uma coleção de objetos, o núcleo do sistema.
Camada responsável pelo mapeamento (O/R Mapping) e gravação em banco dos objetos da aplicação.
Colabora diretamente com a camada de Objetos de Negócio transformando objetos em memória em
atributos, tabelas e registros em banco e assegurando a possibilidade de sua posterior restauração.
A camada de persistência possui compatibilidade com os SGDBR padrão ANSI-SQL92. Ela isola os
acessos realizados diretamente ao banco de dados pela aplicação, bem como centraliza os processos de
construção de consultas (queries), operações de manipulação de dados (insert, update e delete) e a criação
de procedimentos armazenados (stored-procedures) em uma camada de objetos transparente ao
programador.
1.2. Modularização
Trata-se de dividir seu projeto em unidades (módulos) com o máximo de independência. Assim, essas
unidades poderão se tornar intercambiáveis, ou seja, podem ser substituídas por outras ou ainda serem
retiradas do projeto sem que outras unidades tenham que ser alteradas. Na SpeedCASE™ existem duas
categorias de módulos, os dinâmicos e os estáticos.
Módulos dinâmicos são aqueles que geram um arquivo BPL (Borland Package Library) independente do
arquivo executável. Esse arquivo é linkado ao executável em tempo de execução (late-binding), podendo
ser removido do projeto sem que o mesmo tenha que ser recompilado (como um plugin). A ferramenta
beneficia-se desse conceito para gerar um instalador da aplicação final onde pode-se escolher quais
módulos serão instalados. Assim, selecionam-se quais funcionalidades o programa terá no momento de sua
instalação.
Os Módulos estáticos por sua vez, são adicionados na cláusula "uses" do projeto e compiladas juntamente
com o mesmo, logo, não podem ser adicionados ou removidos sem a compilação do projeto.
1.3. Distribuição
Cada distribuição possui uma lista de módulos, tanto estáticos quanto dinâmicos, que a constitui. Isso
acelera o processo de geração de fonte e de compilação, já que a ferramenta gera e compila apenas o que
diz respeito à distribuição ativa. Além disso, possibilita que desenvolvedores trabalhem no mesmo projeto,
mas em distribuições diferentes onde o erro de compilação de um não atrapalha o andamento das
atividades do outro.
As distribuições podem ser consideradas como resultados de um projeto, ou executáveis, onde, um projeto
pode gerar “n” distribuições de acordo com a necessidade do desenvolvedor, cada distribuição representa
uma aplicação final, assim, um projeto modular pode criar diversas versões de aplicativos através das
combinações de seus módulos.
1.4. Proxy
Pode-se definir um proxy como sendo uma visão de uma classe. O desenvolvedor, cria um proxy e
determina em sua composição todos os atributos e métodos da classe os quais ele deseja que sejam vistos
pelo usuário. Depois, ao chamar a tela de navegação ou edição dessa classe, pode-se informar qual visão
utilizar, e apenas os campos determinados nela serão mostrados.
Os proxies também são responsáveis pela criação dos Scripts SQL, exibindo sua composição de forma
gráfica e de fácil manipulação.
Estes métodos podem ser usados como “botões” nas janelas, bastando para isso marcá-los no proxy
desejado, ou ainda usados como eventos para os menus.
Por padrão, esse módulo é criado com uma unit e uma classe base. Essa classe, chamada TGuiBoClass,
especializada da classe base de persistência do framework da ferramenta TCustomGuiBoClass para que
possam ser adicionados funcionalidades da Gui (interface do aplicativo). A classe TGuiBoClass possui
métodos GuiProcedure que realizam as operações básicas de adicionar um registro (GuiBoAppend), editar
um registro (GuiBoEdit), apagar um registro (GuiBoDelete), para visualizar um registro (GuiBoView) e para
utilizar o recurso de compartilhamento de registro (GuiBoAppendOverlapping). Esses métodos, se marcados
nos proxies, se transformarão em botões na janela de navegação de uma classe.
Assim, a classe TGuiBoClass tem a finalidade de facilitar a integração das classes definidas pelo
desenvolvedor e a interface da aplicação. Para fazer uso, basta utilizá-la como classe base para todas as
classesBo.
1.8. Plugins
Plugins são partes da ferramenta e da aplicação final que podem ser trocadas sem acarretar qualquer
alteração estrutural (código-fonte).
Eles podem ser classificados de acordo com a camada da aplicação em que atuam. A figura abaixo mostra
quais são essas camadas.
Conexão(API): Camada de conexão direta com banco de dados. A utilização deste plugin permite
que uma mesma aplicação possa utilizar diferentes bancos de dados. Dentre os plugins disponíveis,
o DBXConnection permite a conexão com os bancos Interbase® , Firebird® e MySQL®. Já o
ADOConnection torna possível a utilização do Microsoft® SQLServer®; Outras API’s poderão ser
criadas e utilizadas pela aplicação final sem impacto no código-fonte, como Zeos® para utilizar o
MySql® e ODAC® para o Oracle®.
Acesso a Dados (BoAccess): Esta camada controla os dados vindos do banco utilizando-se o
plugin de conexão, fazendo assim a ligação entre a camada de persistência e a aplicação. No
momento apenas um plugin está disponível, o DB-Aware, que utiliza os componentes do Delphi®
(ClientDataSet, DataSetProvider, DbGrids,etc...). Futuramente poderemos realizar o acesso através
de outras suítes, como Interbase Objects (IBO), DBIsam, Advantage Database Server, entre outros;
Construtor de Interface (GUIBuilder): é o plugin responsável pela criação dos elementos que vão
constituir a interface com o usuário. O VCLGUIBuilder constrói esses objetos utilizando os
componentes da VCL do Delphi®. A VCL é uma biblioteca que acompanha o Delphi® e que possui
componentes como botões, menus, campos de entrada de dados, painéis, formulários, etc. Novos
Builders poderão ser criados como, por exemplo: CLX para utilizar componentes “cross-plataform”
ou IW para aplicações Web.
Novos plugins podem ser adicionados à ferramenta, permitindo extensão das funcionalidades das camadas.
Entretanto, aos mais aventureiros, a ferramenta permite sua extensão pelos seus usuários, ou seja, com
conhecimento mais aprofundado os próprios usuários do SpeedCASE™ podem desenvolver novos plugins
para cada uma das suas camadas.
O dicionário de dados pode armazenar vários projetos em um unico local (banco de dados), para este
recurso damos o nome de Central de Projetos, onde os desenvolvedores possuem controle de acesso aos
projetos e seus módulos, proporcionando segurança, facilidade de bakup e centralização do código-fonte.
O Identificador Handle é gerado automaticamente pelo mapeador objeto-relacional, cada classe terá uma
sequencia de identificadores, quando houver generalização de classes o Handle da superclasse será
atribuído também para as subclasses.
Todas as classes serão criadas como tabelas no banco de dados com o nome definido na propriedade
TableID, adicionando o caractere (T) no início do nome, isto também ocorre com os relacionamentos.
2. Material Complementar