Arquitetura de Software: Atributos para decisões do projeto arquitetural

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Este artigo apresenta um conjunto de informações que podem subsidiar decisões de projeto arquitetural de sistemas de software.

Esse artigo faz parte da revista Engenharia de Software 22 edição especial. Clique aqui para ler todos os artigos desta edição



Projeto

Arquitetura de Software

Atributos para decisões do projeto arquitetural

 

De que trata o artigo:

Apresenta um conjunto de informações que podem subsidiar decisões de projeto arquitetural de sistemas de software.

Para que serve:

Entender o papel do projeto arquitetural dentro do processo de desenvolvimento de software orientado para arquitetura e identificação de informações necessárias às decisões de projeto.

Em que situação o tema é útil:

Identificação de informações e critérios que apóiam as atividades de análise e projeto de arquitetura de software.

 

Software é uma entidade que se encontra quase permanentemente sendo modificado. Tais mudanças ocorrem devido à necessidade de corrigir erros existentes no software ou de adicionar novos recursos e funcionalidades. Igualmente, os sistemas computacionais (isto é, aqueles que têm software como um de seus elementos) também estão sujeito a mudanças frequentes. Isso pode motivar um sistema de software a se tornar ‘não confiável’ e predisposto a defeitos, bem como ocasionar atraso na entrega e elevação de custos acima do estimado. Concomitante com esses fatos, o crescimento em tamanho e complexidade dos sistemas de software exige que os profissionais da área raciocinem, projetem, codifiquem e se comuniquem por meio de componentes de software. Como resultado, qualquer projeto ou solução de sistema requer decisões arquiteturais (de projeto) que podem impactar o produto final.  A necessidade da arquitetura de software prover suporte a um conjunto de requisitos, geralmente conflitantes, exige que decisões arquiteturais sejam tomadas ainda durante o projeto, tema esse tratado neste artigo.

Projeto da Arquitetura de Software

Um projetista desenvolve um projeto considerando um conjunto de decisões de projeto. Para tomar decisões, ele leva em conta os requisitos arquiteturais que motivam e justificam suas decisões. Por trás disto, também estão metas de qualidade desejadas para o sistema a ser desenvolvido, bem como cenários de uso, estilos arquiteturais existentes e padrões de projeto. A Figura 1 ilustra essa visão do projeto arquitetural.

 

 

Figura 1. Elementos de decisão do projeto arquitetural.

 

Perceba que o projeto arquitetural é uma fase iterativa do processo de desenvolvimento de sistema software sobre a qual o projetista ou arquiteto de software precisa raciocinar a fim de tomar decisões, levando em consideração os requisitos arquiteturais e cenários de uso, por exemplo. O arquiteto pode ainda fazer uso de técnicas de análise arquitetural para apoiar seu raciocínio sobre o comportamento de atributos de qualidade. Tais técnicas podem acrescentar informações aos estilos arquiteturais de modo a possibilitar o raciocínio qualitativo e quantitativo.

Perceba que há uma interação entre as fases de análise e projeto de arquitetura de software. Tal interação surge da necessidade de refinar os requisitos arquiteturais elicitados na fase anterior do processo de desenvolvimento orientado para arquitetura, como ilustrado na Figura 2.

 

 

 

Figura 2. Desenvolvimento orientado para arquitetura de software.

 

A interação existente entre as fases de projeto e análise arquitetural permite o refinamento da documentação da arquitetura do sistema que culminará com sua implementação. É importante observar ainda que, durante a implementação, pode haver necessidade de reconsiderar decisões de projeto tomadas anteriormente.

Uma vez que a arquitetura de software tenha sido obtida, essa pode evoluir e, portanto, requer que novos requisitos arquiteturais sejam elicitados a fim de satisfazer às mudanças desejadas. Deste modo, características são adicionadas e/ou modificadas.

 

Dimensões e Regras de Projeto

Projetos inovadores são, geralmente, desenvolvidos para resolver novos tipos de problemas ou até mesmo prover solução a algum problema com requisitos bem específicos. Entretanto, os custos associados podem ser elevados. Nesse sentido, a comunidade de engenharia de software e, mais especificamente, de arquitetura de software, tem procurado organizar o conhecimento de projeto de sistemas de software. Uma forma de fazer isto é desenvolvendo um vocabulário, englobando conceitos e padrões de projetos que possam ser facilmente compreendidos e reutilizáveis. Como resultado deste esforço, tem-se:

1.    A possibilidade de desenvolver um projeto de sistema a partir de blocos estruturais.

2.    Entendimento e antecipação das propriedades de um projeto.

3.    Redução do esforço necessário para compreender o projeto de outra pessoa.

 

Um exemplo de organização de conhecimento através de um vocabulário é a codificação de estruturas de controle do fluxo de instruções em um algoritmo, onde dispomos de estruturas sequenciais, de decisão e repetição. Isto oferece um entendimento sobre os padrões de fluxo de controle no qual é feito uso desses blocos estruturais. Uma forma de organizar o conhecimento a ser utilizado no projeto arquitetural é obtendo um conjunto de soluções de projeto em termos de dimensões de projeto. Cada dimensão nesse conjunto solução descreve uma característica do sistema ou decisão de projeto.

Considere, por exemplo, que o tempo de resposta de um sistema seja uma dimensão no conjunto solução. Similarmente, o mecanismo de sincronização entre processos também pode ser visto como outra dimensão. A Figura 3 ilustra essas duas dimensões envolvendo dois sistemas exemplo quaisquer. A figura sugere que o mecanismo de mensagens oferece um tempo de resposta melhor quando comparado a semáforos.

 

Figura 3. Exemplo simples de conjunto solução de projeto.

 

A existência de diferentes dimensões não implica que elas sejam independentes. Na realidade, é de suma importância identificar correlações entre as dimensões. Como resultado, isto permite a criação de regras de projeto que especificam quão adequada é a combinação de opções. Uma forma empírica de determinar a existência de correlações é checando se há agrupamento de soluções de projeto em uma região do conjunto solução e sua ausência é verificada em outras regiões."

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?