Arquitectura de Software

Gedai

Disciplina de Engenharia de Software Instituto Superior de Engenharia do Porto Alunos: André Serafim da Silva Nogueira no 1020498 David Alexandre Guimarães Costa nº 1020518 Filipe Duarte Neves da Costa nº 1050525 Turma: C

Índice Índice ................................................................................................................................ 2 Introdução......................................................................................................................... 3 Arquitectura e o seu significado ....................................................................................... 4 O que é arquitectura?.................................................................................................... 4 O que é arquitectura de software? ................................................................................ 4 Porque é que a arquitectura é importante?.................................................................... 4 Estilos arquitecturais......................................................................................................... 5 Tipos de arquitectura de software................................................................................. 5 Centrada em dados ................................................................................................... 5 Fluxo de dados.......................................................................................................... 6 Chamada e retorno.................................................................................................... 6 Orientadas a objectos................................................................................................ 7 Camadas ................................................................................................................... 7 Analises de alternativas ao projecto arquitectural ............................................................ 8 Resumo ........................................................................................................................... 10 Bibliografia..................................................................................................................... 10

2

Introdução Desde o momento, em que os programas foram divididos em módulos, os sistemas de software passaram a ter arquitecturas e os programadores têm sido responsáveis pelas interacções entre os módulos e as propriedades globais da montagem. Historicamente as arquitecturas têm estado implícitas tanto nos acidentes de implementação como nos sistemas que foram herdados ao longo do tempo. A arquitectura de software e a sua representação tornaram-se temas dominantes em engenharia de software hoje em dia.

3

Arquitectura e o seu significado O que é arquitectura? Arquitectura é a maneira pela qual os vários componentes de algo (edifício, hardware, software, etc.) são integrados para formar um todo coeso. O modo como o produto se ajusta ao ambiente e se mistura com os outros produtos já existentes interligando-se a esses e estabelecendo padrões das mais diversas formas, está implícito no conceito de arquitectura, tal como o sentido estético do produto, o modo pelo qual texturas, cores, materiais, etc. são combinados para criar o produto final.

O que é arquitectura de software? Arquitectura de software de um programa ou de um sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis e as relações entre elas. A representação que permite ao engenheiro de software analisar a efectividade do projecto, satisfazer os seus requisitos declarados, considerar alternativas arquitecturais num estado em que fazer modificações de projecto é ainda relativamente fácil e além disso reduzir os riscos associados com a construção do software, faz também parte integral da arquitectura de software que ajuda assim o analista / programador a estruturar as suas ideias. Uma peça de software pode ser dividida em “componentes de software”, que podem ser algo tão simples como módulos do programa, mas também podem tomar formas mais complexas como bases de dados. As propriedades dos componentes são aquelas características necessárias para o entendimento de como os componentes interagem entre si. As propriedades internas como por exemplo o código, não são especificadas. Existe também uma relação entre componentes que pode ser simples ou mais complexa.

Porque é que a arquitectura é importante? A arquitectura é de elevada importância devido a: • • •

Representações de arquitecturas de software constituem um facilitador da comunicação entre todas as partes envolvidas no desenvolvimento de um sistema baseado em computadores; A arquitectura destaca decisões iniciais do projecto que vão ter um impacto profundo em todo o trabalho que se segue e de igual modo no sucesso final do sistema como uma entidade operacional; A arquitectura “constitui um modelo relativamente pequeno, intelectualmente legível de como o sistema é estruturado e como os seus componentes trabalham em conjunto”.

4

Estilos arquitecturais Todo o tipo de produto pode ser definido usando vários tipos de padrões/estilos e como tal também uma peça de software pode ser definida usando vários estilos. Cada estilo deve descrever: • Uma categoria de sistemas que abrange; • Um conjunto de componentes que realizam a função que é o requisito do sistema; • Um conjunto de ligações que possibilita a comunicação entre os vários componentes; • Restrições que definem como os componentes podem ser integrados para formar o sistema; • Modelos que permitem ao projectista entender quais as propriedades gerais de cada sistema pela sua análise.

Tipos de arquitectura de software Centrada em dados Um depósito de dados (base de dados) fica no centro dessa arquitectura e os outros componentes que a manipulam (adicionam, retiram, actualizam, …) têm acesso a esse depósito. A seguinte figura ilustra um estilo típico centrado nos dados, diversos software-clientes têm acesso a uma base de dados. Este tipo de arquitectura promove a integração, ou seja, componentes existentes podem ser modificados e novos componentes-clientes podem ser adicionados à arquitectura sem preocupação com os outros clientes, porque estes operam independentemente.

5

Fluxo de dados Esta arquitectura aplica-se quando os dados de entrada devem ser transformados, por meio de uma série de componentes em dados de saída. Na seguinte figura (figura a) é mostrado o padrão de “tubo e filtro”, que têm um conjunto de componentes chamados filtros que estão conectados por tubos que transportam dados de um componente para outro. Os filtros trabalham independentes uns dos outros, espera pela entrada de dados e depois actua como lhe é pedido para transformar a informação. Se o fluxo de dados se degenera numa única linha de transformação, é denominado sequencial por lotes. Como é demonstrado na seguinte figura (figura b). Este padrão recebe os dados e faz a sua transformação ao longo do percurso, todos os dados passam por todos os filtros neste padrão.

Chamada e retorno Este estilo arquitectural permite ao projectista conseguir uma estrutura do programa que é fácil de modificar e ampliar. Existem vários sub-estilos nesta categoria, entre os quais: • “Arquitecturas de programa principal/subprogramas”, esta estrutura clássica de programa decompõe a função numa hierarquia de controlo em que um programa “principal” invoca um certo número de componentes de programa, em que por sua vez invocam outros componentes; • “Arquitectura de chamada de procedimentos remotos”, os componentes de uma arquitectura “de programa principal/subprogramas” são divididos entre os vários computadores de uma rede. 6

Orientadas a objectos Os componentes de um sistema encapsulam os dados e as operações que devem ser aplicadas para manipular dados. A comunicação e a coordenação entre os componentes são conseguidas por meio de passagem de mensagens.

Camadas Esta estrutura está ilustrada na figura seguinte. Um certo número de camadas diferentes são definidas, cada uma realizando operações que se tornam progressivamente mais próximas do conjunto de instruções da máquina (computador). Na camada exterior os componentes operam com interface com o utilizador, na camada mais interna os componentes interagem com o sistema operativo.

7

Analises de alternativas ao projecto arquitectural Para procedermos à análise de alternativas à arquitectura do projecto, podemos seguir duas vias: por um lado, usando uma analise iterativa para avaliar os vários pontos do projecto; por outro lado, podemos usar uma análise pseudo-quantitativa para avaliar a qualidade do projecto. O Instituto de Engenharia de Software (SEI) desenvolveu o ATAM (Architecture tradeoff analysis method, também conhecido por KAZ98) que estabelece alguns pontos para a análise: 1. Reunir cenários – O sistema, sobre a vista do utilizador, é representado através de use-cases. 2. Listar requisitos, restrições e descrição do ambiente – Este tipo de informação, é usado para que se possa garantir que todas as preocupações do cliente foram consideradas. 3. Descrever os padrões/estilos arquitecturais escolhidos – Estes estilos devem ser descritos, usando perspectivas arquitecturais a. Visão de módulo b. Visão de processo c. Visão de fluxo de dado 4. Avaliar os atributos de qualidade isoladamente – Os atributos de qualidade devem de ser avaliados segundo a relevância que têm para o sistema. Tais, podem ser confiabilidade, desempenho, segurança, manutenibilidade, flexibilidade, testabilidade, portabilidade, reusabilidade e interoperabilidade. 5. Identificar a susceptibilidade de atributos de qualidade aos diversos atributos arquitecturais. – Útil, para descobrir pontos sensíveis no arquitectura, fazendo para isso, pequenas modificações na arquitectura, determinado quão sensível é um dado atributo. 6. Criticar arquitecturas candidatas – Uma vez determinados os pontos sensíveis arquitecturais, deve-se identificar os elementos para os quais múltiplos atributos são susceptíveis. Por exemplo, uma arquitectura cliente-servidor, pode ser muito dependente do número de servidores. O desempenho pode melhorar com o aumento do número de servidores, mas a segurança pode piorar, uma vez que passam a existir mais pontos de ataque. Através deste método, podemos eliminar algumas arquitecturas que poderiam ser alternativas, assim como se pode alterar e representar as restantes com mais detalhe, aplicando-se outra vez os passos ATAM. Embora este método nos ajude muito na análise do projecto, trata-se dum método qualitativo, o que não nos permite uma análise quantitativa. Para isto, podemos usar algumas técnicas (conhecidas por ASA96) que podem complementar a abordagem ATAM. Estas técnicas ajudam o projectista a determinar se determinada arquitectura satisfaz determinados critérios previamente definidos, tais como a segurança, o desempenho, a flexibilidade, entre outros. Numa primeira fase, procede-se ao lançamento de dois casos para o projecto: o melhor e o pior caso (sendo que este deve poder ser aplicado ao problema, ainda que não seja a solução adequada), aos quais são atribuídas as notas máximas e mínimas (Sb e Sw respectivamente). De seguida, procede-se á soma das notas atribuídas a cada atributo do projecto proposto, ao qual se designa por S.

8

É então calculado o grau (Is) em que uma arquitectura se encontra próxima de um sistema óptimo, dentro dos limites propostos por Sw e Sb: Is=[(S-Sw)/(Sb-Sw)]*100 Se mais tarde forem feitas modificações ao projecto, uma forma de comparar se este foi melhorado ou não é comparar o resultado das suas análises através de um índice de melhoria (Imp): Imp=Is2-Is1 No caso deste ser positivo, significa que o sistema 2 foi melhorado em relação ao sistema 1. Procedemos então à análise de selecção de projecto. Esta permite-nos avaliar até que ponto o número de critérios alcançados pelo nosso projecto (Ns) se aproximam do número de critérios propostos pelo projecto ideal (Na). Este índice de selecção (D), pode ser calculado da seguinte forma: D=(Ns/Na)*100 Por fim, procedemos a uma analise de contribuição, na qual podemos identificar a razão de certo conjunto de opções ter uma nota mais baixa do que outro. Usando o QFD (Quality Function Deployment) é conduzido uma analise para determinar a prioridade relativa dos requisitos determinados á quando a descoberta de funções, informações e tarefas. É então identificado um conjunto de características arquitecturais, o qual é listado juntamente com os requisitos do cliente numa matriz de referências cruzadas. Cada célula da matriz representa a força da relação, numa escala de 1 a 10. A isto, também se pode designar de QDS (Quantified Design Space), que é fácil de ser implementado e pode ser usado para isolar e descobrir o porque de um conjunto de opções de projecto obter menor nota do que outro. Também podemos proceder à avaliação da complexidade global da arquitectura, usando uma técnica designada por ZHA98. Esta, sugere 3 tipos de dependências entre os componentes dentro da arquitectura: Dependências de compartilhamento – representam as relações de dependência entre consumidores que utilizam o mesmo recurso. Para dois componentes U e V, se U e V referirem-se aos mesmos dados globais, então existe uma relação de dependência deste tipo. Dependências de fluxo – representam as relações de dependência entre produtores e consumidores de recursos. Para dois componentes U e V, se U tiver que ser completado para que se possa executar V ou se U utilizar V parâmetros, então existe uma relação de dependência de fluxo. Dependências de restrição – representam as restrições no fluxo relativo de controle, entre um dado conjunto de actividades. Para dois componentes U e V, se U e V não poderem ser executados ao mesmo tempo (exclusão mutua) então existe uma relação deste tipo.

9

Resumo A arquitectura de software fornece uma visão abstracta do sistema a ser construído mostrando a estrutura organizacional dos componentes, as propriedades vitais e as conexões entre estes componentes, representando essencialmente os fluxos de dados existentes ao longo da execução da aplicação. Esta arquitectura torna-se assim num conjunto de métodos que visam a estruturação da aplicação para que dessa forma sejam pensados os detalhes essenciais desta, os seus blocos e fluxos de transferência de maneira a que todas as dúvidas deste estejam previamente esclarecidas, antes que se torne demasiado tarde e que se torne dispendiosa a sua alteração. Da mesma forma que visa prever problemas futuros problemas, é também um modo de se desenhar possíveis formas que o projecto poderá levar e dessa forma escolher a melhor e mais económica. Existem vários estilos arquitecturais que poderão ser utilizados conforme as necessidades da especificação do projecto. O modelo orientado a objectos por exemplo, será melhor aplicado numa aplicação que implemente este tipo de sistema no seu núcleo principal, enquanto que o modelo centrado em dados é óptimo para descrever sistemas com vários módulos que acedem a uma base de dados e fazem cada qual uma determinada tarefa.

Bibliografia Pressman R., Engenharia de Software, 5ª edição, MCGraw-Hill http://www.sei.cmu.edu/ata/ata_init.html

10