Projeto de Arquitetura Cap. 11 Sommerville 8 ed.
Introdução: - O projeto de arquitetura vem após os requisitos. - Sistemas grandes devem ser decompostos em sub-sistemas. - Vantagens de projetar e documentar a arquitetura do software: Comunicação de Stakeholders. Análise de Sistema. Reuso.
- A análise da arquitetura força os projetistas a considerar aspectos principais do projeto no início. - A arquitetura pode ser definida com base nos RNF do sistema, tais: Desempenho (Pouca comunicação, componentes de alta granularidade) Proteção ( Arquitetura de camadas para proteger itens críticos) Segurança ( Sub-sistema exclusivo para tratar a segurança) Disponibilidade ( Componentes redundantes) Facilidade de Manutenção ( Componentes de baixa granularidade)
- Um projeto de subsistema é uma decomposição de um sistema em componentes de alta granularidade, cada um podendo ser um sistema substancial independente. Sistema de Visão Diagrama de Blocos de um sistema de controle robotizado de empacotamento Sistema de identificação de objetos Controlador de braço Controlador de garra Sistema de Seleção de embalagem Sistema de Empacotame nto Controlador de esteira Representação ideal para stakeholders. Omite detalhes importantes para o projeto.
Decisões de projeto de arquitetura: O projeto de arquitetura é um processo criativo em que se tenta estabelecer uma organização do sistema que satisfaça os RF e os RNF. Os arquitetos do sistema precisam responder a questões fundamentais: - Existe uma utilizada? arquitetura genérica que pode ser - Como será a distribuição do sistema entre os vários processadores? - Como as unidades estruturais do sistema será decomposto em módulos? - Como o projeto de arquitetura será avaliado? - Como documentar a arquitetura do sistema?
Estilo de Arquitetura - Escolha da estrutura mais apropriada (Cliente-Servidor, Camadas...) - Estratégia de decomposição do sistema (Módulos, componentes...) - Modelagem e controle (como controlar o sistema)
- O produto do processo de projeto de arquitetura é um documento de projeto de arquitetura, que podem incuir: Modelos estático da arquitetura. Modelos dinâmico do processo. Modelos de interface. Modelos de relacionamentos. modelos de distribuição.
- Os modelos podem ser gráficos, como UML. - Pode ser usados as linguagens de descrição de arquiteturas ADL (Architectural Description Language ).
- Organização do Sistema: Reflete a estratégia básica a ser usada para a estruturação do sistema. - Podem ser usados um único modelo ou vários na solução arquitetural de um sistema.
Modelo de Repositório: Analisador de Projeto Gerador de código Editor de Programa Neste modelo, os sub sistemas devem trocar informações. Todos os dados compartilhados em um BD. Cada sistema possui seu BD e trocam informações. Tradutor de projeto Repositório de Projeto Editor de projeto Gerador de Relatório Arquitetura de um conjunto de ferramentas CASE integradas Vantagens: Maneira eficiente de compartilhar grande quantidade de dados. Facilita o Backup de informações. Desvantagens: Os subsistemas devem estar de acordo com o modelo de repositório. Difícil evolução. Mesma política a todos os subsistemas.
Modelo Cliente-Servidor: Cliente 1 Cliente 2 Cliente 3 INTERNET O sistema é organizado com um conjunto de serviços e servidores. Clientes solicitam serviços disponiveis Uma rede permite o acesso Vantagens: Grande capacidade de fornecimento de serviços, arquitetura distribuida. Facilidade para adicionar novos serviços. Servidor de catálogos Catálogo do acervo Servidor de Vídeos Arquivos de vídeos Servidor de fotografias Fotografias digitalizadas Desvantagens: Problemas com desempenho da rede. Arquitetura de uma aplicação WEB
Modelo em Camadas: Organiza o sistema em camadas, cada uma fornecendo um conjunto de serviços. Camada do sistema de gerenciamento de configuração Camada do sistema de gerenciamento de objetos Vantagens: Apóia o desenvolvimento incremental. Modificável e portável, desde que mantida a sua interface. Camada do sistema de banco de dados Camada do sistema do sistema operacional Modelo em camada de um sistema de gerenciamento de versões. Desvantagens: Difícil estruturação entre as camadas do sistema. Desempenho por causa da necessidade de comunicação direta com a camada seguinte.
Estilo de decomposição modular: - Decisão sobre qual a abordagem será utilizada na decomposição de sub-sistemas em módulos. - Componentes e módulos são menores que subsistemas. - Subsistema é um sistema cuja as operações depende de serviços fornecidos por outros subsistemas. - Módulo normalmente é um componente de sistema que fornece
Decomposição orientada a objeto: Consiste na decomposição de sistemas em objetos que se comunicam entre si. Objetos firmemente acoplados com interfaces definidas. Relaciona-se as classes e objetos do sistema, diagramas da UML pode ser utilizado. Vantagens: - Fácil modificação dos objetos. - Fácil entendimento, objetos representam entidades do mundo real. - Linguagens de programação orientadas a objetos facilitam o desenvolvimento. Desvantagens: - Dependência da interface do objeto. - Entidades complexas são de difícil representação pelo modelo de objeto.
Pipelining orientado a funções: Consiste no processamento das entradas, produzindo saídas através de transformações funcionais. Comum em sistemas de processamento de dados. Vantagens: - Apóia o reuso de informações. - Modelo intuitivo pois muitas pensam em seu trabalho como processamento de entradas gerando uma saída. - A evolução do sistema é feita pela adição de novas transformações. - È simples de ser implantada como sistemas concorrente ou sequencial. Desvantagens: - Necessita de um formato comum para a transferência de dados que possa ser reconhecido por todas as transformações. - Sistemas interativos são difíceis de escrever por impossibilidade de termos uma sequência de dados a
Exemplo de decomposição: Orientada a objetos e Pipelining Customer customer# name address credit period Payment invoice# date amount customer# Invoice invoice# date amount customer issue () sendreminder () acceptpayment () sendreceipt () Receipt invoice# date amount customer# Issue receipts Receipts Read issued invoices Identify payments Find payments due Issue payment reminder Reminders Invoices Payments
Modelos de controles: Necessário para controlar o funcionamento dos subsistemas. Serviços certos no tempo certo. São usados em conjunto com estilos de estrutura.
Controle Centralizado Um subsistema é designado para controlar o sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas. Modelo Chamada-Retorno Modelo top-down de sub-rotina onde o controle começa na hierarquia da sub-rotina. Arvore de controle. Modelo Gerenciador Usa um gerenciador de sistema que controla todo o sistema.
Exemplo de controle centralizado: Chamada Retorno e Gerenciador Main program Sensor processes Actuator processes Routine 1 Routine 2 Routine 3 System controller Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2 Computation processes User interface Fault handler
Controle Orientado a Eventos Os sistemas são regidos pela ocorrência de eventos. Modelos de Broadcast Um evento é transmitido a todos os subsistemas. Modelos orientados a interrupções Usado exclusivamente em sistemas de tempo real onde temos um mecanismo para tratar as interrupções.
Exemplo de controle orientado a eventos: Broadcast e Orientado a interrupções Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and messa ge handler Interrupts Interrupt vector Handler 1 Handler 2 Handler 3 Handler 4 Process 1 Process 2 Process 3 Process 4
Arquiteturas de referências Podem ser determinados pelo domínio do problema. Podem ser reutilizados. Modelos Genéricos Englobam as características principais dos sistemas. Ex.: Sistemas de tempo real. Modelos de Referência São modelos abstratos é descrevem uma classe maior de sistemas. Ex.: OSI.
Fim.