Projeto de Arquitetura

Transcrição

1 Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os modelos gerais de processo de software O levantamento e análise de requisitos Os modelos que compõem o documento de requisitos de software Chegou o momento de planejar como será construído o software Como um software pode ser construído de diversas maneiras, cabe aprender a planejar a construção. Vamos agora conhecer o projeto de arquitetura O que é? É o processo inicial de projeto, que consiste em identificar e estabelecer um framework para o controle e a comunicação de subsistemas Vantagens: Comunicação entre os diversos clientes e usuários do sistema (usada em apresentações, discussões etc) Tornar a arquitetura explícita através de uma análise de sistema. Tem profundo efeito sobre como o sistema vai cumprir com os requisitos críticos. Reuso em larga escala. A arquitetura permite a identificação de projetos padrões. Requisitos Influenciados Desempenho Se o desempenho for um requisito crítico, a arquitetura deve ser projetada para localizar operações críticas dentro de alguns subsistemas, com tão pouca comunicação quanto possível entre eles. Isso pode significar o uso de componentes de alta granularidade para reduzir as comunicações entre eles. Proteção Se a proteção for um requisito crítico, uma estrutura em camadas para a arquitetura deve ser usada, com itens mais críticos protegidos por camadas mais internas e com um alto nível de validação de proteção aplicado a essas camadas. 1

2 Requisitos Influenciados Segurança Se a segurança for um requisito crítico, a arquitetura deve ser projetada de modo que as operações relacionadas à segurança estejam todas localizadas em um único subsistema (ou em um pequeno). Isso reduz os custos e os problemas de validação e segurança e torna possível fornecer esse serviço a sistemas de proteção relacionados. Disponibilidade Se a disponibilidade for um requisito crítico, a arquitetura deve ser projetada para incluir componentes redundantes e, assim que possível, substituir e atualizar componentes sem parar o sistema. Requisitos Influenciados Facilidade de manutenção Aqui a arquitetura de sistema deve ser projetada usando componentes de baixa granularidade e autocontidos que possam ser prontamente mudados. Os criadores de dados devem ser separados dos clientes, e estruturas de dados compartilhadas devem ser evitadas. Os conflitos entre os requisitos na arquitetura podem ser resolvidos com o uso de arquiteturas diferentes para as diferentes partes do sistema. Engenharia de requisitos x projeto de arquitetura Existem sobreposições na prática Subsistemas Um subsistema é uma decomposição abstrata de um sistema em componentes de alta granularidade Pode ser substancial e independente Diagramas de blocos são usados para descrever subsistemas Caixas dentro de caixas indicam que o subsistema foi decomposto em subsistemas As setas significam dados e sinais de controle transferidos na indicação da seta Pessoas de diferentes áreas, envolvidas no projeto, podem compreender o diagrama facilmente. Subsistemas Ex.: Diagrama de blocos de um sistema de controle robotizado de empacotamento. visão identificação de objetos de braço seleção de embalagem de garra empacotamento de esteira 2

3 Modelo de repositório Os subsistemas devem trocar informações de modo que possam trabalhar juntos eficientemente. Existem duas maneiras fundamentais de como isso pode ser feito. 1 - Todos os dados compartilhados são mantidos em um banco de dados que pode ser acessado por todos os subsistemas. Um modelo de sistema baseado em um banco de dados compartilhado é algumas vezes denominado modelo de repositório. 2 Cada subsistema mantém seu próprio banco de dados. Os dados são trocados com outros subsistemas por meio da passagem de mensagens entre eles. Modelo de repositório: Vantagens de desvantagens do repositório compartilhado. Maneira eficiente de compartilhar dados Os subsistemas devem estar de acordo com o modelo de dados do repositório Subsistemas que produzem dados não precisam conhecer os que vão usar os dados Uma evolução do sistema pode ser uma tarefa difícil, devido o grande número de dados, relações etc Atividades de back-up up,, proteção, controle de acesso e recuperação de erros são centralizadas Modelo cliente-servidor Onde um sistema é organizado como um conjunto de serviços, servidores e clientes associados que acessam e usam os serviços. Os principais componentes são: Um conjunto de servidores que oferecem serviços para outros subsistemas 1. Um conjunto de servidores que oferecem serviços para Um conjunto de clientes que solicitam serviços. São normalmente subsistemas independentes. 2. Um conjunto de clientes que solicitam serviços. São Uma rede que permite aos clientes acessarem esses serviços. 3. Uma rede que permite aos clientes acessarem esses Modelo cliente-servidor. Exemplo Arquitetura de um sistema de acervo de filmes e fotografias. catálogos Catálogo do acervo Cliente 2 Cliente 2 Cliente N vídeos Arquivos de videoclipe Internet fotografias Fotografias digitalizadas Servidor Web Informações de filmes e fotos 3

4 Modelo em camadas Onde um sistema é organizado em camadas de serviços. Cada camada é responsável por um conjunto de serviços específicos para o sistema. Características: Facilidade na manutenção e troca de código na implementação das camadas, desde que se respeite as interfaces originais. 1. Facilidade na manutenção e troca de código na 2. Apóia o desenvolvimento incremental Desvantagem de ser de difícil estruturação, dependendo da complexidade do problema. 3. Desvantagem de ser de difícil estruturação, dependendo da Modelo em camadas: exemplo de um sistema de gerenciamento de versões. gerenciamento de configuração gerenciamento de objetos banco de dados Camada de sistema operacional Diferença: módulos x subsistemas Não existe uma definição para que haja distinção, mas é interessante pensar que: Subsistemas São sistemas cujas operações não dependem de serviços fornecidos por outros subsistemas. Os subsistemas são compostos por módulos e definem interfaces (usadas para comunicação com outros subsistemas). Módulos São componentes de um subsistema que fornecem um ou mais serviços para outros módulos. Eles também fazem uso de serviços de outros módulos. Dessa forma, não é um sistema independente. Existem duas estratégias principais que se pode usar ao decompor um subsistema em módulos: Decomposição Orientada a Objetos na qual você compõe um sistema em um conjunto de objetos que se comunicam. Objetos chamam serviços oferecidos por outros objetos Na UML, setas tracejadas indicam que um objeto usa os atributos e serviços fornecidos por um outro objeto. Pipelining Orientado a Funções (ou modelo de fluxo de dados) - no qual você decompõe um sistema em módulos funcionais que aceitam dados de entrada e transforma-os os em dados de saída. Vantagem de ser intuitiva e de fácil implementação. Desvantagem de se ter um formato padrão para comunicação 4

5 Modelo de objeto de um sistema de processamento de faturas. Modelo de pipeline de um sistema de processamento de faturas. Cliente nome endereco credito Fatura cliente Recibo Ler faturas emitidas Identificar pagamentos Emitir recibos Recibos Pagamento emissao() enviaraviso() aceitarpagamento() enviarrecibo() Faturas Pagamentos Encontrar pagamentos devidos Emitir lembrete de pagamento Lembrete Modelos de Controle Para que os subsistemas funcionem como sistema, é necessário que exista o controle de seus serviços Controle Centralizado Um subsistema tem a responsabilidade geral de coordenar. Controle baseado em eventos Cada subsistema responde a eventos gerados externamente. Modelos de broadcast evento transmitido a todos os subsistemas. Modelos orientados a interrupções interrupções externas são detectadas (para sistemas de tempo real). 5