<< Chapter < Page Chapter >> Page >

Na prática, é importante observarmos que a divisão entre decisõesestruturais e comportamentais não é absoluta. Podemos encontrar decisõesque, para descrever um comportamento, necessitem de novas estruturas arquiteturais.Assim, por conveniência, é melhor descrever estas novas estruturas na própria decisãocomportamental do que documentar uma nova decisão estrutural. Podemos observareste caso no exemplo anterior, onde descrevemos as partições do conjuntode dados para então descrever o comportamento de particionamento dos dados e assimconseguir algum nível de escalabilidade horizontal.

Por outro lado, há decisões que proíbem a existência deelementos arquiteturais. Essas decisões são chamadas de decisões não-existenciaise elas servem para restringir as alternativas de design de baixo nível. Alguns padrõesarquiteturais, como o 3- tier ou mesmo o padrão Camadas, proíbem a comunicação entre alguns dos elementosque eles descrevem, constituindo decisões não-existenciais.

Decisões de propriedades

Decisões de propriedades não determinam a existência de partesdo software, mas apresentam alguma qualidade ou característica que umaou mais partes devem exibir. O papel deste tipo de decisão é o de guiartanto o design de baixo nível, quanto a implementação, uma vez que descreveos princípios e regras ou restrições de design que devem ser respeitadasao longo do desenvolvimento.

Os exemplos mais comuns de decisões de propriedades são asdecisões sobre preocupações transversais ao software, como por exemplo, decisõesde logging , decisões de tolerância a faltas oumesmo decisões sobre a precisão na obtenção dos resultados. Podemos observaruma ilustração mais completa deste tipo de decisão nos exemplos a seguir( [link] e [link] ). Note que, em ambos os exemplos, as decisõesnão descrevem a existência de elementos que devem estar na arquitetura, masdescrevem as propriedades de elementos arquiteturais que foram descritos emoutras decisões.

[Decisão Arquitetural 008]Os métodos públicos de cada serviço que implementaos módulos descritos na [DecisãoArquitetural 001] devem seguiras seguintes regras de logging :

  • Deve-se registrar todos os parâmetros das chamadasem nível de DEBUG . Este modo deve poder ser ligadoou desligado em tempo de execução.
  • Todas as exceções lançadas devem ser logadasem nível de ERROR e registrar os parâmetros usados durante a execução.
  • Os tempos de execução de cada chamadaao método devem ser registrados, para possibilitar a monitoraçãode desempenho do sistema. O canal de logging utilizado neste caso deve ser especializado para coleta demétricas de desempenho.

Objetivo : Estas regras facilitam a operabilidadedo sistema.

Motivação : O registro dos acontecimentos inesperadosno sistema facilita o diagnóstico dos problemas e a possibilidadede aumentar o nível de detalhe dos registros em tempo de execuçãopermite que esse diagnóstico seja mais rápido. Por outro lado, oregistro de métricas de desempenho do sistema permite análise de capacidade,podendo indicar se o sistema está precisando de mais recursos computacionais.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Arquitetura de software. OpenStax CNX. Jan 05, 2010 Download for free at http://cnx.org/content/col10722/1.9
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?

Ask