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

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

ARQUITETURA DE SOFTWARE

Apresentações semelhantes


Apresentação em tema: "ARQUITETURA DE SOFTWARE"— Transcrição da apresentação:

1 ARQUITETURA DE SOFTWARE
Prof. Antonio Alberto P. Santana

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

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. para 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 APRESENTAÇÃO DISTRIBUÍDA
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 APRESENTAÇÃO REMOTA Principal benefício Principal conseqüência
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 FUNÇÃO DISTRIBUÍDA Principais benefícios Principal conseqüência
é 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 GERENCIAMENTO REMOTO DE DADOS
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 GERENCIAMENTO DE DADOS DISTRIBUÍDO
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, 1996. LOOSLEY, C. Client/Server applications development and performance - 6º Congresso Nacional de Novas Tecnologias e Aplicações em Banco de Dados. São Paulo, 1995. LOOSLEY, CHRIS; High Performance Client/Server, 1ª ed. John Wiley Consumer, 1997. VASKEVITCH, D. Estratégias Cliente/Servidor. 1ª ed. São Paulo, Berkeley, 1995. VAUGHN, L. Client/Server System Design & Implementation. 1a. ed. New York, McGrow-Hill, 1994.

32 F I M


Carregar ppt "ARQUITETURA DE SOFTWARE"

Apresentações semelhantes


Anúncios Google