Andre faktorer som påvirker vegetasjonsfordelingen

sistemas de processamento de transac¸˜oes de neg´ocios e fornece diretrizes para melhor´a-los.

2.4

Frameworks Relevantes na ´area de Neg ´ocios

Nesta sec¸˜ao, faz-se um resumo de alguns dos frameworks relevantes encontrados na literatura, cujo dom´ınio ´e relacionado a neg´ocios. Sem d´uvida, o principal deles ´e o IBM SanFrancisco, in- ternacionalmente conhecido e utilizado em diversas companhias no mundo todo (entre eles Jap˜ao, Canad´a, It´alia, Brasil, M´exico, Polˆonia e Holanda). Outros frameworks aqui abordados s˜ao oAc- counts, que ´e um framework de aplicac¸˜ao empresarial, e o OmniBuilder, que ´e um framework de

integrac¸˜ao demiddleware.

2.4.1

IBM SanFrancisco

O framework de componentes SanFrancisco (em inglˆesSanFrancisco Component Framework), ou

SFCF, foi desenvolvido por uma equipe da IBM utilizando a linguagem Java, para auxiliar seus parceiros de neg´ocios na construc¸˜ao de aplicac¸˜oes para uso pr´oprio ou para distribuic¸˜ao para seus clientes (Monday et al., 2000). Ele pode ser alugado por empresas para a criac¸˜ao de aplicac¸˜oes que, depois de encerrado o per´ıodo de desenvolvimento, passam a utilizar o sistema gerado sem outros encargos (Yassin e Fayad, 2000). A Figura 2.3 mostra a arquitetura do SanFrancisco, que ´e composto por diversas camadas que permitem seu reuso em diferentes n´ıveis (Monday et al., 2000).

A camada mais espec´ıfica do SanFrancisco ´e denominada “Processos de Neg´ocio Centrais” e trata dos principais processos e classes de um dom´ınio particular. Por ser espec´ıfica, essa camada aplica-se apenas aos dom´ınios por ela cobertos, que s˜ao: Gest˜ao de Armaz´ens, Livro Raz˜ao, Contas a Pagar, Contas a Receber e Gest˜ao de Pedidos.

A camada intermedi´aria do SanFrancisco, denominada “Objetos de Neg´ocio Comuns”, con- siste de classes, processos e mecanismos comuns a v´arios dom´ınios de aplicac¸˜ao, divididos em trˆes grupos principais: objetos gerais de neg´ocio (por exemplo, Companhia, Moeda e Cliente); objetos financeiros de neg´ocio (por exemplo, Conta Banc´aria e Calend´ario Financeiro); e meca- nismos generalizados ou padr˜oes (por exemplo, Pol´ıtica dirigida `a cadeia de responsabilidade e Controlador). Nessa camada intermedi´aria do SanFrancisco s˜ao fornecidas partes independentes que podem ser escolhidas e utilizadas de maneira similar a uma biblioteca de componentes, desde que seja respeitado o relacionamento entre processos e classes do framework SanFrancisco.

A camada inferior do SanFrancisco, denominada “Fundac¸˜ao e Utilit´arios”, fornece os servic¸os b´asicos necess´arios a uma aplicac¸˜ao de neg´ocio, isolando-a, dessa forma, da tecnologia subjacente.

2.4 Frameworks Relevantes na ´area de Neg´ocios 24

Processos de Negócio Centrais Objetos de Negócio Comuns

Fundação e Utilitários IBM

SanFrancisco

Plataformas Máquina virtual Java

Hardware e Sistemas Operacionais Aplicação Aplicação Apli- cação Apli- cação Solução do Cliente

Figura 2.3: Arquitetura do framework IBM SanFrancisco (Monday et al., 2000)

Exemplos de servic¸os inclu´ıdos nessa camada s˜ao armazenamento e compartilhamento de objetos de neg´ocio e utilit´arios para configurac¸˜ao e controle de servic¸os b´asicos.

Cada uma das camadas do SanFrancisco ´e constru´ıda com base nas camadas abaixo dela. As- sim, a camada “Processos de Neg´ocio Centrais” est´a acima da camada “Objetos de Neg´ocio Co- muns”. Uma classe fornecida pela camada “Processos de Neg´ocio Centrais” ´e constru´ıda usando uma ou mais classes da camada “Objetos de Neg´ocio Comuns” ou da camada “Fundac¸˜ao e Uti- lit´arios”. O usu´ario do SanFrancisco pode utilizar a camada mais apropriada `as suas necessidades. Por exemplo, uma aplicac¸˜ao financeira pode ser constru´ıda sobre as partes Livro Raz˜ao, Contas a Pagar e Contas a Receber da camada “Processos de Neg´ocio Centrais”. Uma aplicac¸˜ao para seguradoras deveria ser constru´ıda sobre a camada “Objetos de Neg´ocio Comuns”, j´a que o San- Francisco n˜ao possui uma parte espec´ıfica para sistema de seguradoras em sua camada “Processos de Neg´ocio Centrais”. Uma aplicac¸˜ao que n˜ao seja da ´area de neg´ocio deve ser constru´ıda sobre a camada “Fundac¸˜ao e Utilit´arios”.

2.4.2

OmniBuilder

O OmniBuilder (OMNISPHERE, 2002) ´e um ambiente de desenvolvimento totalmente orientado a objetos, feito para desenvolver aplicac¸˜oes completas a partir de um modelo de neg´ocios (Busi- ness Model em inglˆes). Segundo Yassin e Fayad (2000), ele ´e um framework de integrac¸˜ao de middleware, pois consiste de um gerador de aplicac¸˜oes abertas capaz de construir aplicac¸˜oes de

neg´ocios totalmente funcionais e sofisticadas, a partir do modelo de neg´ocio. O OmniBuilder ge- rencia o ciclo de vida completo da aplicac¸˜ao, captando o modelo de objetos, incluindo regras de

2.4 Frameworks Relevantes na ´area de Neg´ocios 25 neg´ocios, requisitos e casos de uso. Gera todos os componentes da aplicac¸˜ao, desde os objetos servidores, m´odulos cliente, protocolos de middleware, documentac¸˜ao e ajuda online. A arqui-

tetura do OmniBuilder garante independˆencia da linguagem alvo (por exemplo, Java, C++) e da estrutura de implementac¸˜ao (por exemplo, multi-camadas, Intranet). Pode ser personalizada e es- tendida pelo usu´ario para obedecer a requisitos espec´ıficos e foi projetada para acomodar novas tecnologias que venham a surgir.

A Figura 2.4 mostra a estrutura do OmniBuilder. Ele gera aplicac¸˜oes completas a partir do Modelo de Neg´ocios, que pode ser fornecido manualmente durante a an´alise ou pode ser criado utilizando os Gabaritos de Neg´ocios (Business Templates). Esse gabaritos podem conter um mo-

delo completo ou parcial do neg´ocio, sendo importados para o OmniBuilder e ent˜ao melhorados ou modificados conforme desejado, para criar um modelo de neg´ocios personalizado e completo. O Modelo da Aplicac¸˜ao ´e constru´ıdo automaticamente a partir do modelo de neg´ocios. Ele cont´em elementos para prototipac¸˜ao dos objetos e de seu comportamento. Padr˜oes de Projeto s˜ao usados pelo OmniBuilder para captar comportamento complexo e para promover reuso de componen- tes. Muitos padr˜oes de projeto j´a se encontram incorporados ao OmniBuilder, sendo oferecida a facilidade de adicionar padr˜oes de projeto personalizados, que podem ser utilizados para gerar caracter´ısticas particulares de maneira reus´avel. O Modelo de Implementac¸˜ao cont´em os obje- tos execut´aveis gerados. Podem ser produzidas aplicac¸˜oes com interface com o usu´ario baseada em Windows ou p´aginas dinˆamicas baseadas em HTML para Internet/Intranet a serem executadas por um Browser Internet. O OmniBuilder pode gerar aplicac¸˜oes em um n´umero de tecnologias alvo, incluindo Java e C++. Pode tamb´em gerar aplicac¸˜oes de trˆes camadas compat´ıveis com CORBA/COM/OLE.

2.4.3

Accounts

OAccounts ´e um framework para criac¸˜ao de sistemas de processamento de transac¸˜oes de neg´ocio,

no qual definem-se contas e transac¸˜oes (Keefer, 1994). Foi desenvolvido na Universidade de Illinois-EUA usando a linguagem Smalltalk-80. As duas classes principais doAccounts s˜ao conta

e transac¸˜ao. Uma conta controla as transac¸˜oes nela postadas e ´e capaz de calcular os valores de seus atributos em uma certa data. Exemplos de contas s˜ao: di´arios de invent´ario, contas banc´arias e registros de empregados. Transac¸˜ao, um termo comumente usado em sistemas cont´abeis, con- siste no registro de um evento significativo envolvendo dados relevantes ao sistema. Exemplos de transac¸˜oes s˜ao compra, venda, dep´osito e retirada.

Um sistema cont´abil representa a vis˜ao do mundo por parte de uma pessoa ou entidade de neg´ocio e ´e tipicamente utilizado para representar o fluxo de caixa da organizac¸˜ao. Sistemas cont´abeis podem controlar diferentes tipos de dados, inclusive n˜ao-financeiros, como suprimento em invent´arios, dados de censo ou dados meteorol´ogicos. Em qualquer sistema cont´abil ´e poss´ıvel

2.5 Trabalhos relevantes que relacionam padr˜oes a frameworks 26