Você está na página 1de 71
Projeto de Sistemas Arquitetura de Software Ernani Gaspar Santos Estudante de Doutorado egsantos@inf.ufes.br

Projeto de Sistemas

Projeto de Sistemas Arquitetura de Software Ernani Gaspar Santos Estudante de Doutorado egsantos@inf.ufes.br

Arquitetura de Software

Ernani Gaspar Santos

Estudante de Doutorado

egsantos@inf.ufes.br

nemo.inf.ufes.br/en/ernani/teaching/ps

Núcleo de Modelagem Conceitual e Ontologia Departamento de Informática Universidade Federal do Espírito Santo

Os slides foram cedidos por gentileza do Prof. Ricardo de Almeida Falbo e ligeiramente alterados

Agenda

O que é?

Fatores de afetam o Projeto da Arquitetura

Interessados na Arquitetura

O Modelo de Arquitetura

Classes de Sistemas

Estilos Arquitetônicos

Padrões Arquitetônicos

Projeto de Sistemas de Informação

Classes de Sistemas • Estilos Arquitetônicos • Padrões Arquitetônicos • Projeto de Sistemas de Informação 2

2

Classes de Sistemas • Estilos Arquitetônicos • Padrões Arquitetônicos • Projeto de Sistemas de Informação 2

O que é Arquitetura de Software?

Organização e estrutura geral do sistema

Atribuição de funcionalidades a elementos da arquitetura

Atributos de Qualidade de Produto (RNFs)

do sistema • Atribuição de funcionalidades a elementos da arquitetura • Atributos de Qualidade de Produto

3

do sistema • Atribuição de funcionalidades a elementos da arquitetura • Atributos de Qualidade de Produto

O que é Arquitetura de Software?

Organização e estrutura geral do sistema

Atribuição de funcionalidades a elementos da arquitetura

Atributos de Qualidade de Produto (RNFs)

a elementos da arquitetura • Atributos de Qualidade de Produto (RNFs) • Seleção de Alternativas de

Seleção de Alternativas de Projeto

a elementos da arquitetura • Atributos de Qualidade de Produto (RNFs) • Seleção de Alternativas de

4

a elementos da arquitetura • Atributos de Qualidade de Produto (RNFs) • Seleção de Alternativas de

O que é Arquitetura de Software?

É a estrutura do sistema, compreendendo elementos de

software (ou módulos), propriedades externamente visíveis desses elementos e os relacionamentos entre eles (BASS;

CLEMENTS; KAZMAN, 2003).

propriedades externamente visíveis desses elementos e os relacionamentos entre eles (BASS; CLEMENTS; KAZMAN, 2003). 5

5

propriedades externamente visíveis desses elementos e os relacionamentos entre eles (BASS; CLEMENTS; KAZMAN, 2003). 5

O que é Arquitetura de Software?

É a estrutura do sistema, compreendendo elementos de

• É a estrutura do sistema, compreendendo elementos de software (ou módulos), propriedades externamente visíveis

software (ou módulos), propriedades externamente visíveis desses elementos e os relacionamentos entre eles.

indicam as suposições que os demais elementos podem fazer sobre um elemento, tais como serviços
indicam as suposições que os demais
elementos podem fazer sobre um
elemento, tais como serviços providos e
características de qualidade esperadas.

6

elementos podem fazer sobre um elemento, tais como serviços providos e características de qualidade esperadas. 6

O que é Arquitetura de Software?

É uma abstração do sistema que suprime detalhes dos

elementos que não afetam como eles são usados, como se relacionam, como interagem e como usam outros elementos.

É usada, principalmente, para descrever aspectos estruturais de um sistema.

e como usam outros elementos. • É usada, principalmente, para descrever aspectos estruturais de um sistema.

7

e como usam outros elementos. • É usada, principalmente, para descrever aspectos estruturais de um sistema.

O que é Arquitetura de Software?

Elementos interagem com outros por meio de interfaces que

dividem detalhes sobre um elemento em partes pública e privada.

A arquitetura está preocupada com a parte pública dessa divisão.

Detalhes privados não são arquiteturais.

A arquitetura está preocupada com a parte pública dessa divisão. • Detalhes privados não são arquiteturais.

8

A arquitetura está preocupada com a parte pública dessa divisão. • Detalhes privados não são arquiteturais.

Fatores que Afetam o Projeto da Arquitetura

Requisitos

Ambiente técnico (plataforma de implementação)

Estrutura e metas da organização de desenvolvimento

Experiências e formação dos projetistas

• Estrutura e metas da organização de desenvolvimento • Experiências e formação dos projetistas 9

9

• Estrutura e metas da organização de desenvolvimento • Experiências e formação dos projetistas 9

Fatores que Afetam o Projeto da Arquitetura

Informações para EAP

e alocação de recursos

Requisitos

Estrutura da Organização

Natureza da organização, padrões aceitos

Requisitos do sistema

Arquitetura Novas
Arquitetura
Novas

Metas Atuais

experiências

Novas oportunidades, reúso, qualidade

Introdução em um novo

segmento de mercado

Experiências

anteriores

Formação e Experiência dos Projetistas

Metas da Organização

um novo segmento de mercado Experiências anteriores Formação e Experiência dos Projetistas Metas da Organização 10

10

um novo segmento de mercado Experiências anteriores Formação e Experiência dos Projetistas Metas da Organização 10

Interessados na Arquitetura

Desenvolvedores

Gerentes de projeto

Mantenedores

Clientes e usuários finais

• Desenvolvedores • Gerentes de projeto • Mantenedores • Clientes e usuários finais 11

11

• Desenvolvedores • Gerentes de projeto • Mantenedores • Clientes e usuários finais 11

Interessados na Arquitetura

Desenvolvedores

Gerentes de projeto

Mantenedores

Clientes e usuários finais

Desenvolvedores • Gerentes de projeto • Mantenedores • Clientes e usuários finais • Negociação

Negociação

• Gerentes de projeto • Mantenedores • Clientes e usuários finais • Negociação 12

12

• Gerentes de projeto • Mantenedores • Clientes e usuários finais • Negociação 12

O Modelo de Arquitetura

É um modelo relativamente pequeno e intelectualmente compreensível de como o sistema é estruturado e como seus

elementos trabalham em conjunto.

Abstração do sistema que pode ser usada para compreensão mútua, negociação, consenso e comunicação entre os interessados.

do sistema que pode ser usada para compreensão mútua, negociação, consenso e comunicação entre os interessados.

13

do sistema que pode ser usada para compreensão mútua, negociação, consenso e comunicação entre os interessados.

O Papel do Modelo de Arquitetura

Registro das primeiras decisões de projeto:

Implementação deve ser dividida nos elementos prescritos pela

arquitetura

Os elementos têm de interagir conforme o prescrito e cada elemento tem de cumprir sua responsabilidade conforme ditado

pela arquitetura

de interagir conforme o prescrito e cada elemento tem de cumprir sua responsabilidade conforme ditado pela

14

de interagir conforme o prescrito e cada elemento tem de cumprir sua responsabilidade conforme ditado pela

O Papel do Modelo de Arquitetura

Ajuda a obter estimativas e cronogramas mais precisos

Ajuda na prototipagem

Influencia diretamente na manutenibilidade:

Alterações locais

Alterações não locais (vários elementos)

Alterações arquitetônicas

• Alterações locais • Alterações não locais (vários elementos) • Alterações arquitetônicas 15

15

• Alterações locais • Alterações não locais (vários elementos) • Alterações arquitetônicas 15

O Papel do Modelo de Arquitetura

É transferível para outros sistemas, em especial para aqueles similares, promovendo reuso em larga escala

Permite uma abordagem de desenvolvimento baseada na

composição ou montagem de elementos desenvolvidos separadamente, até mesmo de forma independente.

baseada na composição ou montagem de elementos desenvolvidos separadamente, até mesmo de forma independente. 16

16

baseada na composição ou montagem de elementos desenvolvidos separadamente, até mesmo de forma independente. 16

Como representar o Modelo de Arquitetura

Forma comum: diagramas contendo caixas (representando elementos) e linhas (representando relacionamentos).

Um modelo de arquitetura deve incorporar informações

acerca dos tipos de elementos e dos tipos de relacionamentos (decomposição, utilização etc.)

informações acerca dos tipos de elementos e dos tipos de relacionamentos (decomposição, utilização etc.) 17

17

informações acerca dos tipos de elementos e dos tipos de relacionamentos (decomposição, utilização etc.) 17

Classes de Sistemas

Sistemas similares muito provavelmente terão arquiteturas similares.

Se há soluções bem estabelecidas para certas classes de

sistemas, não há razão para reinventar a roda.

O melhor é procurar reutilizar soluções.

certas classes de sistemas, não há razão para reinventar a roda. • O melhor é procurar

18

certas classes de sistemas, não há razão para reinventar a roda. • O melhor é procurar

Classes de Sistemas

Sistemas podem ser classificados de muitas formas diferentes.

Classificação de Blaha e Rumbaugh (2006):

Sistemas de Transformação em Lote

Sistemas de Transformação Contínua

Sistemas de Interface Interativa

Sistemas de Simulação Dinâmica

Sistemas de Tempo Real

Sistemas Gerenciadores de Transações

– Sistemas de Simulação Dinâmica – Sistemas de Tempo Real – Sistemas Gerenciadores de Transações 19

19

– Sistemas de Simulação Dinâmica – Sistemas de Tempo Real – Sistemas Gerenciadores de Transações 19

Classes de Sistemas

Quanto à plataforma em que executam:

Aplicações desktop: executam em estações de trabalho (computadores, notebooks) e podem utilizar os recursos dessas máquinas.

Aplicações web: utilizam a Web, por meio de um navegador (browser), como ambiente de execução.

Aplicações móveis: desenvolvidos para dispositivos móveis de baixa capacidade de

processamento, tais como celulares. Podem executar via Web (e, portanto, neste

caso são também aplicações web) ou como clientes específicos de uma certa plataforma móvel (p.ex., iPhone, Blackberry, Android, Windows Mobile). Neste último caso, uma aplicação cliente desenvolvida para um sistema operacional pode

não ser portável para outros.

Neste último caso, uma aplicação cliente desenvolvida para um sistema operacional pode não ser portável para

Classes de Sistemas

Riqueza das interfaces com o usuário:

Aplicações desktop: maior riqueza das interfaces com o usuário.

Aplicações web tradicionais: baseadas na apresentação de

páginas HTML, o que permite uma interação pouco flexível.

Aplicações Ricas para Internet (Rich Internet Applications - RIAs):

interação com o usuário avançada e sofisticada no mesmo nível das aplicações desktop.

Applications - RIAs): interação com o usuário avançada e sofisticada no mesmo nível das aplicações desktop.

Aplicações Web

• O termo “Aplicações Web” (WebApps) abrange um amplo espectro de sistemas construídos para serem acessados via

Web.

“Aplicações Web” (WebApps) abrange um amplo espectro de sistemas construídos para serem acessados via Web. 22

22

“Aplicações Web” (WebApps) abrange um amplo espectro de sistemas construídos para serem acessados via Web. 22

Categorias de Aplicações Web

Informacionais: proveem conteúdo apenas de leitura, com navegação e links simples. Ex.: Jornais online, catálogos de produtos, boletins informativos, manuais, relatórios, classificados online.

Interativas: formulários de inscrição, apresentação de informações personalizadas, jogos online etc.

Orientadas a Transação: Compras on-line (solicitação de bens e serviços), homebaking, reservas aéreas, etc.

on-line (solicitação de bens e serviços), homebaking, reservas aéreas, etc. Fonte: (Muregesan; Ginige, 2008) 23

Fonte: (Muregesan; Ginige, 2008)

23

on-line (solicitação de bens e serviços), homebaking, reservas aéreas, etc. Fonte: (Muregesan; Ginige, 2008) 23

Categorias de Aplicações Web

Orientadas a Workflow: planejamento e programação online, gestão de estoque, monitoramento, gerenciamento da cadeia de

fornecimento etc.

Ambiente de Trabalho Cooperativo: sistemas de auditoria distribuída, ferramentas de design colaborativo etc.

Comunidades e mercados online: provêm serviços de

comunicação entre uma comunidade de usuários via salas de bate-papo, mensagens instantâneas etc; Ex.: grupos de

discussão, sistemas de recomendação etc.

instantâneas etc; Ex.: grupos de discussão, sistemas de recomendação etc. Fonte: (Muregesan; Ginige, 2008) 24

Fonte: (Muregesan; Ginige, 2008)

24

instantâneas etc; Ex.: grupos de discussão, sistemas de recomendação etc. Fonte: (Muregesan; Ginige, 2008) 24

Categorias de Aplicações Web

• WebApps de Download: permitem que seus usuários “baixem” arquivos de servidores apropriados.

Sistemas de Informação Web: sistemas de informação disponíveis na Web.

Portais: pontos de entrada geral, de um tema específico ou de uma organização, provendo acesso a diversos serviços.

Orientadas a Serviços

Data Warehousing

etc.

de uma organização, provendo acesso a diversos serviços. • Orientadas a Serviços • Data Warehousing •

25

de uma organização, provendo acesso a diversos serviços. • Orientadas a Serviços • Data Warehousing •

Sistemas de Informação

Responsáveis por coletar, manipular e preservar grandes quantidades de informações complexas, relacionadas a

processos de negócio de uma organização.

e preservar grandes quantidades de informações complexas, relacionadas a processos de negócio de uma organização. 26

26

e preservar grandes quantidades de informações complexas, relacionadas a processos de negócio de uma organização. 26

Características de SIs

Grandes volumes de dados

Dados precisam ser armazenados por longos períodos de tempo

Usuários acessam os dados concorrentemente

Fortemente interativos

Necessidade de integração com outros SIs

Necessidade de satisfazer regras de negócio

interativos • Necessidade de integração com outros SIs • Necessidade de satisfazer regras de negócio 27

27

interativos • Necessidade de integração com outros SIs • Necessidade de satisfazer regras de negócio 27

SIs e Atributos de Qualidade

Segurança

Interoperabilidade

Confiabilidade (tolerância a falhas, disponibilidade,

recuperabilidade)

Usabilidade (facilidade de entender, aprender, operar, atratividade)

Eficiência (em relação ao tempo, em relação ao uso de recursos)

Portabilidade

Manutenibilidade (estabilidade, facilidade de analisar, alterar e testar)

ao uso de recursos) • Portabilidade • Manutenibilidade (estabilidade, facilidade de analisar, alterar e testar) 28

28

ao uso de recursos) • Portabilidade • Manutenibilidade (estabilidade, facilidade de analisar, alterar e testar) 28

Fim de papo por hoje

Dúvidas

Fim de papo por hoje Dúvidas 29
Fim de papo por hoje Dúvidas 29

29

Fim de papo por hoje Dúvidas 29

Estilos e Padrões Arquitetônicos

Estilos arquitetônicos: definem um vocabulário de tipos de elementos e tipos de relacionamentos, e um conjunto de restrições sobre como eles podem ser combinados

Padrões arquitetônicos: também estabelecem tipos de elementos e de relacionamentos entre eles.

Sua apresentação segue uma forma bem definida, indicando nome, contexto, problema, solução e consequências.

Especialmente a solução define estratégias para tratar o problema, o que não acontece com os estilos arquitetônicos.

Estilos têm uma apresentação mais livre e são descritos de maneira mais abstrata que padrões arquitetônicos.

• Estilos têm uma apresentação mais livre e são descritos de maneira mais abstrata que padrões

Categorias de Estilos Arquitetônicos

Sistemas de Fluxo de Dados: são caracterizados pelo modo como dados se movem através do sistema. Ex.: Dutos e Filtros.

Sistemas de Chamada e Retorno: são caracterizados por um modelo de ativação que envolve a linha principal de controle que realiza invocações explícitas de operações. Ex.:

Camadas, Partições.

Componentes Independentes: neste estilo, a invocação de uma operação é desacoplada de sua execução. Ex.: Invocação Implícita

Máquinas Virtuais: possuem uma máquina de interpretação, uma memória contendo o pseudocódigo a ser interpretado, uma representação do estado da máquina de interpretação e uma representação do estado corrente do programa Ex.: Sistemas

Baseados em Regras.

Repositórios: envolvem um repositório de dados compartilhado para a troca de informações. Ex.: Estilos baseados em banco de dados, Quadro-negro.

repositório de dados compartilhado para a troca de informações. Ex.: Estilos baseados em banco de dados,
repositório de dados compartilhado para a troca de informações. Ex.: Estilos baseados em banco de dados,

Estilos Arquitetônicos

Podem (e devem) ser combinados.

É sempre uma boa opção considerar a combinação de estilos

durante o projeto de uma arquitetura.

Uma arquitetura pode combinar diferentes estilos em partes distintas de um sistema, de modo a exibir diferentes atributos de qualidade.

pode combinar diferentes estilos em partes distintas de um sistema, de modo a exibir diferentes atributos

Dutos e Filtros

Considera a existência de uma rede pela qual dados fluem de uma extremidade (origem) até a outra (destino).

O fluxo de dados se dá através dos dutos e os dados sofrem

transformações nos filtros.

Um duto provê uma forma unidirecional de fluxo de dados, atuando como um condutor entre dois componentes, do componente origem para o componente destino.

de fluxo de dados, atuando como um condutor entre dois componentes, do componente origem para o

Dutos e Filtros

Filtros

Dutos e Filtros Filtros Dutos
Dutos e Filtros Filtros Dutos
Dutos e Filtros Filtros Dutos
Dutos e Filtros Filtros Dutos

Dutos

Dutos e Filtros Filtros Dutos

Dutos e Filtros

Cada componente (filtro) possui um conjunto de entradas e um conjunto de saídas.

Um componente lê dados de suas entradas e produz dados em suas saídas, realizando alguma transformação local.

Os filtros são independentes uns dos outros e não compartilham informações internas.

Um filtro não conhece os filtros anteriores e posteriores no fluxo.

A especificação de um filtro define apenas o que deve aparecer nos dutos de entrada e garantir o que vai aparecer nos dutos de saída, sem, no entanto, identificar os componentes nas extremidades desses dutos.

o que vai aparecer nos dutos de saída, sem, no entanto, identificar os componentes nas extremidades

Dutos e Filtros

Pipelines: restringem a topologia para sequências lineares de filtros.

Quando em um pipeline, cada filtro processa a sua entrada

como um todo, tem-se um estilo de transformação em lote sequencial.

em um pipeline , cada filtro processa a sua entrada como um todo, tem-se um estilo

Dutos e Filtros

Vantagens:

Facilita o reuso: quaisquer dois filtros podem ser conectados,

desde que eles estejam de acordo em relação aos dados sendo

transmitidos entre eles.

Facilita a manutenção e o crescimento: novos filtros podem ser adicionados a um sistema existente, bem como filtros podem ser substituídos por outros melhores ou atualizados.

podem ser substituídos por outros melhores ou atualizados. – Suporta execução concorrente: cada filtro pode ser

Suporta execução concorrente: cada filtro pode ser implementado como uma tarefa separada e potencialmente executada em paralelo com outros filtros.

cada filtro pode ser implementado como uma tarefa separada e potencialmente executada em paralelo com outros

Dutos e Filtros

Desvantagens:

O projetista deve pensar cada filtro como provendo uma

transformação completa dos dados de entrada para dados de

saída.

Devido a seu caráter transformacional, este estilo não cai bem

para tratar aplicações interativas.

Exemplos

UNIX pipes

Compiladores

este estilo não cai bem para tratar aplicações interativas. • Exemplos – UNIX pipes – Compiladores

Camadas

Sistemas são organizados hierarquicamente, como um conjunto ordenado de camadas, cada uma delas construída

em função das camadas abaixo e fornecendo serviços para as

camadas acima.

O conhecimento é unidirecional: uma camada conhece as camadas abaixo, mas não as camadas acima.

Há uma relação cliente-servidor entre uma camada usuária

de serviços e suas camadas inferiores, provedoras de

serviços.

uma relação cliente-servidor entre uma camada usuária de serviços e suas camadas inferiores, provedoras de serviços.

Camadas Fechadas e Abertas

Camadas fechadas: uma camada é construída apenas em função da camada imediatamente inferior.

Reduz a dependência entre as camadas, permitindo que alterações sejam feitas mais facilmente

Camadas abertas: uma camada pode usar recursos de quaisquer camadas inferiores.

camada pode usar recursos de quaisquer camadas inferiores. – Reduz a necessidade de redefinir operações em

Reduz a necessidade de redefinir operações em vários níveis, o que tende a resultar em melhor desempenho.

Mudanças em uma camada podem afetar qualquer camada acima, tornando a arquitetura menos robusta e comprometendo a manutenibilidade do sistema.

podem afetar qualquer camada acima, tornando a arquitetura menos robusta e comprometendo a manutenibilidade do sistema.

Camadas

Geralmente

chamadas de

procedimento

Camadas Geralmente chamadas de procedimento Camadas Arquitetura Fechada Arquitetura Aberta
Camadas Geralmente chamadas de procedimento Camadas Arquitetura Fechada Arquitetura Aberta

Camadas

Camadas Geralmente chamadas de procedimento Camadas Arquitetura Fechada Arquitetura Aberta

Arquitetura Fechada

Arquitetura Aberta

Camadas Geralmente chamadas de procedimento Camadas Arquitetura Fechada Arquitetura Aberta

Camadas

Vantagens:

Separação de preocupações: o projeto é baseado em níveis crescentes de abstração, permitindo dividir um problema complexo em uma sequência de passos incrementais, tratando de diferentes preocupações.

Facilita a manutenção e o crescimento, especialmente as arquiteturas fechadas, pois alterações em uma camada afetam apenas a camada adjacente superior. Diferentes implementações da mesma camada podem ser usadas alternativamente, desde que provejam as mesmas interfaces para as camadas superiores.

Facilita o reuso.

ser usadas alternativamente, desde que provejam as mesmas interfaces para as camadas superiores. – Facilita o

Camadas

Desvantagens:

Nem todos os sistemas são facilmente estruturados em camadas,

sendo muitas vezes difícil encontrar os níveis de abstração e

número de camadas corretos.

Considerações de desempenho podem colocar obstáculos,

sobretudo para o uso de arquiteturas fechadas.

corretos. – Considerações de desempenho podem colocar obstáculos, sobretudo para o uso de arquiteturas fechadas.

Partições

Dividem um sistema verticalmente em subsistemas fracamente acoplados.

As partições podem ter algum conhecimento acerca das

outras, mas esse conhecimento não é profundo e evita maiores dependências de projeto.

ter algum conhecimento acerca das outras, mas esse conhecimento não é profundo e evita maiores dependências

Partições

Partições mutuamente dependentes

Partição 1

Partição 2

Partições Partições mutuamente dependentes Partição 1 Partição 2 Partição n Partições independentes

Partição n

Partições independentes

Partições Partições mutuamente dependentes Partição 1 Partição 2 Partição n Partições independentes

Partições x Camadas

Ao contrário das camadas, que variam em seu nível de abstração, as partições simplesmente dividem um sistema em partes, todas tendo um nível de abstração semelhante.

Camadas dependem umas das outras, enquanto as

partições podem ser tanto independentes como

mutuamente dependentes.

• Camadas dependem umas das outras, enquanto as partições podem ser tanto independentes como mutuamente dependentes.

Partições

Normalmente, o uso de partições simplesmente não é suficiente para estruturar um sistema.

Boa opção: combinar partições e camadas:

Partições divididas em camadas (mais comum)

Camadas divididas em partições

combinar partições e camadas: – Partições divididas em camadas (mais comum) – Camadas divididas em partições

Invocação Implícita

Um componente pode anunciar eventos.

Outros componentes podem registrar interesse por um evento, associando um procedimento a ele.

Quando um evento é anunciado, o sistema invoca todos os procedimentos registrados para o evento.

Assim, o anúncio de um evento implicitamente provoca a invocação de procedimentos em outros componentes.

o evento. • Assim, o anúncio de um evento implicitamente provoca a invocação de procedimentos em

Invocação Implícita

Componente Ouvinte 1

Invocação Implícita Componente Ouvinte 1 Componente Anunciante Mecanismo de Difusão de Eventos evento Invocação de

Componente

Anunciante

Mecanismo de Difusão de Eventos

evento

Anunciante Mecanismo de Difusão de Eventos evento Invocação de procedimento registrado, passando evento

Invocação de procedimento

registrado, passando evento

Mecanismo de Difusão de Eventos evento Invocação de procedimento registrado, passando evento Componente Ouvinte n

Componente Ouvinte n

Mecanismo de Difusão de Eventos evento Invocação de procedimento registrado, passando evento Componente Ouvinte n

Invocação Implícita

Vantagens:

Suporta execução concorrente: Eventos são assíncronos, o que permite

que o componente anunciante continue realizando alguma outra

computação após o envio do evento.

Facilidade de manutenção e crescimento:

O componente anunciante desconhece a identidade dos componentes ouvintes.

Componentes podem ser introduzidos no sistema simplesmente registrando-os como ouvintes de eventos do sistema.

Componentes podem ser substituídos por outros, sem afetar as interfaces de outros componentes do sistema.

sistema. • Componentes podem ser substituídos por outros, sem afetar as interfaces de outros componentes do

Invocação Implícita

Desvantagens:

Dificuldade de ordenar o processamento

Uma vez que o componente anunciante desconhece os componentes ouvintes,

não se pode fazer suposições acerca da ordem de processamento, nem mesmo

sobre que processamento vai ocorrer como resultado de seus eventos.

A maioria dos sistemas de invocação implícita também inclui invocação explícita como uma forma de interação complementar.

Exemplo: Tratamento de exceções

também inclui invocação explícita como uma forma de interação complementar. • Exemplo: Tratamento de exceções

Sistemas Baseados em Regras

Sistemas de apoio à decisão que procuram representar o modo de raciocínio e o conhecimento utilizado por

especialistas na resolução de problemas no seu âmbito de

especialidade.

Problemas propícios a serem tratados por SBRs: aqueles resolvidos por um especialista humano e que podem ser expressos mediante um conjunto de regras bem definidas

para analisar o problema. Ex.: planejamento, diagnóstico,

interpretação de dados.

um conjunto de regras bem definidas para analisar o problema. Ex.: planejamento, diagnóstico, interpretação de dados.

Sistema Baseado em Regras x Sistema Tradicional

Aplicações tradicionais (procedimentais, OO ou funcionais):

conhecimento sobre o domínio do problema é codificado tanto

nas instruções propriamente ditas quanto nas estruturas de

dados.

Abordagem de regras: todo o conhecimento relativo ao domínio do problema é codificado exclusivamente nas estruturas de dados. Nenhum conhecimento é armazenado

nas instruções ou nos programas propriamente ditos.

nas estruturas de dados. Nenhum conhecimento é armazenado nas instruções ou nos programas propriamente ditos.

Sistemas Baseados em Regras

Arquitetura geral compreende dois componentes principais:

Base de conhecimento: um conjunto de declarações totalmente

dependentes do domínio do problema,

Máquina de inferência: programa independente do domínio do problema, apesar de altamente dependente das estruturas de dados.

de inferência: programa independente do domínio do problema, apesar de altamente dependente das estruturas de dados.

Sistemas Baseados em Regras

Base de conhecimento: divida em base de regras e base de fatos.

Base de regras contém as regras que definem como derivar

informações a partir dos fatos,

Fatos: informações acerca do estado do domínio.

Formato das regras: Se condição então ação

Máquina de inferência: responsável por efetuar o

processamento.

É independente do conhecimento do domínio do problema.

de inferência: responsável por efetuar o processamento. – É independente do conhecimento do domínio do problema.

Sistemas Baseados em Regras

Outros componentes:

Memória: armazena temporariamente fatos iniciais e conclusões

intermediárias

Interface com o usuário: front-end para interação com o usuário, a partir da qual se introduzem novos fatos do problema e se

recebem os resultados ou conclusões retiradas pelo sistema.

a partir da qual se introduzem novos fatos do problema e se recebem os resultados ou

Sistemas Baseados em Regras

Interface com o Usuário

Memória

Fatos e regras

Base de Conhecimento
Base de
Conhecimento

Mecanismo de Inferência

Sistemas Baseados em Regras Interface com o Usuário Memória Fatos e regras Base de Conhecimento Mecanismo
Sistemas Baseados em Regras Interface com o Usuário Memória Fatos e regras Base de Conhecimento Mecanismo

Fim de papo por hoje

Dúvidas

Fim de papo por hoje Dúvidas 58
Fim de papo por hoje Dúvidas 58

58

Fim de papo por hoje Dúvidas 58

Padrões Arquitetônicos

Um padrão descreve um problema que ocorre diversas vezes e o núcleo central de uma solução para esse problema.

Padrões advêm de observações do que funciona na prática e,

portanto, eles não são inventados, mas descobertos.

• Padrões advêm de observações do que funciona na prática e, portanto, eles não são inventados,

Padrões Arquitetônicos

Padrões são um ponto de partida.

É importante ter uma visão geral dos padrões para saber que

problemas eles resolvem e como eles resolvem, de modo a

selecioná-los quando forem aplicáveis.

Uma vez reconhecida a necessidade de se aplicar o padrão, tem-se de descobrir como aplicá-lo ao problema específico que se tem em mãos.

a necessidade de se aplicar o padrão, tem-se de descobrir como aplicá-lo ao problema específico que

Padrões Arquitetônicos

Padrões são artefatos semi-prontos, o que implica na necessidade de completar a solução no contexto específico do

projeto.

Padrões são relativamente independentes, mas não são isolados uns dos outros, sobretudo os padrões arquitetônicos. Muitas vezes, um padrão leva a outros ou um padrão só é aplicável se outro estiver envolvido.

arquitetônicos. Muitas vezes, um padrão leva a outros ou um padrão só é aplicável se outro

Sistemas de Informação

São usados para prover informações para apoiar processos de negócio e apresentam como características marcantes:

grandes quantidades de dados que precisam ser armazenados

por longos períodos de tempo,

usuários acessando o sistema de maneira concorrente por meio de interfaces com o usuário,

regras de negócio que devem ser consideradas para que o sistema satisfaça as necessidades de seus usuários

– regras de negócio que devem ser consideradas para que o sistema satisfaça as necessidades de

Padrões Arquitetônicos para SIs

Catálogo de Fowler (2003): estilo subjacente aos padrões apresentados é o estilo em camadas.

Há também design patterns utilizados para realizar a

arquitetura.

Assim, em (FOWLER, 2003) não há uma clara separação entre padrões arquitetônicos e design patterns.

• Assim, em (FOWLER, 2003) não há uma clara separação entre padrões arquitetônicos e design patterns.

Padrões Arquitetônicos para SIs

If Then Else If Then Else
If
Then
Else
If
Then
Else
Arquitetônicos para SIs If Then Else If Then Else Camada de Interface com o Usuário Camada

Camada de Interface com o Usuário

Then Else If Then Else Camada de Interface com o Usuário Camada de Gerência de Dados

Camada de Gerência de Dados

Camada de

Lógica do

Negócio

Then Else If Then Else Camada de Interface com o Usuário Camada de Gerência de Dados

Padrões Arquitetônicos para SIs

If Then Else If Then Else Camada de Interface com o Usuário • Script de
If
Then
Else
If
Then
Else
Camada de
Interface com
o Usuário
• Script de Transação
• Modelo de Domínio
• Módulo Tabela
• Camada de Serviço

Camada de Gerência de Dados

Camada de

Lógica do

Negócio

Modelo de Domínio • Módulo Tabela • Camada de Serviço Camada de Gerência de Dados Camada
Modelo de Domínio • Módulo Tabela • Camada de Serviço Camada de Gerência de Dados Camada

Padrões Arquitetônicos para SIs

If Then Else If Then Else Camada de Interface com o Usuário • Registro Ativo
If
Then
Else
If
Then
Else
Camada de
Interface com
o Usuário
• Registro Ativo
• Mapeador de Dados
• Objeto de Acesso a Dados (DAO)
Padrões de mapeamento objeto relacional
Camada de
Gerência de
Dados

Camada de

Lógica do

Negócio

a Dados (DAO) Padrões de mapeamento objeto relacional Camada de Gerência de Dados Camada de Lógica

Padrões Arquitetônicos para SIs

If Then Else If Then Else
If
Then
Else
If
Then
Else

Camada de Gerência de Dados

If Then Else If Then Else Camada de Gerência de Dados Camada de Interface com o

Camada de Interface com o Usuário

• Modelo Visão Controlador (MVC) • Controlador de Aplicação Visão (p.ex., Template View) Controladores (p.ex.,
• Modelo Visão Controlador (MVC)
• Controlador de Aplicação
Visão (p.ex., Template View)
Controladores (p.ex., Controlador Frontal)

Camada de

Lógica do

Negócio

de Aplicação Visão (p.ex., Template View) Controladores (p.ex., Controlador Frontal) Camada de Lógica do Negócio

Padrões Arquitetônicos para SIs

Catálogo de Fowler

Outros padrões: Concorrência e Estado de Sessões

Estrutura: nome, intenção, esboço (representação gráfica), problema, solução, quando usar o padrão e leitura adicional.

Outro catálogo: POSA (Pattern Oriented Software Architecture)

É, na verdade, um conjunto de catálogos de propósito mais geral, enfocando diversos aspectos e envolvendo tanto padrões arquitetônicos como padrões de projeto, idiomas e linguagens de padrões.

diversos aspectos e envolvendo tanto padrões arquitetônicos como padrões de projeto, idiomas e linguagens de padrões.

Projeto de SIs

Abordagem Predominante: combinação de partições e camadas.

Combinação com outros estilos em módulos específicos do SI.

P.ex., Invocação Implícita para tratamento de erros.

Combinação com outros estilos em módulos específicos do SI. P.ex., Invocação Implícita para tratamento de erros.

Projeto de SIs Distribuídos

• Arquiteturas ditas “cliente-servidor”

Arquitetura de Hardware

2 camadas (two tier)

3 camadas (three tier)

n camadas

“cliente - servidor” • Arquitetura de Hardware – 2 camadas (two tier) – 3 camadas (three

Fim do Capítulo de Arquitetura

Fim do Capítulo de Arquitetura 71
Fim do Capítulo de Arquitetura 71

71

Fim do Capítulo de Arquitetura 71