<< 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 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 :
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.
Notification Switch
Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?