Engenharia de Software Projeto de Arquitetura de Software Mai/2010

Processos de Software Atividades de Processo – Ex. Ciclo Tradicional Definição de Requisitos Projeto de Sistema e Software Implementação e Teste de Unidade Integração e Teste de Sistema Operação e Manutenção

Projeto e Implementação de SW Atividades do Projeto -> Produtos do Projeto Projeto de Arquitetura -> Arquitetura de Sistema Especificação Abstrata -> Especificação de Software Projeto de Interface -> Especificação de Interface Projeto de Componente -> Especificação de Componente Projeto de Estrutura de Dados -> Especif. de Estrutura de Dados Projeto de Algoritmo -> Especificação de Algoritmo

Projeto de Arquitetura Sistemas grandes são sempre decompostos em subsistemas que fornecem algum conjunto de serviços relacionados. Processo inicial de projeto consiste em identificar os subsistemas e estabelecer um framework para o controle e comunicação de subsistemas.

Projeto de Arquitetura Vantagens de projetar e documentar explicitamente uma arquitetura de software: Comunicação de stakeholders – apresentação em alto nível para discussão com diferentes stakeholders Análise de Sistema – Explicita decisões de arquitetura para atender requisitos não funcionais. Reuso em larga escala – Arquitetura de sistema é muitas vezes a mesma para sistemas com requisitos similares.

Projeto de Arquitetura A arquitetura do sistema afeta o desempenho, facilidade de distribuição e manutenção de um sistema. O estilo e a estrutura específicos escolhidos podem depender dos requisitos não funcionais do sistema: Desempenho Proteção Segurança Disponibilidade Facilidade de Manutenção

Projeto de Arquitetura Decisões de Projeto de Arquitetura Organização de Sistema Estilos de Decomposição Modular Modelos de Controle Arquiteturas de Referência

Projeto de Arquitetura Decisões de Projeto de Arquitetura Organização de Sistema Estilos de Decomposição Modular Modelos de Controle Arquiteturas de Referência

Decisões de Projeto de Arquitetura Existe uma arquitetura genérica de aplicação que possa funcionar como um modelo para o sistema que está sendo projetado? (ex. Sistemas do mesmo Domínio de conhecimento) Como o sistema será distribuído ao longo de vários processadores? (sistemas grandes x sistemas pessoais) Qual ou quais estilos de arquitetura são apropriados para o sistema? (cliente servidor, em camadas) Qual será a abordagem fundamental usada para estruturar o sistema? Como as unidades estruturais do sistema serão decompostas em módulos? Qual estratégia será usada para controlar as operações das unidades no sistema? Como a arquitetura do sistema deve ser documentada?

Decisões de Projeto de Arquitetura Produto: Documento de Projeto de Arquitetura Inclui: Representações gráficas do sistema Texto descritivo associado Como o sistema está estruturado em subsistemas Qual abordagem adotada Como cada subsistema está estruturado em módulos

Decisões de Projeto de Arquitetura Modelos podem ser: Modelo estático de estrutura (mostra os subsistemas desenvolvidos como unidades separadas) Modelo dinâmico de processo (mostra como o sistema está organizado em tempo de execução) Modelo de interface (Define os serviços oferecidos por cada subsistema por meio de suas interfaces públicas) Modelo de relacionamentos (mostra os relacionamentos entre os subsistemas tal como fluxo de dados) Modelo de distribuição (mostra como os subsistemas podem ser distribuídos entre computadores / regiões)

Projeto de Arquitetura Decisões de Projeto de Arquitetura Organização de Sistema Estilos de Decomposição Modular Modelos de Controle Arquiteturas de Referência

Organização de Sistema A organização reflete a estratégia básica usada pra estruturação. A organização pode refletir-se diretamente na estrutura do subsistema.

Organização de Sistema Estilos organizacionais normalmente utilizados: Modelo de Repositório Modelo Cliente-servidor Modelo em Camadas

Modelo de Repositório Os subsistemas que constituem um sistema devem trocar informações de modo que possam trabalhar juntos eficientemente. Duas maneiras: Todos os dados compartilhados são mantidos em um BD que pode ser acessado por todos os subsistemas.(Repositório) Cada subsistema mantém seu próprio BD. Os dados são trocados com outros subsistemas por meio da passagem de mensagens entre eles.

Modelo de Repositório Vantagens: Maneira eficiente de compartilhamento de grandes quantidades de dados. Não há necessidade de transmitir dados explicitamente de um subsistema para outro. Porém, os subsistemas devem estar de acordo com o modelo de dados do repositório. Os subsistemas que produzem dados não precisam saber como esses dados são usados por outros subsistemas. Evolução pode ser difícil, quando um grande volume de informações é gerado de acordo com o modelo de dados atual. Atividades de back-up, proteção, controle de acesso e recuperação de erros são centralizadas. Responsabilidade do gerenciador do repositório. Porém, subsistemas diferentes podem ter requisitos diferentes para políticas de proteção, recuperação e backup. Modelo de compartilhamento é visível por meio do esquema de repositório. Distribuição difícil do repositório por uma série de máquinas. Problemas de redundância e inconsistência de dados.

Organização de Sistema Estilos organizacionais normalmente utilizados: Modelo de Repositório Modelo Cliente-servidor Modelo em Camadas

Modelo Client-Servidor Modelo em que o sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços. Os principais componentes são: Conjunto de Servidores que oferem serviços: Servidores de impressão, de gerenciamento de arquivos ... Conjunto de Clientes que usam os serviços Rede.

Modelo Client-Servidor Os clientes precisam saber os nomes dos servidores disponíveis e os serviços que eles fornecem. Os Servidores não precisam saber a identidade dos clientes ou quantos clientes existem. Essencialmente, um cliente faz um pedido a um servidor e espera até receber uma resposta. Vantagem: é uma arquitetura distribuída. É fácil adicionar um novo servidor e integrá-lo ao restante do sistema ou atualizar servidores de maneira transparente sem afetar outras partes do sistema.

Organização de Sistema Estilos organizacionais normalmente utilizados: Modelo de Repositório Modelo Cliente-servidor Modelo em Camadas

Modelo em Camadas Também chamada modelo de máquina abstrata. Organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de serviços Ex. Modelo de referência OSI de protocolos de rede. Cada camada pode ser imaginada como uma máquina abstrata cuja linguagem de máquina é definida pelos serviços fornecidos pela camada. Desempenho pode ser prejudicado devido aos vários níveis de interpretação de comandos.

Projeto de Arquitetura Decisões de Projeto de Arquitetura Organização de Sistema Estilos de Decomposição Modular Modelos de Controle Arquiteturas de Referência

Estilos de decomposição modular Abordagem a ser usada na decomposição de subsistemas em módulos. Não há uma distinção rígida entre a organização do sistema e a decomposição modular. Podemos utilizar os modelos de organização aqui.

Estilos de decomposição modular Não há uma clara distinção entre subsistema e módulos, mas é útil vê-los da seguinte forma: Um subsistema é um sistema em si cuja operação não depende de serviços fornecidos por outros subsistemas. Os subsistemas são compostos de módulos e têm interfaces que são utilizadas para comunicação com outros subsistemas. Um módulo é normalmente um componente de sistema que fornece um ou mais serviços para outros módulos. Ele faz uso de serviços fornecidos por outros módulos.

Estilos de decomposição modular Duas estratégias básicas para decompor um subsistema em módulos: Decomposição orientada a objetos Pipelining orientado a funções

Estilos de decomposição modular Duas estratégias básicas para decompor um subsistema em módulos: Decomposição orientada a objetos Pipelining orientado a funções

Decomposição orientada a objetos Nessa abordagem os módulos são objetos que se comunicam. Vantagens: Objetos não fortemente acoplados a implementação pode ser modificada sem afetar outros objetos. Objetos são representações de entidades do mundo real e assim a estrutura do sistema é rapidamente entendida. Os objetos podem ser reusados.

Decomposição orientada a objetos Desvantagens: Para usar serviços, os objetos devem fazer referência explícita ao nome e à interface de outros objetos. Se uma mudança de interface for necessária para satisfazer propostas de mudança de sistema o efeito dessa mudança sobre todos os usuários do objeto alterado deve ser avaliado.

Estilos de decomposição modular Duas estratégias básicas para decompor um subsistema em módulos: Decomposição orientada a objetos Pipelining orientado a funções

Pipelining orientado a funções Nessa abordagem as transformações funcionais processam suas entradas e produzem saídas. Os dados fluem de uma para outra função e são transformados ao moverem-se sequencialmente. Cada etapa do processamento é implementada como uma transformação. Os dados de entrada fluem através dessas transformações até serem convertidos em saídas. As transformações podem ser executadas sequencial ou paralelamente.

Pipelining orientado a funções Vantagens: Apóia o reuso das transformações. É intuitiva no sentido de que muitas pessoas pensam em seu trabalho em termos de processamento de entrada e saída. A evolução do sistema pela adição de novas transofmrções é geralmente direta. Ela é simples de ser implementada tanto quanto um sistema concorrente ou sequencial.

Pipelining orientado a funções Desvantagens: Não inclui informação sobre a sequencia de operações. Necessita de um formato comum para transferência de dados que possa ser reconhecido por todas as transformações. Sistemas interativos são difíceis de escrever usando o modelo de pipelining por causa da necessidade de uma sequência de dados ser processada. Enquanto a entrada e saída de textos simples podem ser modeladas dessa maneira, interfaces gráficas com o usuário têm formatos e controle de entrada/saída mais complexos, baseados em eventos como cliques com o mouse ou seleções de menu.

Projeto de Arquitetura Decisões de Projeto de Arquitetura Organização de Sistema Estilos de Decomposição Modular Modelos de Controle Arquiteturas de Referência

Modelos de Controle Existem dois estilos genéricos de controle usados em sistema de software: Controle centralizado: Controle baseado em eventos: Cada subsistema pode responder a eventos gerados externamente.

Controle centralizado Um subsistema tem responsabilidade geral pelo controle e inicia e pára outros subsistemas Duas classes: Modelo chamada-retorno: O controle começa no topo da hierarquia de subrotina e, através de chamadas de subrotinas, passa para os níveis mais baixos na árvore. É aplicável somente a sistemas sequenciais. Modelo gerenciador: Aplicável a sistemas concorrentes. O gerenciador de sistema controla o início a parada e a coordenação de outros processos do sistema.

Controle centralizado A natureza rígida e restritiva desse modelo é, ao mesmo tempo, um ponto forte e fraco. Ponto forte porque é relativamente simples analisar fluxos de controle e testar como o sistema responderá a entradas específicas. Ponto fraco porque, em operação normal, é difícil lidar com as exceções. Processo controlador do sistema decide quando os processos devem ser iniciados ou interrompidos dependendo das variáveis de estado do sistema. O controlador geralmente está em loop contínuo.

Controle baseado em eventos Em modelos de controle centralizados, as decisões de controle são geralmente determinadas pelos valores de algumas variáveis de estado de sistema. Por outro lado, os modelos orientados a eventos são regidos pelos eventos gerados externamente. Dois modelos de controle orientados a eventos: Modelos de broadcast Modelos orientados a interrupções

Modelos de Broadcast Um evento é transmitido a todos os subsistemas. Qualquer subsistema programado para manipular esse evento pode responder a ele (ex. mouse, teclado...) Os subsistemas registram um interesse em eventos específicos. Quando esses eventos ocorrem, o controle é transferido para o subsistema que pode tratar o evento. A diferença entre este modelo e o modelo centralizado, é que a política de controle não é incorporada ao tratador de eventos e mensagens. Os subsistemas decidem de quais eventos necessitam e o tratador de eventos e mensagens assegura que esses eventos sejam enviados a eles.

Modelos de Broadcast A vantagem dessa abordagem de broadcast é que a evolução é relativamente simples. Um novo subsistema para tratar classes específicas de eventos pode ser integrado por meio do registro de seus eventos no tratador de eventos. Qualquer subsistema pode ativar qualquer outro subsistema sem saber seu nome ou sua localização. Os subsistemas podem ser implementados em máquinas distribuídas. Essa distribuição é transparente a outros subsistemas.

Modelos de Broadcast Desvantagem é que não se sabe se ou quando os eventos serão tratados. Quando um subsistema gera um evento, ele não sabe quais outros subsistemas registraram interesse nesse evento. É bem possível que subsistemas diferentes se registrem para os mesmos eventos.

Modelos orientados a interrupções São usados exclusivamente em sistemas de tempo real nos quais interrupções externas são detectadas por um tratador de interrupções. Há uma série de tipos de interrupções conhecidas com um tratador definido para cada tipo. Cada tipo de interrupção está associado ao local de memória em que o endereço de seu tratador está armazenado. Quando uma interrupção de determinado tipo é recebida, uma chave de hardware transfere o controle imediatamente para seu tratador. Esse tratador de interrupções pode, então, iniciar ou parar outros processos em resposta ao evento sinalizado pela interrupção.

Arquitetura de Aplicações Sistemas de aplicações são criados para atender algumas necessidades de negócios ou organizacionais. Todos os negócios tem muito em comum. Geralmente os sistemas de mesmo tipo possuem arquiteturas similares. Modelos genéricos de estrutura podem ser usados como: Ponto de partida para o processo de projeto de arquitetura Como checklist do projeto Como uma maneira de organização do trabalho da equipe de desenvolvimento Como meio de avaliação de componentes para reuso. Como vocabulário para conversar sobre tipos de aplicações.

Arquitetura de Aplicações Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados Aplicações de Processamento de Transações Sistema de Processamento de Eventos Sistema de Processamento de Linguagens

Arquitetura de Aplicações Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados Aplicações de Processamento de Transações Sistema de Processamento de Eventos Sistema de Processamento de Linguagens

Sistemas de processamento de dados Esses sistemas enfocam os dados e, geralmente, os bancos de dados são várias vezes maiores que os sistemas em si. Os Sistemas de processamento de dados são sistemas de processamento em lotes nos quais os dados são entradas e saídas em lotes de um arquivo ou banco de dados em vez de entradas ou saídas para um terminal de usuário. Esses sistemas selecionam os dados de registros de entrada e, dependendo do valor dos campos nos registros, tomam algumas ações especificadas no programa.

Sistemas de processamento de dados A arquitetura dos sistemas de processamento de lotes tem três componentes principais: Entrada: coleta as entradas de uma ou mais fontes Processamento: realiza a computação usando essas entradas Saída: gera saídas a serem escritas novamente no banco de dados e impressas. Os sistemas de processamento de dados são orientados a funções, em vez de orientados a objetos. Os diagramas de fluxo de dados, são uma boa maneira de descrever a arquitetura desses sistemas.

Arquitetura de Aplicações Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados Aplicações de Processamento de Transações Sistema de Processamento de Eventos Sistema de Processamento de Linguagens

Sistemas de processamento de transações Os Sistemas de processamento de transações são projetados para processar solicitações de informações por usuários de um banco de dados ou solicitações para atualizar o banco de dados. Alguns desses sistemas são versões interativas de sistemas de processamento de lotes. Exemplo de transação: Saque em ATM.

Sistemas de processamento de transações São geralmente sistemas interativos nos quais os usuários enviam solicitações assíncronas de serviço. Primeiro, um usuário faz uma solicitação para o sistema. A solicitação é processada por alguma lógica específica da aplicação. Uma transação é passada para um gerenciador de transações. O gerenciador de transações em geral é incorporado ao SGBD. Depois que o gerenciador de transações assegurar que a transação foi concluída adequadamente, ele sinalizará para a aplicação que o processamento foi finalizado.

Arquitetura de Aplicações Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados Aplicações de Processamento de Transações Sistema de Processamento de Eventos Sistema de Processamento de Linguagens

Sistemas de processamento de eventos Os Sistemas de processamento de eventos respondem aos eventos do ambiente ou da interface com o usuário do sistema. Os Sistemas de tempo real também são sistemas de processamento de eventos, porém os eventos são associados a sensores e atuadores do sistema. Ex.: Processadores de texto, sistemas de apresentação, jogos, sistemas de tempo real.

Arquitetura de Aplicações Podemos classificar os Sistemas de Aplicações em quatro tipos abrangentes: Aplicações de Processamento de Dados Aplicações de Processamento de Transações Sistema de Processamento de Eventos Sistema de Processamento de Linguagens

Sistemas de processamento de linguagens Os Sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representação dessa linguagem como saída. Exemplos: Compiladores, Descrição de dados XML em comandos Sistemas de processamento de linguagem natural que tentam traduzir uma linguagem em outra.