Arquitetura de Software

Transcrição

1 Arquitetura de Software Jair C Leite Arquitetura e Engenharia Qual o papel da arquitetura e da engenharia... Na construção civil edifícios, pontes, estradas, etc.? Na indústria automobilística? Na indústria de eletrônicos televisores, tocadores de DVD, de CD, de MP3? Os papéis podem variar, mas algumas características comuns podem ser identificadas... É preciso que alguém idealize, defina e conceba o produto ou artefato de acordo com os requisitos É preciso que alguém execute e realize o que foi idealizado, definido e concebido. 1

2 Limitações das analogias A natureza do software não é física, é conceitual O software é uma máquina abstrata que processa informações e toma decisões Indústria de software é imatura e não está completamente estabelecida. A forma como um software é entregue (configuração e instalação) é diferente dos outros produtos. Design e Arquitetura na ES Tradicionalmente na engenharia de software, usa-se os termos Design arquitetural Design detalhado No modelo cascata eles são fases do processo No modelo RUP eles são disciplinas que ocorrem em várias fases A arquitetura é o produto 2

3 O papel da arquitetura de software Sub-sistemas ou módulos Class a { int x; char v; Func(a,b } Class b... Codificação Compilação e Ligação Produto final Componentes Binários executáveis Modelo abstrato do do programa em em termos de de componentes (sub-sistemas, módulos, etc..) etc..) interconectados entre entre si. si. Modelo Modelo abstrato abstrato --Modelo estático: estrutura dos dos componentes componentes --Modelo dinâmico: físicos físicos que que comportamento formam formam o produto produto --Diferentes Visões final Visões final Arquiteto de software Conceitos fundamentais Arquitetura é o conjunto das principais decisões de design sobre um sistema de software Três aspectos fundamentais Todo software tem uma arquitetura Todo software tem pelo menos uma arquitetura Arquitetura não é uma fase do desenvolvimento. A arquitetura está fundamentalmente ligada aos requisitos Funcionais Não-funcionais 3

4 O que é Arquitetura de Software? Uma descrição abstrata de diferentes visões do sistema em termos de unidade (partes) que interagem entre si. As unidades podem variar dependendo da visão utilizada. Por exemplo, as partes podem ser componentes e conectores; ou sub-sistemas e módulos. A arquitetura deve dar suporte à funcionalidade do sistema (requisitos funcionais). A arquitetura deve está em conformidade com a qualidade (requisitos não-funcionais). O que não é arquitetura de software? Design detalhado (baixo-nível) design de componentes internos, modelos de dados e implementação Arquitetura do sistema físico elementos processadores, topologia de rede, arquitetura de elementos de hardware, etc. Arquitetura de software está relacionada com estes últimos no que se chama de Arquitetura do Sistema. Uma fase do processo de software. 4

5 Histórico Visão tradicional Conceito de Sub-sistema e Módulos Arquitetura nos Métodos Estruturados Arquitetura nos Métodos Orientados-a-Objetos Visão atual Disciplina emergente [Shaw e Garlan] Estilo arquiteturais Padrões de Design e Frameworks Visões Arquiteturais Linguagens de Descrição Arquitetural (ADL) Desenvolvimento Baseado em Componentes Arquitetura de Software nos Métodos Estruturados Objetivos: Visão abstrata em termos de módulos e funções/procedimentos Diminuir complexidade e facilitar manutenção Princípios: Dividir-e-conquistar Informação escondida Independência Funcional Alta coesão e baixo acoplamento Técnicas Decomposição Funcional Refinamento sucessivo (passo-a-passo) Representação Diagramas de caixas e linhas Linguagens de descrição de módulos 5

6 Estilo de arquitetura A arquitetura básica é hierárquica: um programa principal decomposto em várias sub-rotinas ou funções Sub-rotinas podem ser agrupadas em módulos Forma de Interação: Chamada-de-função e passagem de parâmetros Conceitos: Fan-in e Fan-out: mede o grau de dependência entre as sub-rotinas. Coesão e Acoplamento: uma boa arquitetura deve ter alta coesão e baixo acoplamento Sub-rotinas módulos Fan-in Fan-out Baixa coesão Alto acoplamento Alta coesão Baixo acoplamento Arquitetura de Software nos Métodos Orientados-a-Objetos Objetivos Agrupamento de dados e funções num único componente Visão abstrata em termos de classes/objetos e troca de mensagens Princípios: Independência Conceitual Encapsulamento Técnicas Identificação de objetos Especialização de objetos (Herança) Padrões de Projetos (Design Patterns) Representação UML: diagramas de classes, de seqüência, de colaboração e de estados 6

7 Exemplo Sistema estação meteorológica subsistemas e módulos «subsystem» Data collection «subsystem» Data display Observer Weather station Co mms Satellite Balloon User interface Ma p Ma p display Ma p printer «subsystem» Data processing Da ta checking Da ta integration «subsystem» Data archiving Map store Da ta storage Da ta store Fonte: Ian Sommerville, 2000 Exemplo Sistema estação meteorológica classes de um módulo WeatherStation identifier reportweather () calibrate (instruments) test () startup (instruments) shutdown (instruments) WeatherData airtemperatures groundtemperatures windspeeds win ddirections pressures rainfall collect () summarise () Ground thermometer temperature test () calibrate () Fonte: Ian Sommerville, 2000 Anemometer windspeed win ddirection test () Ba rom eter pressure height test () calibrate () 7

8 Arquitetura de Software visão emergente Objetivos Visão abstrata do software através de componentes e interfaces Independência de plataforma e paradigma de programação Paradigma de desenvolvimento baseado em componentes Técnicas Estilos Arquiteturais Padrões de projetos (Design Patterns) Frameworks Visões arquiteturais Tecnologias CORBA,.NET, J2EE Representação Linguagens de Descrição Arquitetural Estilos arquiteturais Identificados em diversas aplicações de sucesso Modelo em camadas OSI/ISO para redes Notificador em Sistemas de Janelas Pipes em Sistemas Unix Não são modelos, são conjunto de características comuns Mais de um estilo pode ser utilizado em uma mesma aplicação Semelhanças com a idéia de Patterns 8

9 Tubos e filtros (pipe-and-filter) Um Filtro é um componente que processa o fluxo de dados de sua entrada e gera um fluxo de saída para um outro filtro Fluxo de dados vai de um Filtro para o outro através de Tubos Exemplo Abrindo uma imagem compactada e criptografada Facilmente implementado no Unix ls grep java more req req req Application P Decompression P Decryption P OS File- System Visões arquiteturais Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade. Cada visão descreve diferentes conceitos da engenharia. Visões permitem reduzir a quantidade de informação que o arquiteto trata em um dado momento Muitos arquitetos de software tem usado as diferentes visões sem reconhecê-las como visões arquiteturais separadas. 9

10 Visões arquiteturais (Hofmeister, 2000) Visões arquiteturais (Hofmeister, 2000) Quatro visões: Conceitual: descreve o sistema em termos dos elementos de design e relacionamentos entre eles Módulo: consiste na decomposição do sistema em módulos Execução: consiste no mapeamento dos componentes a entidades de execução e de hardware. Este mapeamento deve ser definido na fase de projeto arquitetural e não apenas na fase de desenvolvimento. Código: consiste na organização do código fonte em bibliotecas, binários, arquivos, versões e diretórios 10

11 Visão conceitual Mais próxima ao domínio da aplicação A funcionalidade do sistema é mapeada em elementos arquiteturais: Componentes, conectores, configuração Desafio: Isolar comunicação entre componentes em conectores Notação utilizada Variação da UML componentes, conectores descritos como classes estereotipadas. componente porta role conector Visão conceitual 11

12 Visão de módulo Componentes e Conectores que formam a visão conceitual são mapeados em subsistemas, módulos e camadas Sub-sistemas Partes que podem funcionar de forma independentes Podem conter módulos ou outros sub-sistemas Módulos Implementam os elementos conceituais (componentes, conectores, portas e roles) Podem conter outros módulos Camadas Organizam módulos de acordo com o seu uso. Princípios: Dependências entre módulos devem ser minimizadas Reuso de módulos deve ser maximizado Visão de módulos 12

13 Visão de execução Descreve como os módulos são mapeados para elementos oferecidos pela plataforma de execução e como estes são mapeados para o hardware Define entidades de execução e seus atributos como uso de memória e de elementos de hardware Exemplos de elementos de execução Processo (<<process>>) Memória compartilhada (<<shared data>>) Visão de execução 13

14 Visão de execução Relação com o hardware Visão de código Determina: como módulos (visão de módulo) são mapeados em componentes fonte como componentes do nível de implementação são mapeados a partir dos componentes fonte como as entidades de execução são mapeadas em componentes do nível de implementação (p.ex. executáveis) 14

15 Visão de codificação Organização do fonte Visão de codificação 15

16 Relacionamento entre as Visões Há necessidade de feedback e interação entre as visões As visões módulo, execução e código auxiliam a diminuir o gap entre o que uma ADL modela e o que uma plataforma de execução pode executar. Componentes e conectores da visão conceitual não podem ser diretamente mapeados para uma plataforma de execução As visões módulo e execução definem como componentes e conectores são mapeados para uma plataforma de execução 16