Engenharia de Software. Projeto de Arquitetura

Transcrição

1 Engenharia de Software Projeto de Arquitetura

2 O que já vimos? Introdução a Engenharia de Software Processos de Software Desenvolvimento Ágil de Software Engenharia de Requisitos Modelagem de sistemas (outra disciplina) Projeto de Arquitetura

3 Modelagem de sistemas (relembrando) É o processo de desenvolvimento de modelos abstratos de um sistema, em que cada modelo apresenta uma visão ou perspectiva diferente do sistema. Os modelos são usados durante o processo de engenharia de requisitos para ajudar a extrair os requisitos do sistema; durante o processo de projeto, são usados para descrever o sistema para os engenheiros que o implementam; e, após isso, são usados para documentar a estrutura e a operação dos sistema.

4 O projeto de arquitetura é o elo crítico entre o projeto e a engenharia de requisitos...

5 O que significa projetar a arquitetura? Está preocupado com a compreensão de como um sistema deve ser organizado e com a estrutura geral desse sistema. O resultado do processo de projeto de arquitetura é um modelo de arquitetura que descreve como o sistema está organizado em um conjunto de componentes de comunicação.

6 E em processos ágeis? Geralmente, se aceita que um estágio inicial do processo de desenvolvimento se preocupe com o estabelecimento de uma arquitetura global do sistema. Refatoração é cara!

7 Níveis de abstração Você pode projetar a arquitetura de um sistema em dois níveis de abstração: Arquitetura em pequena escala Arquitetura em grande escala

8 Arquitetura em pequena escala Está preocupada com a arquitetura de programas individuais. Nesse nível estamos preocupados com a maneira como um programa individual é decomposto em componentes.

9 Arquitetura em grande escala Preocupa-se com a arquitetura de sistemas corporativos complexos que incluem outros sistemas, programas e componentes de programas. Esses sistemas estão distribuídos por diversos computadores, que podem pertencer por e ser geridos por diferentes empresas.

10 Por que é importante projetar a arquitetura de um sistema? É importante pois afeta o desempenho e a robustez, bem como a capacidade de distribuição e manutenibilidade de um sistema. Construir uma casa sem a planta Ilusão de simplicidade

11 A relação entre o projeto de arquitetura e a engenharia de requisitos Os requisitos não funcionais dependem da arquitetura do sistema a forma como esses componentes são organizados e como se comunicam. Em muitos sistemas, os requisitos não funcionais são também influenciados por componentes individuais, mas não há dúvida de que a arquitetura de sistema é a influência dominante. Na prática, existe uma considerável sobreposição entre os processos de engenharia de requisitos e de projeto de arquitetura. A decomposição da arquitetura é normalmente necessária para estruturar e organizar a especificação. Portanto, como parte do processo de engenharia de requisitos pode-se propor uma arquitetura abstrata do sistema.

12 Vantagens Comunicação de stakeholders Pode ser usada como um foco de discussão por uma série de diferentes stakeholders. Análise de sistemas Tornar explícita a arquitetura do sistema, em um estágio inicial de desenvolvimento, requer alguma análise. As decisões de projeto de arquitetura têm um efeito profundo sobre a possibilidade de o sistema atender ou não os requisitos críticos como desempenho, confiabilidade e manutenibilidade. Reúso em larga escala Um modelo de projeto de arquitetura de sistema é uma descrição compacta e gerenciável de como um sistema é organizado e como os componentes interoperam. Geralmente, a arquitetura é a mesma para sistemas com requisitos semelhantes.

13 Como modelar a arquitetura? Em geral, as arquiteturas de um sistema são modeladas por meio de diagrama de blocos simples. Cada caixa representa um componente. Caixas dentro de caixas indicam que o componente foi decomposto em subcomponentes. As setas significam que os dados e/ou sinais de controle são passados de um componente a outro na direção das setas.

14 Diagrama de blocos simples Apresenta uma imagem de alto nível da estrutura do sistema, de forma que as pessoas de diferentes disciplinas, envolvidas no processo de desenvolvimento do sistema, possam compreender facilmente.

15 Modelo abstrato de um sistema de controle robotizado de empacotamento

16 Uso de um modelo de arquitetura Duas maneiras de usar um modelo de arquitetura: Para facilitar a discussão sobre o projeto do sistema; e Como forma de documentar uma arquitetura que foi projetada.

17 Decisões de projeto de arquitetura O projeto de arquitetura é um processo criativo no qual você projeta uma organização de sistema para satisfazer os requisitos funcionais e não funcionais de um sistema. Durante o processo de projeto de arquitetura, os arquitetos de sistema precisam tomar uma série de decisões estruturais que afetam profundamente o sistema e seu processo de desenvolvimento.

18 Questões fundamentais sobre o sistema Existe uma arquitetura genérica de aplicação que pode atuar como um modelo para o sistema que está sendo projetado? Como o sistema será distribuído por meio de um número de núcleos ou processadores? Que padrões ou estilos de arquitetura podem ser usados? Qual será a abordagem fundamental para se estruturar o sistema? Como os componentes estruturais do sistema são decompostos em subcomponentes?

19 Questões fundamentais sobre o sistema (2) Que estratégia será usada para controlar o funcionamento dos componentes do sistema? Qual a melhor organização de arquitetura para satisfazer os requisitos não funcionais do sistema? Como o projeto de arquitetura será avaliado? Como a arquitetura do sistema deve ser documentada?

20 Devido a estreita relação entre os requisitos não funcionais e a arquitetura do software, o estilo e a estrutura da arquitetura particular que você escolhe para um sistema devem depender dos requisitos não funcionais do sistema...

21 Desempenho Se o desempenho for um requisito crítico, a arquitetura deve ser projetada para localizar as operações críticas dentre os componentes, com todos os componentes implantados no mesmo computador, em vez de distribuídos pela rede. Isso pode significar o uso de alguns componentes relativamente grandes, em vez de pequenos de baixa granularidade, que reduzem o número de comunicações entre eles.

22 Proteção Se a proteção for um requisito crítico, deve ser usada uma estrutura em camadas para a arquitetura, com os ativos mais críticos protegidos em camadas mais internas, com alto nível de validação de proteção aplicado a essas camadas.

23 Segurança Se a segurança for um requisito crítico, a arquitetura deve ser concebida de modo que as operações relacionadas com a segurança estejam localizadas em um único componente ou em um pequeno número de componentes. Isso reduz os custos e os problemas de validação de segurança e torna possível fornecer sistemas de proteção relacionados que podem desligar o sistema de maneira segura em caso de falha.

24 Disponibilidade Se a disponibilidade é um requisito crítico, a arquitetura deve ser projetada para incluir componentes redundantes, de modo que seja possível substituir e atualizar componentes sem parar o sistema.

25 Manutenção Se a manutenção é um requisito crítico, a arquitetura do sistema deve ser projetada a partir de componentes autocontidos de baixa granularidade que podem ser rapidamente alterados. Os produtores de dados devem ser separados dos consumidores, e as estruturas de dados compartilhados devem ser evitadas.

26 Obviamente, há um conflito potencial entre algumas dessas arquiteturas...

27 Visões de arquitetura Que visões ou perspectivas são úteis ao se projetar e documentar uma arquitetura de sistema? Quais notações devem ser usadas para se descrever modelos de arquitetura?

28 É impossível representar todas as informações relevantes sobre a arquitetura de um sistema em um único modelo de arquitetura, pois cada modelo mostra apenas uma visão ou perspectiva do sistema. Tudo isso é útil em momentos diferentes; por isso, para ambos, projeto e documentação, geralmente você precisa apresentar múltiplas visões da arquitetura de software

29 Modelo de visão 4+1 de arquitetura de software (Kruchten, 1995) Visão Lógica: mostra as abstrações fundamentais do sistema como objetos ou classes de objetos. Nessa visão, deveria ser possível relacionar os requisitos de sistema com as entidades. Visão de Processo: mostra como, no tempo de execução, o sistema é composto de processos interativos. É útil para fazer julgamentos sobre as características não funcionais do sistema.

30 Modelo de visão 4+1 (continuação...) Visão de Desenvolvimento: mostra como o software é decomposto para o desenvolvimento, ou seja, apresenta a distribuição do software em componentes que são implementados por um único desenvolvedor ou por uma equipe de desenvolvimento. É útil para gerentes de software e programadores. Visão Física: mostra o hardware do sistema e como os componentes de software são distribuídos entre os processadores. É útil para os engenheiros que estão planejando uma implantação do sistema.

31 Hofmeister et al. (2000) Sugere o uso de visões de arquitetura semelhantes, mas acrescentam a noção de uma visão conceitual. Essa é uma visão abstrata do sistema que pode ser a base para a decomposição de requisitos de alto nível em especificações detalhadas. Na prática, as visões conceituais são, quase sempre, desenvolvidas durante o processo de projeto e são usadas para apoiar a tomada de decisões de arquitetura. Elas são uma maneira de comunicar a essência de um sistema para os diferentes stakeholders.

32 A respeito do uso da UML para descrições de arquitetura...

33

34

35

36 Padrões de arquitetura A ideia de padrões como uma forma de apresentar, compartilhar e reusar o conhecimento sobre sistemas de software é hoje amplamente usada. Você pode pensar em padrões como uma descrição abstrata, estilizada, de boas práticas experimentadas e testadas em diferentes sistemas e ambientes.

37 Padrões de arquitetura (2) Padrão MVC (Model-View-Control) Arquitetura em camadas Arquitetura de repositório Arquitetura cliente-servidor

38 Padrão MVC (modelo-visão-controlador, do inglês, model-view-controller) Esse padrão separa os elementos do sistema, permitindo mudá-los de forma independente.

39 Nome Descrição Quando é usado Vantagens MVC Separa a apresentação e a interação dos dados do sistema. Sistema é estruturado em três componentes lógicos que interagem entre si. Model (modelo) gerencia o sistema de dados e operações associadas a esses dados. View (visão) gerencia como os dados serão apresentados ao usuário. Controller (controlador) gerencia a interação do usuário, e passa essas interações para a visão e o modelo. Usado quando existem diferentes maneiras de se visualizar e interagir com os dados. Permite que os dados sejam alterados de forma independente de sua representação, e vice-versa. Apoia apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação aparecendo em todas elas. Desvantagem Quando o modelo de dados e as interações são simples, pode envolver código adicional e complexidade ao código.

40

41

42 Arquitetura em camadas As noções de separação e independência são fundamentais para o projeto de arquitetura, pois permitem que alterações sejam localizadas. Cada funcionalidade do sistema é organizada em camadas, e cada camada depende de recursos e serviços oferecidos pela camada imediatamente abaixo dela. Vantagens: desde que a interface seja mantida, permite a substituição de camadas inteiras. Desvantagens: na prática, é difícil proporcionar uma clara separação entre as camadas. Desempenho pode ser problema por causa dos múltiplos níveis de interpretação de uma solicitação de serviço, uma vez que são processados em cada camadas.

43 Arquitetura genérica em camadas

44 Arquitetura de repositório Descreve como um conjunto de componentes que interagem podem compartilham dados. A maioria dos sistemas que usam grandes quantidades de dados é organizada em torno de um banco de dados ou repositório compartilhado. Esse modelo é, portanto, adequado para aplicações nas quais os dados são gerados por um componente e usados por outro.

45 Nome Descrição Repositório Todos os dados em um sistema são gerenciados em um repositório central, acessível a todos os componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório. Quando é usado Usado quando existe um grande volume de informações gerados e precisam ser armazenados por um longo tempo. Vantagens Os componentes podem ser independentes não precisam saber da existência do outro. As alterações feitas a um componente podem propagar-se para todos os outros. Todos os dados podem ser gerenciados de forma consistente. Desvantagem O repositório é ponto único de falha, assim, problemas no repositório podem afetar todo sistema. Pode haver ineficiência na organização de toda a comunicação através do repositório.

46

47 Arquitetura cliente-servidor Muito usada em sistemas distribuídos. Um sistema que segue o padrão cliente-servidor é organizado como um conjunto de serviços e servidores associados, e clientes que acessam e usam os serviços. Um conjunto de servidores que oferecem serviços a outros componentes; Um conjunto de clientes que podem chamar os serviços oferecidos pelos servidores; Uma rede que permite aos clientes acessar esses serviços.

48 Nome Descrição Quando é usado Vantagens Desvantagem Cliente-Servidor A funcionalidade do sistema está organizada em serviços cada serviço é prestado por um servidor. Os cliente são os usuários desses serviços e acessam os servidores para fazer uso deles. É usado quando os dados em um banco de dados compartilhado precisam ser acessados a partir de uma série de locais. A principal vantagem desse modelo é que os servidores podem ser distribuídos através de uma rede. A funcionalidade geral pode estar disponível para todos os clientes e não precisa ser implementada por todos os serviços. Cada serviço é ponto único de falha suscetível a ataques de negação de serviço ou de falha no servidor. O desempenho, bem como o sistema, pode ser imprevisível, pois depende da rede.

49