A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

ARQUITETURA DE SOFTWARE Prof. Antonio Alberto P. Santana.

Apresentações semelhantes


Apresentação em tema: "ARQUITETURA DE SOFTWARE Prof. Antonio Alberto P. Santana."— Transcrição da apresentação:

1 ARQUITETURA DE SOFTWARE Prof. Antonio Alberto P. Santana

2 - Estrutura da aplicação distribuída Cliente/Servidor - Transação - Consultas - Independência das camadas - Particionamento da aplicação AGENDA

3 ESTRUTURA DA APLICAÇÃO XXX

4 ESTRUTURA DA APLICAÇÃO - Função lógica de apresentação - é a camada que realiza a interação com o usuário final - Principais funções - garantir a segurança de acesso ao sistema; - permitir a navegação sobre o sistema para a chegada do usuário ao ponto desejado; - realizar a apresentação das informações; - manipular as informações imputadas no sistema; - realizar algumas análises destas informações.

5 ESTRUTURA DA APLICAÇÃO - Função lógica de regras de negócio - é responsável pela imposição da política de negócio da organização, comandando a tomada de decisão do processo, conforme os requisitos e regras que determinam o comportamento do negócio. - é a parte da aplicação que dá sentido à existência da própria aplicação. - a comunicação com esta camada é feita através do pedido de processo, que representa a interface da camada.

6 ESTRUTURA DA APLICAÇÃO - Função lógica de gerenciamento de dados - tem a responsabilidade de garantir o armazenamento, a manipulação, a consistência, a integridade e a segurança dos dados. - Principais funções - fazer a leitura e a atualização dos dados; - controlar a segurança do acesso aos dados; - garantir a integridade dos dados; - realizar a validação das operações solicitadas.

7 GERENCIAMENTO DE DADOS - Função lógica de gerenciamento de dados - a interface de comunicação com a camada de gerenciamento de dados é representada pelas transações e consultas. - p ara garantir consistência, integridade e segurança aos dados, o acesso a eles deve ser feito somente através de um conjunto de transações e consultas cuidadosamente definido.

8 TRANSAÇÃO - Definição - Uma transação é “uma seqüência de ações pré-definida, realizada por uma aplicação, que transforma um sistema de computação e seus recursos de um estado consistente para outro, ordenadamente, para realizar a desejada funcionalidade do negócio.” (BERSON, 1992).

9 TRANSAÇÃO - Propriedades - Atomicidade - uma transação deve ser completada ou abortada (se uma ação da seqüência falhar, todas as outras já realizadas pela transação deverão ser desfeitas); - Consistência - uma transação transforma um sistema de computação e seus recursos de um estado consistente para outro também consistente;

10 TRANSAÇÃO - Propriedades - Isolamento - os efeitos de uma transação não são visíveis por outras transações enquanto ela não for finalizada; - Serialização - as informações utilizadas por uma transação são travadas ao longo de sua execução, para evitar que outras transações alterem estas informações antes que aquela seja encerrada;

11 TRANSAÇÃO - Propriedades - Durabilidade - alterações feitas por uma transação encerrada (comitada) são permanentes e tolerantes à falha do sistema.

12 TRANSAÇÃO - Principais funções - garantir atualizações consistentes - atualizações devem ser implementadas somente por meio de transações para assegurar a consistência; - impor regras de negócio básicas - as regras de negócio básicas devem ser monitoradas pelas transações; - evitar atualizações não autorizadas ou inválidas no SGBD - a interface transacional funciona como um guardião para evitar atualizações não autorizadas ou inválidas no Banco de Dados.

13 CONSULTAS - Definição - “é um conjunto de consultas projetadas especialmente para recuperar dados da camada de gerenciamento de banco de dados de forma correta e consistente.” (VASKEVITCH, 1995).

14 CONSULTAS - Principais funções - simplificar uniões complexas - uma consulta feita pelo usuário pode, muitas vezes, exigir a reunião de diversas tabelas físicas do banco de dados para construir a informação solicitada. A complexidade do banco de dados deve ser transparente ao usuário, de forma que ele possa fazer consultas simples e obter respostas satisfatórias; - - assegurar consistência - os dados consultados devem refletir a integridade da informação, onde as características do evento que a gerou devem ser explicitadas quando a consulta for feita; - - garantir segurança - consultas elaboradas de forma apropriada podem assegurar que informações sensíveis sejam disponíveis apenas aos usuários e aplicativos autorizados.

15 INDEPENDÊNCIA DAS CAMADAS - é importante para se alcançar alguns benefícios proporcionados pela arquitetura distribuída, tais como a independência tecnológica, a estabilidade e a reutilização. - uma camada se torna independente quando os detalhes da sua implementação são encapsulados, escondendo a sua forma de operação, de maneira que a funcionalidade desta camada dependa apenas do estímulo feito através de mensagens, que trafegam sobre uma interface padronizada.

16 INDEPENDÊNCIA DO GERENCIAMENTO DE DADOS - se torna independente das regras de negócio quando o SGBD trabalha, sem importar quais são essas regras. - As transações na interface do SGBD não devem conter quaisquer regras.

17 INDEPENDÊNCIA DO GERENCIAMENTO DE DADOS - Regras - protejer cuidadosamente o banco de dados usando um modelo de dados bem planejado - não há substituto para um bom projeto de banco de dados; - desenvolver consultas e transações que ofereçam um bom acesso ao banco de dados - nas atualizações, as transações devem impor regras básicas de consistência, e, nas consultas, elas deverão oferecer uma visão lógica mais simples das complexas estruturas de dados do SGBD; - permitir apenas que transações bem elaboradas atualizem o banco de dados - as transações deverão se tornar verdadeiros guardiões do banco de dados; - isolar o usuário dos detalhes e locais dos bancos de dados fundamentais - a interface de banco de dados deverá se comunicar com uma série de bancos de dados diferentes em diferentes computadores, sem que o usuário ou a aplicação se preocupe com isto.

18 INDEPENDÊNCIA DAS REGRAS DE NEGÓCIO - se torna independente da apresentação quando evitamos que estas regras falem com o usuário. - a interface gráfica de usuário deve ser a única forma do usuário se comunicar com o sistema; - a independência das regras de negócio objetiva alcançar a interoperabilidade e a reutilização do código da aplicação. - interoperabilidade - é a capacidade de um módulo da aplicação (trecho do código) interoperar com uma variedade de outros módulos da organização (VASKEVITCH, 1995). - alcançada a interoperabilidade, teremos viabilizada a reutilização, onde um módulo da aplicação, que realiza uma determinada tarefa, poderá ser utilizado por diversos outros módulos da organização.

19 INDEPENDÊNCIA D APRESENTAÇÃO - tem como objetivo aumentar a liberdade e a flexibilidade dos usuários e da organização. - nesta camada, os usuários poderão moldar a aplicação de acordo com suas necessidades, ao seu jeito, sem que isto afete as regras, as políticas e os procedimentos da organização. - a organização poderá providenciar mudanças ou mesmo substituição desta camada, sem que as demais sejam afetadas. - A apresentação envia pedidos formais à camada de regras de negócio, podendo fazer qualquer coisa antes de enviar o pedido ou depois de receber a resposta.

20 PARTICIONAMENTO DA APLICAÇÃO - Particionar a aplicação é a forma de dividirmos o código da mesma entre o processo cliente e o processo servidor. - Essa importância decorre do fato de que a possibilidade de distribuição dos componentes do processamento da aplicação entre cliente e servidor é um dos motivos pelos quais a arquitetura cliente/servidor utiliza o processamento cooperativo, sendo que este representa o fundamento e a força motriz daquela (BERSON, 1992).

21 APRESENTAÇÃO DISTRIBUÍDA

22 - Principal benefício - quando se deseja controlar o acesso e o processamento da aplicação no módulo principal (módulo servidor), deixando apenas a apresentação gráfica para o processo cliente.

23 APRESENTAÇÃO REMOTA

24 - Principal benefício - adequada para as aplicações não-conversacionais onde o processo cliente recebe os dados de entrada e os envia através de uma única mensagem ao processo servidor, recebendo também de volta somente uma mensagem; - tende a reduzir o tráfego na rede. - Principal conseqüência - tende a sobrecarregar o servidor, uma vez que nele centraliza o processamento.

25 FUNÇÃO DISTRIBUÍDA

26 - Principais benefícios - é uma topologia adequada para aplicações altamente interativas e com intensivo I/O de banco de dados; - possibilita melhor aproveitamento do potencial do cliente; - alivia a carga de processamento do servidor; - permite a redução do número de mensagens entre a camada de apresentação e a camada de gerenciamento de dados, o que irá reduzir o tráfego na rede. - Principal conseqüência - a aplicação implementada nesta topologia tem a desvantagem de se caracterizar como uma implementação complexa.

27 GERENCIAMENTO REMOTO DE DADOS

28 - Principal benefício - esta topologia pode ser conveniente para aplicações de execução não freqüentes, que se caracterizam por baixo volume de dados nas solicitações e nos resultados. - Principais conseqüências - sobrecarga na rede - na medida em que todos os dados pesquisados sejam enviados ao cliente, o aumento no tráfego da rede poderá comprometer a performance da aplicação; - um local único de dados, bem como do banco de dados, cria um ponto “único” de falha, gerando desconfiança quanto à segurança; - os dados, bem como o banco de dados, localizados num único sistema (servidor de dados) podem comprometer o processamento devido a sua capacidade.

29 GERENCIAMENTO DE DADOS DISTRIBUÍDO

30 - Principal benefício - esta topologia proporciona maior segurança ao sistema, pois os dados críticos podem possuir múltiplas cópias localizadas em servidores diferentes; - o tráfego na rede pode ser sensivelmente reduzido, já que as solicitações dos dados passam por uma consistência no módulo cliente (entre as camadas de regras de negócio e dados) e, se a solicitação for satisfeita, a mensagem é enviada ao banco de dados remoto; caso contrário, é rejeitada antes de ser enviada pela rede. - Principal conseqüência - alta complexidade no gerenciamento de dados.

31 REFERÊNCIAS BIBLIOGRÁFICAS BERSON, A. Client/server architecture. 1ª ed. Singapore, McGrow- Hill Book, LOOSLEY, C. Client/Server applications development and performance - 6º Congresso Nacional de Novas Tecnologias e Aplicações em Banco de Dados. São Paulo, LOOSLEY, CHRIS; High Performance Client/Server, 1ª ed. John Wiley Consumer, VASKEVITCH, D. Estratégias Cliente/Servidor. 1ª ed. São Paulo, Berkeley, VAUGHN, L. Client/Server System Design & Implementation. 1a. ed. New York, McGrow-Hill, 1994.

32 F I M


Carregar ppt "ARQUITETURA DE SOFTWARE Prof. Antonio Alberto P. Santana."

Apresentações semelhantes


Anúncios Google