Projeto Arquitetural

Resumo da seção

• Projeto de uma arquitetura
• Decomposição do sistema: partições e camadas
• Arquiteturas em n camadas
• Uso de UML para modelar a arquitetura
• Estruturas de controle
• Opções de persistência
• Reutilização: Frameworks e componentização
• Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Projeto de uma arquitetura

• O que é um projeto arquitetural?
  • Decisões estratégicas que terão consequências profundas
  • As decisões são tomadas num alto nível
• Exemplos de decisões
  • Modularização do projeto em subsistemas
  • Escolha de uma estrutura de comunicação e controle entre os subsistemas
  • Escolha da divisão de trabalho entre membros de uma equipe ou entre equipes de desenvolvimento
  • Definição das interfaces entre subsistemas para possibilitar o trabalho paralelo de desenvolvimento
  • Escolha de uma estratégia de persistência
  • Escolha do paradigma de DBMS a usar
  • Determinação de oportunidades para o reuso de software
  • Atendimento a requisitos especiais de desempenho
  • Atendimento a outros requisitos (custo, mobilidade, uso de padrões, etc.)
  • Exposição das interfaces para facilitar a futura integração de aplicações (Enterprise Application Integration - EAI)
  • etc.
• Observe que sempre deve-se ter um olho na satisfação dos requisitos levantados
• Veremos vários aspectos do projeto arquitetural
  • A discussão é direcionada mais a sistemas de informação
    

Decomposição do sistema: partições e camadas

• Uma estrutura elegante pode frequentemente ser elaborada usando camadas e partições
  • Uma camada é um subsistema que adiciona valor a subsistemas de menor nível de abstração
  • Uma partição é um subsistema "paralelo" a outros subsistemas

• Lembre que subsistemas devem ser coesos (trata de responsabilidades fortemente relacionadas)
  • Tem forte acoplamento dentro de um subsistema
  • Tem fraco acoplamento entre subsistemas
• Para minimizar o acoplamento, camadas frequentemente se comunicam apenas com as camadas "vizinhas"
• A decomposição pode terminar quando você atingir subsistemas com temas claros que sejam simples de entender
• Alguns sistemas muito pequenos não necessitam de camadas e partições

Arquiteturas em n camadas

• Para sistemas de informação que incluam uma interface com o usuário e persistência (isto é, quase todos!), usa-se frequentemente uma arquitetura em 3 camadas (3-tier architecture)

• As camadas verticais são:
  • Apresentação: janelas, relatórios, etc.
    • Também chamada de Camada de Interface com o Usuário, Camada de Serviços do Usuário
  • Lógica da Aplicação: tarefas e regras que governam o processo
    • Também chamada de Camada de Aplicação, Ccamada de Serviços de Aplicação
  • Dados: mecanismo de armazenamento persistente
    • Também chamada de Camada de Gerência de Dados, Camada de Serviços de Dados, Camada de Armazenamento
• O que vai em cada camada pode mudar ligeiramente
  • Exemplo: é possível (e pode ser desejável) ter alguma lógica de aplicação na camada de dados usando Stored Procedures
  • Exemplo: é possível (mas em geral indesejável) ter alguma lógica de aplicação na camada de apresentação usando linguagens de scripts
• Em que máquina cada camada roda pode variar, mas hoje em dia, a distribuição física completa é comum
• Por que uma arquitetura em 3 camadas?
  • Sistemas em camadas surgiram para aproveitar os PCs da empresa e oferecer sistemas com interface gráficas amigáveis e integradas ao desktop
  • Os primeiros sistemas cliente-servidor eram de duas camadas (juntando as camadas de apresentação e de aplicação) mas sofriam de vários problemas:
    • Falta de escalabilidade (conexões a bancos de dados)
    • Enormes problemas de suporte (mudanças à lógica de aplicação forçava instalações)
    • Nenhum suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ...)
    • Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, ...)
    • Dificuldade de criar software reutilizável para rodar em clientes
  • Além do mais, a arquitetura em 3 camadas permite:
    • Usar o browser como cliente universal, levando ao conceito de Intranet
    • Evitar instalação em computadores de clientes, parceiros, fornecedores, etc.
    • Implementar serviços automáticos de persistência, tolerência a falhas com fail-over, gerência de transações, balanceamento de carga, resource pooling, etc.
      • Enterprise JavaBeans, COM+
• Arquitetura em n camadas
  • Podemos dividir a camada de aplicação em mais de uma camada
    • Frequentemente feito separando as aspectos relacionados ao domínio do problema e os aspectos de serviços

• Podemos também dividir a camada de dados em mais camadas (usando um datawarehouse, por exemplo)

Uso de UML para modelar a arquitetura

• UML provê o conceito de package para agrupar elementos
• Este mecanismo pode ser utilizado para evidenciar os subsistemas e suas dependências
• Um package em UML:

• A arquitetura em camadas pode ser representada em UML:

• A arquitetura detalhada e as dependências (acoplamento) entre packages podem ser representadas em UML:

Estruturas de controle

• O paradigma de controle externo da aplicação deve ser escolhido
  • O paradigma diz como uma aplicação é controlada "de fora" e como interage com seus usuários e outras aplicações
  • O controle interno dos objetos da aplicação não é visível fora da aplicação
• Há vários paradigmas de controle externo
  • Controle orientado a procedimento
    • Tem um único thread no programa
    • Métodos executam chamadas para obter dados de entrada e esperam os dados
    • O estado do programa pode ser guardado em variáveis locais aos procedimentos (na pilha de execução)
    • Vantagem: fácil de implementar com linguagens convencionais
    • Desvantagem: qualquer paralelismo inherente aos objetos deve ser mapeado a um fluxo de controle sequencial
    • Frequentemente usado em aplicações que possuem uma interface não gráfica
  • Controle orientado a evento
    • Um dispatcher é provido pela linguagem, SGBD, linguagem ou sistema operacional
    • Métodos da aplicação são amarrados a eventos
      • Quando o evento ocorre, o método correspondente é chamado
    • Todos os métodos retornam o controle para o dispatcher em vez de esperar que os dados de entrada cheguem
    • O estado do programa deve ser guardado em variáveis globais já que os métodos retornam o controle (e não ficam com ele)
    • Vantagem: ajuda a separar a lógica da aplicação da interface com o usuário
    • Frequentemente usado com SGBD munido de linguagem de quarta geração
    • Muito usado com bancos de dados
    • Quase sempre usado para controlar uma interface gráfica
  • Controle concorrente
    • O controle fica com vários objetos autônomos, cada um respondendo a eventos
    • A concorrência é provida pelo sistema operacional
      • Usando paralelismo em hardware ou não
    • Observe que estamos nos referindo a controle concorrente dentro da aplicação e não entre aplicações
      • Este último é muito comum (sessões paralelas de acesso a BD, por exemplo)
    • Infrequentemente usado, embora seu uso tenda a crescer com o CORBA (framework de objetos distribuídos)
  • Controle declarativo
    • O programa usa um fluxo de controle implícito beaseado em statements declarativos
    • Usado em sistemas especialistas baseados em regras
• Dois padrões de controle frequentemente utilizados na arquitetura são:
  • Observer Pattern (ou Publish-Subscribe) para acoplar objetos ou subsistemas
  • Model-View-Controller (MVC) para separar os objetos de domínio dos objetos de interface
  • Serão descritos em outro capítulo (sobre Design Patterns)

Opções de persistência

• Tratamos aqui apenas dos aspectos arquiteturais da persistência
  • Um capítulo à frente trata mais detalhadamente do mapeamento de projetos OO para esquemas de BD relacionais
• Três grandes pontos devem ser tratados com respeito à persistência de objetos:
  • Escolha da forma básica de persistência (na memória, em arquivos, usando um SGBD)
  • Escolha do paradigma de SGBD (se usar um SGBD)
  • Determinação da estratégia de interação entre a aplicação e os dados

Escolha da forma básica de persistência

• As alternativas básicas são:
  • Dados na memória
  • Dados em arquivos
  • Dados sob controle de um BD
• Muitas aplicações requerem necessariamente os serviços de um BD, mas algumas podem funcionar bem com uma alternativa mais simples
• Os seguintes pontos devem ser avaliados para tomar a decisão sobre a forma de persistência:
  • Persistência de dados
    • Arquivos e SGBDs são fortes
    • Ficar com os dados na mamória requer um suporte especial de memória e fontes de alimentação para prevenir a perda de informação
  • Custo de aquisição
    • Um SGBD pode ser muito caro
      • Se houver um site license já em uso, o custo incremental pode ser pequeno
    • O hardware para manter dados na memória pode ser caro
    • Arquivos nada custam pois são inherentemente suportados pelo sistema operacional
  • Custo total de posse (Total Cost of Ownership)
    • Custos incluem a aquisição, treinamento, desenvolvimento, implantação, operação e manutenção
    • Qualquer uma das 3 alternativas pode ganhar aqui
      • Exemplo: SGBD pode reduzir custos de desenvolvimento mas aumenta custos de operação (incluindo recursos humanos)
      • Exemplo: arquivos não têm custo de aquisição mas têm um alto custo de manutenção
  • Quantidade de dados
    • SGBDs podem armazenar gigantescas quantidades de informação
    • Recursos de hardware limitam a quantidade de dados que pode ser armazenada na memória
    • Arquivos são limitados em tamanho pelo sistema operacional
      • Cuidado com sistemas que limitam arquivos a 32 bits (4 GBytes)
  • Desempenho
    • xdados na memória são acessados mais rapidamente
    • SGBDs têm algoritmos e estruturas de dados especiais para lidar com grandes quantidades de dados
    • Arquivos podem ser rápidos se couberem na memória ou se forem eficientemente acessados sequencial ou randomicamente
  • Extensibilidade
    • SGBDs oferecem independência de dados de forma que o desenvolvedor pode se concentrar nos aspectos lógicos dos dados, sem preocupação imediata com detalhes de implementação física
  • Acesso concorrente
    • A granularidade de travamento pode afetar o desempenho
    • Tipicamente, arquivos são travados por completo
      • Travamento de registros de arquivos requer muita programação
    • A granularidade é melhor com dados na memória
    • SGBDs podem ter boa granularidade (record locking) ou menos boa (page locking)
      • Além do mais, SGBDs podem escalonar travamentos e resolver conflitos automaticamente sem programação adicional
  • Recuperação de crash
    • Arquivos: Arquivos de backup são necessários
    • SGBDs: têm lógica sofisticada para recuperação de crash
    • Memória: requer o uso de shadow memory
  • Integridade
    • Apenas SGBDs oferecem o suporte a regras de integridade (definidas pelo programador)
  • Suporte a transações
    • Apenas SGBDs oferecem suporte a transações
  • Distribuição
    • Apenas (alguns) SGBDs oferecem suporte à distribuição de dados e vários sites
  • Linguagem de consulta
    • SGBDs oferecem linguagens de consulta para facilitar o manuseio de dados
    • Alguns produtos do mercado oferecem linguagens de consulta simples para dados em arquivos
  • Segurança
    • Arquivos podem ser protegidos pelo sistema operacional (mas sem sofisticaão)
    • SGBDs podem implementar segurança com passwords, views, etc.
  • Metadados
    • SGBDs permitem a manipulação da estrutura dos dados (metadados) em tempo de execução
• Um sumário segue:

• Em suma, algumas aplicações naturalmente se beneficiam de cada alternativa de persistência:
  • Dados na memória
    • Dados para dispositivos eletrônicos (celulares, PDAs, ...)
    • Dados para smart cards, cartuchos de jogos
    • Dados para aplicações que não podem tolerar o custo ou falta de confiabilidade de um disco
  • Arquivos
    • Dados de grande volume, com pouca densidade de informação (archival files, registros históricos detalhados, logs, ...)
    • Dados crus que devem ser sumarizados num BD (exe.: aquisição de dados, telemetria, ...)
    • Quantidades modestas de dados com estrutura simples (quando não tem SGBD ou este seria complexo demais para a empresa manter)
    • Dados acessados sequencialmente
    • Dados que são lidos por inteiro na memória
  • SGBDs
    • Dados que requerem atualização com níveis finos de granularidade por múltiplos usuários
    • Dados que devem ser acessados por várias aplicações
    • Grandes quantidades de dados que devem ser eficientemente manipulados
    • Dados de longa duração e muito valiosos a uma organização
    • Dados que devem ser acessados com sofisticado controle de segurança
    • Dados sujeitos a análise sofisticada para o apoio à decisão
• Finalmente, observe que é comum utilizar mais do que uma única alternativa para dados diferentes

Escolha do paradigma de SGBD

• Se usar um SGBD, ainda deve-se escolher entre SGBDs relacionais, objeto-relacionais e orientados a objeto
• Os detalhes fogem do escopo desta disciplina
• Resumindo:
  • SGBDRs são maduros mas sofrem de um problema sério: impedance mismatch entre objetos e relações
    • As grandes desvantagens são:
      • Navegação lenta (usando joins de tabelas)
      • Protocolos de travamento inflexíveis (por serem automáticos)
      • Poucos tipos de dados
      • Tudo tem que ser uma tabela
    • Mostraremos como mapear um projeto OO para um esquema relacional num capítulo à frente
  • SGBDOOs não são tão maduros mas não sofrem de impedance mismatch e apresentam recursos avançados (evolução de esquema, controle de versões, long transactions, notificações de mudanças, ...)
    • Oferecem navegação rápida mas ainda carecem até de uma teoria completa!
• Há ainda a alternativa de SGBDs Objeto-Relacionais que mantêm o paradigma relacional mas resolvem algumas questões (tais como melhor suporte a tipos de dados)

Determinação da estratégia de interação entre a aplicação e os dados

• Quais são as estratégias para conectar sua aplicação a um SGBD?
• Pré-processador e pós-processador batch
  • Em alguns casos, é melhor que a aplicação não acesse o BD
  • Aplicações batch existentes podem fazer uso de um BD de forma indireta
  • Pode ser útil em algos (raros?) casos em que se usa software legado ou sem código fonte dentro de uma aplicação (como subsistema)

• Arquivos de script
  • Para certas aplicações simples, basta executar um ou mais arquivos contendo comandos de uma linguagem de consulta (SQL, OQL, ...)
  • Bom para certas situações tais como criar esquemas, popular um BD, prorotipagem
• Comandos embutidos da linguagem de manipulação de dados de um SGBDOO
  • Neste caso, a aplicação acessa o BD diretamente
  • Parece natural devido ao casamento entre a linguagem hospedeira (digamos Java) e um SGBDOO
  • Cuidado! Ao proceder assim,  o acoplamento com o SGBDOO fica muito forte e pode ser difícil mudar de SGBD posteriormente
    • Use o padrão ODMG para melhorar a portabilidade
• Comandos SQL estáticos embutidos
  • Código SQl estático é conhecido em tempo de compilação
  • É relativamente simples de usar, mas:
    • Sem muitos cuidados (batching, etc.), pode resultar numa execução lenta
    • Acopla muito o código da aplicação ao esquema do BD
    • Resulta em código difícil de se ler
  • Em suma, tenta-se desta forma resolver o impedance mismatch com código estático
• Implementar uma API customizada de acesso aos dados
  • Os acessos ao BD são encapsulados em poucos métodos da aplicação
  • Ajuda a manter a consistência dos dados
  • Ajuda a manter o escopo de transações
  • Ajuda a não contaminar a aplicação com um monte de código de acesso ao BD
  • Técnica muito usada
• Métodos armazenados no BD
  • Stored procedures
  • Boa forma de reuso para várias aplicações
  • Certos cuidados ao usar Stored Procedures serão tratados num capítulo posterior sobre persistência
  • Cuidado! Stored Procedures não são implementados de forma portável pelos vários SGBDs do mercado
    • O padrão SQL não é obedecido pelos fabricantes
• Linguagem de quarta geração
  • SGBDRs normalmente vêm com uma linguagem 4GL
  • Podem reduzir o esforço de desenvolvimento, mas não são portáveis
• Camada Genérica Orientada a Objeto
  • Uma camada OO é escrita para completamente esconder o BD
  • Ela pode ser genérica (para qualquer objeto, qualquer aplicação) com bastante esforço
  • Geralmente sofre com desempenho
• Interação baseada em Metamodelo
  • A camada de acesso ao BD acessa o metamodelo e constroi a consulta dinamicamente
  • A consulta resultante acessa o BD
  • Solução frequentemente usada com frameworks
  • Cuidado! Essa técnica requer muito esforço!
    • É melhor usar uma solução pronta, tal como Toplink

• Uso de Middleware
  • Os serviços de persistência podem ser obtidos automaticamente usando Middleware
    • Enterprise JavaBeans
    • COM+
  • Vantagem: muitos serviços são obtidos além da persistência:
    • Gerência de transações distribuídas
    • Directory/Naming
    • Segurança
    • Tolerância a falha com Failover
    • Balanceamento de carga
    • Resource pooling
    • Monitoring, logging, ...

Reutilização: Frameworks e componentização

• Devido à sua importância, dedicamos um capítulo à frente sobre o tema de reutilização
  • Frameworks
    • Criação de uma aplicação quase pronta que permite rapidamente criar várias aplicações de um mesmo domínio de problema
  • Componentes
    • Pedaços de software que permitem a composição visual de aplicações em tempo de design

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Sobre entidades externas ao sistema

• Quais sistemas externos devem ser acessados?
• Como serão acessados?
• Há integração com o legado a ser feita? Como?

Determinação de oportunidades para o reuso de software

• Há interesse/conveniência/tempo em aproveitar tais oportunidades?
• Como isso pode ser feito?
  • Com componentes?
  • Construindo um framework?

Sobre a organização geral do sistema

• O sistema é centralizado ou distribuído?
• Como modularizar em subsistemas?
• Como minimizar acoplamento entre os pedaços?
• Lembrando que um sistema pode ser visto como sendo composto de três grandes camadas lógicas ...
• Tais camadas serão lógicas ou terão existência física separada?
• Onde colocar o business logic (como dividir entre as camadas)?
• Qual é o nível de acoplamento, frequência de interações, volumes de dados trocados entre as camadas?
• Qual seria a estrutura de comunicação e controle entre os subsistemas (como ligar as camadas)?
  • Usando o Observer Pattern?
  • Usando o Model-View-Controller Pattern?
• Quais são as interfaces importantes entre os pedaços?
  • Qual é o formato das mensagens (xml, ...)?
  • Como é feita a comunicação remota? CORBA? RPC? RMI? Message Queue?
• A programação será feita com qual paradigma? OO?
• Que linguagens e ferramentas serão usadas?

Sobre a camada de interface

• O sistema será acessado usando que tipos de clientes?
  • Browser?
  • Uso de applet?
  • Uso de script cliente?
• Como fazer a interface gráfica?
  • Com que ferramentas?
  • Com que componentes visuais?
    • Serão desenvolvidos? comprados?
  • Javascript ou outra linguagem de script do lado cliente será usada?
• Que modelo de componentes visuais será usado?
  • Activex?
  • Javabeans?
• Se a interface usar um browser, como será feita a geração de HTML dinâmico?
  • Servlets?
  • JSP?
  • ASP?
• Que ferramentas usar para a formatação de relatórios?
• Há packages a desenvolver que poderiam ser comuns a várias partes da interface?

Sobre a camada de lógica da aplicação

• Escolha de middleware: qual modelo de componentes de servidor será usado?
  • COM+?
  • EJB?
• Quais são os componentes principais a fazer?
• Serão componentes persistentes?
• Serão componentes com ou sem estado?
• De que forma atender aos requisitos para uso multiusuário?
  • Soluções para resolver a concorrência
• Que APIs serão usadas para acesso a:
  • Dados persistentes?
  • Serviço de mail?
  • Serviço de nomes?
• Há packages a desenvolver que poderiam ser comuns a várias partes da lógica da aplicação?
• Qual é a organização interna dos modulos executáveis?
  • Determinar sub-camadas e partições
• Quais são as interfaces importantes entre os pedaços?
• Onde verificar os business rules?
  • No SGBD?
  • No middleware?
• Como implementar aspectos de segurança?
• Como implementar os requisitos de auditoria?

Sobre a camada de dados persistentes

• Quais são as fontes de dados? externas? internas? existentes? novas?
• Como acessa-las?
• Que estratégia de persistência será usada:
  • Na memória (com recursos especiais como pilha)?
  • Em arquivos?
  • Usando um SGBD?
• Qual paradigma de SGBD usar?
  • Relacional?
  • O-R?
  • O-O?
• Onde usar stored procedures para implementar os business rules ou garantir a integridade dos dados?
• Qual será a estratégia de interação entre a aplicação e os dados?
• De que forma atender aos requisitos para uso multiusuário (concorrência)?
• Como resolver o impedance mismatch entre a camada de lógica de aplicação e o esquema de persistência?
• Para grandes escalas, como oferecer connection pooling?
• Como implementar a segurança no SGBD?
• Como será feita a população dos bancos de dados?

Sobre requisitos de desempenho

• Há necessidade de bolar formas especiais de atender aos requisitos de desempenho?
  • Como prover escala?
  • Como prover failover?

O que deve ser produzido?

• Quais são os módulos executáveis a produzir?
  • Executáveis, DLLs, ...
• Quais são os arquivos importantes (de configuração, etc.) e seu formato (xml, ...)?
• Como será resolvida a instalação do produto?
• O que será comprado, feito, modificado?
• O que será gerado automaticamente com uma ferramenta especial?
  • Exemplo: geração de esquema através de ferramentas CASE, ...

Sobre a integração futura

• Que interfaces devem ser expostas para facilitar a futura integração de aplicações (Enterprise Application Integration - EAI)?
  • Pode-se usar uma camada de API para expor a camada de business logic, colocar uma camada de script acima disso e ainda camada(s) de interface para ativar a business logic através de scripts.
  • Vantagens:
    • Fácil criação de macros e outras formas de automação
    • Fácil criação de testes de regressão
    • Clara separação de business logic da interface para o usuário
• Como será feita a exposição?
  • Com XML?
  • Através de uma API?

Perguntas adicionais

• Que ferramentas de desenvovimento serão geradas?
• Como será o atendimento a outros requisitos (custo, mobilidade, uso de padrões, etc.)
• Há considerações especiais de administração a levar em conta?
  • Como será a troca de versões?
  • Como será a distribuição do software?
    • Via Internet/Intranet?
    • Via mídia?

Pergunta final

• Você já verificou que a arquitetura bolada pode atender a todos os requisitos levantados?

proj1-2 programa anterior próxima