Arquitetura de Software

Guilherme Mauro Germoglio Barbosa
Arquitetura de Software
Ad innitum
Universidade Federal de Campina Grande
A todos que ajudaram, obrigado.
Contedo
1 2
Mensagens do Livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduo ao Design de Software . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Design de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 O que Design de Software . . . . . . . . . . . . . . . . . . . . . . . . .
1 7 8 9
2.1.2 Caractersticas de Design de Software . . . . . . . . . . . . . . . . 10 2.2 Elementos do processo de design de software . . . . . . . . . . . . . . . . 13 2.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Restries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.4 Representaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.5 Solues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3 Nveis de design de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Princpios e tcnicas de design de software . . . . . . . . . . . . . . . . . . 23 2.4.1 Diviso e Conquista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.2 Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.3 Encapsulamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.4 Modularizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.5 Separao de preocupaes . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.6 Acoplamento e coeso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.7 Separao de Decises de Execuo de Algoritmos . . . . . 27 2.4.8 Separao de Interfaces de suas Implementaes . . . . . . . 27 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
VIII
Contedo
Estudo de Caso: SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1 Apresentao do estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Funcionalidades do SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Locao e Streaming de vdeo . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.2 Busca, feedback e sugestes ao usurio . . . . . . . . . . . . . . . 35 3.2.3 Disponibilizao de lmes e administrao do sistema . . 35 3.3 Capacidades do SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.1 Nmeros de usurios e aspectos de segurana . . . . . . . . . 37 3.3.2 Tamanho do inventrio e nmero de operaes por dia . 37 3.3.3 Transmisses simultneas . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.4 Adio de informaes sobre os vdeos . . . . . . . . . . . . . . . 38 3.3.5 Tempos de resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Fundamentos de Arquitetura de Software . . . . . . . . . . . . . . . . . . 41 4.1 Motivao para desenvolver melhores sistemas . . . . . . . . . . . . . . . 41 4.2 O que Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Denio de Arquitetura de Software por Perry e Wolf . . . . . . . 43 4.4 Arquitetura de Software por Garlan e Shaw . . . . . . . . . . . . . . . . . 45 4.5 Arquitetura de Software por Bass et al . . . . . . . . . . . . . . . . . . . . . 47 4.6 Arquitetura de Software pelo Padro ISO/IEEE 1471-2000 . . . 50 4.7 Decompondo a denio de Arquitetura de Software . . . . . . . . . 51 4.7.1 Elementos arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7.2 Decises arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.7.3 Atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.8 Vises da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.9 O Documento de Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.9.1 Benefcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.9.2 Diculdades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.10 Por que documentar a arquitetura de software? . . . . . . . . . . . . . . 70 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.1 Quem so os interessados em um sistema de software?. . . . . . . . 78 5.1.1 Importncia dos interessados . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2 Tipos de stakeholders e sua relao com os atributos de qualidade 82 5.2.1 Atendimento aos requisitos como medida de sucesso . . . 83
Contedo
IX
5.2.2 Conitos entre requisitos e atributos de qualidade . . . . . 84 5.2.3 Responsabilidades dos stakeholders . . . . . . . . . . . . . . . . . . 85 5.3 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6 Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.1 Requisitos Funcionais e No-Funcionais . . . . . . . . . . . . . . . . . . . . 92 6.2 Atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2.1 Limites s funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.2.2 Relaes entre atributos de qualidade . . . . . . . . . . . . . . . . 102 6.2.3 A quem interessa os atributos de qualidade . . . . . . . . . . . 103 6.3 Modelo de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.3.1 Padro ISO/IEC 9126-1:2001 . . . . . . . . . . . . . . . . . . . . . . . 103 6.3.2 Conitos entre atributos de qualidade . . . . . . . . . . . . . . . . 115 6.4 Atributos de Negcio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.4.1 Mercado-alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.4.2 Time-to-market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.4.3 Custo e benefcio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.4.4 Vida til . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.4.5 Agenda de lanamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.5 Design Arquitetural para Qualidade de Software . . . . . . . . . . . . . 117 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7 Tcnicas de Design Arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.1 Princpios e Tcnicas de Design Arquitetural . . . . . . . . . . . . . . . . 122 7.1.1 Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.1.2 Separao de preocupaes . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.1.3 Padres e estilos arquiteturais . . . . . . . . . . . . . . . . . . . . . . . 124 7.2 Tticas de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.2.1 Desempenho e escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . 128 7.2.2 Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.2.3 Tolerncia a Faltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.2.4 Compreensibilidade e Modicabilidade . . . . . . . . . . . . . . . 135 7.2.5 Operabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Contedo
Documentao da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 8.1 Arquitetura e Documento da Arquitetura . . . . . . . . . . . . . . . . . . . 142 8.1.1 Auxlio ao Processo de Design . . . . . . . . . . . . . . . . . . . . . . 142 8.1.2 Ferramenta de Comunicao . . . . . . . . . . . . . . . . . . . . . . . . 145 8.1.3 Integridade Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 8.1.4 Modelo para Anlise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.1.5 Ferramenta de Rastreabilidade . . . . . . . . . . . . . . . . . . . . . . 151 8.2 Decises Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.2.1 Decises existenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 8.2.2 Decises descritivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 8.2.3 Decises executivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 8.2.4 Atributos das decises arquiteturais . . . . . . . . . . . . . . . . . 157 8.3 Vises arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 8.3.1 4+1 de Kruchten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 8.3.2 Viewpoints de Rozanski e Woods . . . . . . . . . . . . . . . . . . . . 165 8.3.3 Viewtypes do Software Engineering Institute (SEI) . . . . . 166 8.4 Documentando a Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 8.4.1 Diculdades da Documentao . . . . . . . . . . . . . . . . . . . . . . 167 Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
1 Mensagens do Livro
O contedo deste livro est dividido em seis captulos (alm do estudo de caso) e cada captulo serve para transmitir um conjunto especco de mensagens sobre a disciplina de Arquitetura de Software. Alm de mensagens, h outros dois tipos de elementos que so essenciais para a composio de livro: denies, que descrevem os conceitos fundamentais, e boas prticas, que so recomendaes a serem seguidas pelo leitor ao aplicar o conhecimento presente no livro. As recomendaes tm um papel importante, principalmente, nos estudos de caso, quando o lidamos com os diversos trade-os presentes na prtica de Arquitetura de Software. A seguir, apresentamos os captulos e suas mensagens:
Captulo 2: Introduo a Design de Software

Neste captulo apresentamos design de software e mostramos que ele essencial no processo de desenvolvimento de software independentemente do nvel de detalhe em que ele aplicado. No entanto, o design de alto nvel enfatizado, uma vez que projetar arquitetura fazer design em alto nvel. Mostramos tambm os elementos que compem os problemas de design. As mensagens do captulo so: O design a estrutura ou o comportamento de um sistema que resolve ou contribui para a resoluo das foras que atuam sobre esse sistema; Um design representa apenas um ponto no espao de deciso; Um design pode ser singular, representando apenas uma folha na rvore de decises, ou coletivo, representando um conjunto de decises;
So cinco os elementos que compem os problemas de design: objetivos, restries, alternativas, representaes e solues; Design necessrio em todos os nveis de detalhe durante o processo de desenvolvimento do software.
Captulo 3: Estudo de Caso: SASF

Neste captulo, ilustramos a necessidade de aplicar os conhecimentos de Arquitetura de Software por meio de um problema de design complexo. Nele, apresentamos tanto os requisitos de um sistema web de locao e transmisso de vdeos quanto seus stakeholders. Uma vez que este captulo apenas descreve um caso, no h mensagens explcitas a serem transmitidas.
Captulo 4: Fundamentos de Arquitetura de Software

Este captulo apresenta a denio de Arquitetura de Software usando um padro ISO/IEEE. Como a denio apenas no o bastante para entendermos o porqu de se aplicar os conhecimentos de arquitetura durante o ciclo de desenvolvimento, mostramos seus benefcios explicitamente atravs de exemplos e o estudo de caso. Alm da denio ISO/IEEE, mostraremos outras denies que diversos autores zeram ao longo da histria, uma vez que elas expem caractersticas importantes para o entendimento do assunto. As mensagens deste captulo so: Arquitetura design, mas nem todo design arquitetural. o arquiteto quem dene a fronteira entre o design arquitetural e o no-arquitetural, denindo quais decises sero necessrias para atender aos objetivos de desenvolvimento, de comportamento e de qualidade do sistema; A arquitetura tambm um veculo de comunicao entre stakeholders; A arquitetura contm as decises antecipadas de design, que tm o impacto mais caro (caso seja necessrio mud-las ou caso elas estejam erradas); A arquitetura uma abstrao transfervel do sistema; A arquitetura facilita a construo do sistema; A arquitetura facilita o entendimento do sistema; A arquitetura facilita o reuso durante o ciclo de vida do sistema; A arquitetura facilita a evoluo do sistema;
A arquitetura facilita a anlise do sistema; A arquitetura facilita a gerncia durante o desenvolvimento do sistema; Documentar a arquitetura ajuda no controle intelectual do software; Documentar a arquitetura ajuda a manter a integridade conceitual do sistema; A arquitetura do software restringe o vocabulrio de alternativas de design; Documentar a arquitetura permite a ligao entre os requisitos e as decises de design do software; Documentar a arquitetura tem impacto negativo na impreciso da especicao, que fonte de complexidade do sistema; Documentar a arquitetura ajuda na diviso de tarefas entre os times de desenvolvimento.
Captulo 5: Stakeholders
Os stakeholders tm grande inuncia no design da arquitetura porque so eles que impem os requisitos que o sistema deve atender. Por isso, para entendermos essa inuncia, devemos estud-los. Os stakeholders demonstram essa inuncia porque possuem diversas responsabilidades durante o ciclo de vida do software. Neste captulo apresentamos quem so os stakeholders do software mais comuns e suas caractersticas. As mensagens deste captulo so: Stakeholders inuenciam a arquitetura de diversas maneiras e no necessariamente esto de acordo entre si e por isso que surgem os trade-os durante o design do software; Os seguintes stakeholders devem ser considerados durante o projeto da arquitetura: o prprio arquiteto ou outros futuros arquitetos; os engenheiros de requisitos; os designers; os desenvolvedores; os testadores; os responsveis pela integrao do software com outros sistemas; os mantenedores do software; os designers de outros sistemas; o gerente do desenvolvimento;
o time de controle de qualidade do software. O arquiteto deve ter pleno conhecimento de todo o ciclo de vida do software, para ser capaz de lidar com os trade-os que surgiro entre os stakeholders; O arquiteto deve entender a relao entre os stakeholders e os atributos de qualidade do software.
Captulo 6: Atributos de Qualidade

Uma vez que os atributos de qualidade do software so proporcionados, principalmente, por sua arquitetura e por meio dos atributos de qualidade que o software atende aos requisitos no-funcionais, devemos estudar esses atributos. Este captulo trata tanto dos requisitos no-funcionais quanto dos atributos de qualidade, enfatizando suas relaes e ferramentas de design teis para o alcance dos atributos. Usamos o modelo ISO/IEC 9126-1:2001 mas no nos restringimos a ele para denir a qualidade de software e os atributos que ele deve exibir para tanto. As mensagens deste captulo so: A arquitetura se preocupa principalmente com os requisitos no-funcionais, no apenas tcnicos, mas tambm relacionados a negcio; No existe a arquitetura correta. Existem arquiteturas que so mais ou menos adequadas aos requisitos; A arquitetura permite uma forma de rastreamento entre a implementao do software e seus requisitos; A arquitetura de software afeta diversos atributos de qualidade, entre eles: Funcionalidade Conabilidade Usabilidade Ecincia Manutenibilidade Portabilidade
Captulo 7: Tcnicas de Design Arquitetural

Ao introduzirmos design de software, citamos alguns princpios e tcnicas que so fundamentais ao processo, pois facilitam a representao e a escolha da
soluo entre as alternativas de design. No entanto, no fomos explcitos sobre como estes princpios e tcnicas so fundamentais ao processo de design arquitetural. J no captulo sobre atributos de qualidade, mencionamos a existncia de tticas arquiteturais que ajudam na implementao de alguns requisitos de qualidade, mas no apresentamos essas tticas a no ser de forma breve e apenas por meio de exemplos. Este captulo, por sua vez, tem como objetivo tanto apresentar os princpios de design em nvel arquitetural, quanto apresentar algumas tticas arquiteturais que implementam requisitos de qualidade. Neste captulo, descrevemos os seguintes princpios de design arquitetural: uso da abstrao ou nveis de complexidade; separao de preocupaes; uso padres e estilos arquiteturais. Alm disso, apresentamos diversas tticas arquiteturais para alcanarmos os seguintes atributos de qualidade: desempenho e escalabilidade; segurana; tolerncia a faltas; compreensibilidade e modicabilidade; operabilidade.
Captulo 8: Documentao da Arquitetura

Depois de entender os conceitos, a importncia e ter noes de design de arquitetura, o leitor precisar saber como capturar a informao arquitetural e document-la. Conceitos de vises arquiteturais so introduzidos para facilitar a documentao das diferentes dimenses que uma arquitetura apresenta. Este captulo pretende ser agnstico a linguagens ou modelos de documentao de arquitetura, mas apresenta um exemplo de como faz-lo. As mensagens deste captulo so: Toda informao presente numa arquitetura uma deciso arquitetural. Decises arquiteturais podem ser existenciais, descritivas ou executivas.
Decises arquiteturais se relacionam, podendo restringir, impedir, facilitar, compor, conitar, ignorar, depender ou ser alternativa a outras decises arquiteturais.
Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto. Por isso, a necessidade de mltiplas vises da arquitetura.
2 Introduo ao Design de Software
Antes de comearmos o estudo e a prtica na disciplina de Arquitetura de Software, apropriado sabermos onde ela se encaixa ao longo do Corpo de Conhecimento em Engenharia de Software (Software Engineering Body of Knowledge ). Design arquitetural, ou projeto da arquitetura, a primeira das duas atividades que compem a rea de conhecimento de Design de Software (Software Design Knowledge Area ). A atividade seguinte design detalhado. Por ser uma atividade de Design, o design arquitetural se faz por uma mistura de conhecimento e criatividade. Como criatividade algo que se obtm atravs da experincia, no nosso objetivo ensin-la. No entanto, buscamos ao longo desse livro transmitir o conhecimento necessrio para a criao de arquiteturas de sistemas de software. Certamente, uma base conceitual em Design de Software necessria para uma melhor compreenso desse livro. Dessa maneira, este captulo procura fundamentar o conhecimento do leitor nessa rea, de forma que sua importncia e seus benefcios proporcionados sejam reconhecidos. Em outras palavras, esse captulo far com que o leitor seja capaz de: Reconhecer os conceitos bsicos de design de software Descrever problemas de design atravs de seus elementos fundamentais Identicar princpios de design de software e explicar seus benefcios Diferenciar design de baixo-nvel (detalhado) de design de alto-nvel (arquitetural) e saber quando aplicar cada um
2.1 Design de Software

A relevncia de se projetar ou fazer design de software pode ser explicada pela complexidade crescente dos sistemas de software. Devido a essa complexidade, o risco de se construir um sistema que no alcance seus objetivos eminente. Para evitar tal risco, a prtica comum de qualquer engenharia para se construir um artefato complexo, um sistema de software complexo em nosso caso, constru-lo de acordo com um plano. Em outras palavras, projetar o sistema antes de constru-lo. O resultado dessa atividade, tambm conhecida como de atividade de design, tambm chamado de design. O design facilita duas atividades que so essenciais no ciclo de vida de um sistema de software. Primeiro, ele possibilita a avaliao do sistema contra seus objetivos antes mesmo dele ser construdo. Dessa maneira, ele aumenta a conana de que o sistema construdo, se de acordo com o design, alcanar seus objetivos. Obviamente, uma vez que nesse ponto h apenas o modelo do sistema o design , a avaliao no ser completa, mas isso tambm no quer dizer que ela no oferea resultados importantes que levem ao sucesso do sistema. J a outra atividade beneciada pelo design a prpria construo do sistema, dado que ele tambm serve como guia para a implementao do software. A seguir, mostramos um exemplo de quando o design permite a avaliao do software. O Exemplo 2.1 mostra parte da primeira verso do design de um sistema distribudo de armazenamento, o HBase 1 e, atravs de uma breve avaliao desse design, observamos uma grave limitao do software. Exemplo 2.1. O HBase um sistema de armazenamento distribudo. Isso quer dizer que os dados submetidos a ele no sero guardados em um nico servidor, mas em vrios. De forma simplicada, o design do HBase dene dois tipos de entidades no sistema: o data node, que o subsistema que armazena os dados, e o master node, que o subsistema que sabe em quais data nodes os dados foram escritos e podem ser recuperados. Na primeira verso do HBase, s existia um master node que coordenava todos os data nodes. Assim, para recuperar ou escrever dados no HBase, um cliente realizava os seguintes passos: primeiro, o cliente se comunicava com o master node a m de conseguir, de acordo com uma chave2, o endereo do data node em que ele pode realizar
1 2
Apache HBase : http://hbase.org Os dados so inseridos no HBase na forma (chave,valor).
a operao desejada (leitura ou escrita). Em seguida, o master node, que coordena onde os dados devem car, retorna o endereo do data node que deveria possuir dados para referida chave. A partir da, o cliente, j com o endereo, se comunicava diretamente com o data node e realizava a operao desejada (escrita ou leitura). Se avaliarmos este design, podemos perceber duas caractersticas do HBase. A primeira, que ele no adota o uso de um cliente magro (thin client ). Com isso, a implementao e congurao do cliente se torna mais complexa, uma vez que o cliente precisa conhecer o protocolo de escrita e leitura do HBase, alm de precisar acessar tanto o master node quanto os data nodes. Isto diculta o desenvolvimento, a operabilidade e a eventual evoluo do software, uma vez que mudanas no protocolo afetam clientes e servidores. Alm disso, por possuir apenas um master node, a funcionalidade do HBase ca condicionada sua disponibilidade. Anal, se o master node estiver inacessvel, nenhum cliente poder ler ou escrever no sistema, o que o torna um ponto nico de falhas. 2.1.1 O que Design de Software Para denir design de software, alguns autores o fazem em dois sentidos distintos: quando design de software usado como produto e quando usado como processo. Quando usado no primeiro sentido, o termo design de software indica o produto que emerge do ato (ou processo) de projetar um sistema de software e sendo assim algum documento ou outro tipo de representao do desejo do projetista (ou designer). Esse produto o resultado das decises do designer para formar uma abstrao do sistema que desejado no mundo real. Existem diversas formas de como representar essa abstrao do sistema. Podemos citar, por exemplo, desenhos usando caixas e setas, textos descritivo, ou ainda uso de linguagens ou ferramentas criadas para este propsito, como linguagens de modelagem de software, redes de petri, pseudocdigo, etc. J quando o termo usado no segundo sentido, fazer design indica o processo seguido para se obter um projeto. Esse um processo que faz parte do processo de desenvolvimento e que orientado aos objetivos do software. Ele deve ser realizado tendo em mente os diversos stakeholders do sistema e deve ser fundamentado no conhecimento do designer sobre o domnio do problema.
10
A partir da viso de design como artefato, podemos observar que ele deve descrever diversos aspectos do software para que, assim, possibilite sua construo. Entre estes aspectos, esto: a estrutura esttica do sistema, incluindo a hierarquia de seus mdulos; a descrio dos dados a serem usados; os algoritmos a serem usados; o empacotamento do sistema, em termos de como os mdulos esto agrupados em unidades de compilao; e as interaes entre mdulos, incluindo as regras de como elas devem acontecer e porque elas acontecem.
Podemos perceber que, apesar dos exemplos anteriores descreverem apenas parte do design de dois sistemas, eles mostram boa parte dos aspectos que esperamos no design de um software. Por m, citamos uma denio de design que engloba todos estes aspectos: Denio 2.1 (design de software). tanto o processo de denio da arquitetura, mdulos, interfaces e outras caractersticas de um sistema quanto o resultado desse processo. 3 2.1.2 Caractersticas de Design de Software Projetar os diversos aspectos de um sistema de software um processo trabalhoso. No entanto, pode proporcionar diversos benefcios. Design de software permite avaliao prvia. Como desenvolver software custa tempo e dinheiro, no parece sensato algum investir seus recursos no desenvolvimento de um sistema que no soluciona os problemas propostos pelos interessados. Dessa maneira, a avaliao prvia do sistema se torna imprescindvel para garantir que ele alcance os objetivos desses interessados. Como o design descreve diversos aspectos que estaro presentes no sistema quando construdo, ele permite esse tipo de avaliao. Alm disso, fazer o design de um sistema , geralmente, mais barato que constru-lo. Exemplo 2.2. Considerando o sistema do Exemplo 2.1 e que um de seus objetivos fosse a alta disponibilidade, podemos avaliar que o design apresentado
3
Freny Katki et al, editores. IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., 1991.
11
no seria a melhor soluo para o objetivo proposto. Isso ocorre porque seu design possui um ponto nico de falhas, que uma caracterstica indesejvel para sistemas que buscam alta disponibilidade. Note ainda que no foi necessrio ter o HBase desenvolvido para percebermos esse problema (na poca em que implementava tal design, ele possua cerca de cem mil linhas de cdigo e alguns anos de desenvolvimento e, portanto, no sendo um software de desenvolvimento trivial), bastou apenas estudarmos seu design. Design de software estimula modelagem. Ao modelar um sistema, o designer se concentra no domnio do problema, ignorando temporariamente detalhes menos signicativos para se alcanar a soluo. Isso facilita a separao da complexidade essencial da complexidade acidental do problema. E, como j dito por Fred Brooks em The Mythical Man-Month, essa separao benca para a qualidade nal do sistema projetado. Design de software envolve planejamento. Uma vez que o design serve de guia para a construo do sistema, o designer deve ento antecipar o que ser necessrio para tanto. Esse planejamento ajuda na estimativa dos diversos custos envolvidos no desenvolvimento do sistema. Entre esses custos, podemos citar: Quanto tempo durar todo o desenvolvimento, Quantos desenvolvedores sero necessrios para o mdulo A, Quanto custar o mdulo B, caso for comprado ou caso for implementado, Ou qual ser o custo total do desenvolvimento do sistema. Design de software facilita a comunicao, pois contm conhecimento sobre o sistema que pode ser gravado, transmitido e discutido entre os interessados. Um caso bem comum o de apresentar um sistema a novos membros de um time de desenvolvimento. Por exemplo, quais os principais mdulos e seus diversos comportamentos ou outras informaes valiosas lhes podem ser passadas atravs do design do sistema antes de mostrar-lhes o cdigo-fonte. Dessa maneira, essas informaes de alto nvel de abstrao ajudaro a situlos no cdigo posteriormente. No entanto, o design no serve apenas para os desenvolvedores. Um usurio do sistema pode procurar no design informaes de um nvel ainda maior de abstrao, como quais funes o sistema capaz de realizar, ou qual o desempenho delas. Por outro lado, design de software tambm demanda algumas observaes importantes.
12
O problema a ser resolvido pode no permanecer o mesmo durante todo o processo de design. Ao passo que o design implementado, o cliente, que o stakeholder interessado em que o software construdo solucione um problema em particular, (1) pode mudar de ideia quanto natureza do problema; (2) pode ter descrito o problema incorretamente; ou ainda (3) pode decidir que o problema mudou ou mesmo que j fora resolvido enquanto o design estar sendo feito. Essas possibilidades no devem ser ignoradas durante o desenvolvimento, uma vez que elas podem ocasionar em perda de tempo e dinheiro durante a fase de design ou ainda ocasionar o fracasso no atendimento s necessidades do cliente. H diferenas entre o design e o sistema construdo a partir dele. O design de um software apenas um modelo, do qual o nvel de detalhes pode no ser adequado para certos tipos de avaliao. Por sinal, avaliar um design insucientemente detalhado pode levar a resultados errneos e, consequentemente, h sistemas que no resolvem os problemas da forma esperada. Isso comum acontecer, por exemplo, quando por erro do projetista, detalhes importantes para a avaliao no so includos no design. O exemplo a seguir ilustra um caso em que a avaliao inadequada resultou em um produto com problemas. Exemplo 2.3. Um caso conhecido de produto com falhas por avaliao inadequada o caso de um sistema de controle de armamento para cruzadores da marinha norte-americana que foi desenvolvido pela empresa Aegis. Depois de desenvolvido, o sistema de armamento foi instalado no cruzador U.S.S. Ticonderoga para o primeiro teste operacional. No entanto, os resultados do teste demonstraram que o sistema errava 63% dos alvos escolhidos devido a falhas no software. Posteriormente, foi descoberto que a avaliao e os testes do software de controle foram realizados numa escala menor do que as condies reais e que, alm disso, os casos de teste incluam uma quantidade de alvos menor que a esperada em campo de batalha.4 Por mais ecaz que um design seja, sua implementao pode no ser. O fato de haver um design bem elaborado para um determinado software no garante que na fase de implementao os desenvolvedores sigam as regras previamente especicadas e que o cdigo produzido reita elmente o que foi especicado. Isto certamente um grande problema na construo de sistemas de software,
4
Uma descrio mais completa deste caso pode ser encontrada no artigo The Development of Software for Ballistic-Missile Defense [53], de Lin.
2.2 Elementos do processo de design de software
13
pois pode acarretar na construo de um produto que no era o esperado, e at mesmo levar ao insucesso em sua construo. Felizmente, na Engenharia de Software existem dois mecanismos que visam diminuir as divergncias entre design e implementao. O primeiro mecanismo diz respeito vericao de software, isto , vericar se o software foi construdo corretamente, se atendeu s especicaes do design. Por outro lado, a validao de software est ligada satisfao do cliente diante do produto, isto , se o software construdo o desejado, se atende aos requisitos do cliente.

O processo de design pode ser descrito como o processo de escolha da representao de uma soluo a partir de vrias alternativas, dadas as restries que um conjunto de objetivos envolve. Esse processo, ilustrado na Figura 2.1, pode ser dividido em duas fases: diversicao e convergncia.
Figura 2.1. Ilustrao do processo de design
durante a fase de diversicao que alternativas so geradas. Por alternativas, no nos referimos necessariamente a documentos descrevendo uma possvel soluo, mas tambm ideias de soluo. Essas alternativas so solu-
14
es em potencial e so geradas/obtidas a partir do conhecimento e da experincia do designer. J na fase de convergncia, o designer escolhe a alternativa (ou combinao de alternativas) que satisfaz aos objetivos esperados. A escolha compor a soluo que se sujeitar s restries impostas pelo domnio do problema. Essa soluo ser descrita por meio de alguma representao e essa representao escolhida deve estar de acordo com seus propsitos: descrever a soluo e permitir a construo do sistema que melhor alcana os objetivos esperados. Os elementos enfatizados no pargrafo anterior (objetivos, restries, alternativas, representaes e solues), juntos, denem um arcabouo conceitual que nos ajuda a entender o processo de design de software. 2.2.1 Objetivos O processo de design tem incio com uma necessidade. Se algo projetado, e consequentemente construdo, porque o produto proveniente do projeto suprir essa necessidade. Em Engenharia de Software, a necessidade parte do cliente que especica quais suas necessidades5 e, portanto, quais os objetivos a serem atingidos pelo sistema de software a ser projetado. Assim, o objetivo do processo de design pode ser denido como: Denio 2.2 (objetivo de design). Aquilo que se pretende alcanar para atender as necessidades do cliente. Em design de software, objetivos tambm so chamados de requisitos. O design se preocupa com dois tipos de requisitos: requisitos funcionais e requisitos no-funcionais. Um requisito funcional especica a funcionalidade que um sistema exibe. Denio 2.3 (requisito funcional). a declarao de uma funo ou comportamento provido pelo sistema sob condies especcas. Em outras palavras, o que o sistema faz para alcanar s expectativas do cliente. Por exemplo, um requisito funcional de um programa de ordenao
5
Vale lembrar que h transitividade nas necessidades do cliente. Um exemplo de quando acontece quando clientes e usurios do sistema so entidades distintas. Ento, entre as necessidades do cliente estaro: as necessidades do usurio devem ser atendidas. E, portanto, o software ter que atender ter que satisfazer tambm aos objetivos do usurio, alm dos objetivos do cliente.
15
de nmeros pode ser descrita como sua capacidade de ordenar inteiros; ou, se estamos falando de um sistema de informao de uma locadora de lmes em DVD, temos como requisitos funcionais, entre outros, a capacidade de buscar um lme usando palavras-chave, a capacidade de realizar o aluguel de um ou vrios DVDs, ou a capacidade de realizar a devoluo de um ou vrios DVDs. Por outro lado, um requisito no-funcional, especica propriedades ou caractersticas que o sistema de software deve exibir diferentes dos requisitos funcionais. Os requisitos no-funcionais so atendidos pelos atributos de qualidade do software. Denio 2.4 (requisito no-funcional). a descrio de propriedades, caractersticas ou restries que o software apresenta exibidas por suas funcionalidades. Em outras palavras, basicamente como o sistema funcionar. De volta ao exemplo do programa de ordenar nmeros, um requisito no-funcional que podemos mencionar o tempo de execuo da funo de ordenao do sistema (por exemplo, aceitvel que o tempo de execuo do algoritmo de ordenao tenha uma taxa de crescimento de O(n log n), onde n a quantidade de elementos a serem ordenados). J no sistema da locadora de lmes, um exemplo de atributo de qualidade a exposio de algumas de suas funcionalidades via internet (e.g., busca e reserva de lmes atravs de um site disponibilizado pelo sistema). Como os requisitos no-funcionais e os atributos de qualidade tm um papel importante na arquitetura do software, ns dedicaremos um captulo a eles, onde sero descritos, categorizados e exemplicados em detalhes, alm de serem relacionados aos stakeholders que os demandam. 2.2.2 Restries O produto de design deve ser vivel. Dessa maneira, restries so as regras, requisitos, relaes, convenes, ou princpios que denem o contexto do processo de design, de forma que seu produto seja vivel. Denio 2.5 (restrio de design). A regra, requisito, relao, conveno, ou princpio que dene o texto do processo de design. importante saber que restries so diretamente relacionadas a objetivos e que, em alguns casos, eles so at intercambiveis. No entanto, uma vez
16
que no so apenas os objetivos que guiam o processo de design, necessrio diferenciar objetivos de restries. Em outras palavras, um sistema pode ter objetivos claros, mas seu design ou algumas alternativas dele podem ser inviveis devido s restries. A seguir, apresentamos dois exemplos que nos ajudaro a entender o papel das restries no design. No primeiro exemplo, apesar do sistema ter um objetivo claro, seu design no vivel devido a uma restrio. Exemplo 2.4. Consideremos que um cliente deseje um sistema com um nico objetivo: o sistema deve decidir se um programa, cuja descrio informada como parmetro de entrada, termina sua execuo ou no. Um designer inexperiente pode at tentar encontrar alguma alternativa de design para esse requisito mas podemos ter certeza que a tentativa ser em vo. Como bem conhecido, h uma restrio terica em Cincia da Computao, conhecida como o problema da parada, que impede o desenvolvimento de um programa capaz de alcanar o objetivo proposto. Como essa restrio impede a criao de qualquer alternativa de design que satisfaa o cliente, podemos observar que um design pode ser se tornar invivel mesmo que seus objetivos sejam bem claros. J no segundo exemplo, o sistema tambm tem um objetivo claro. No entanto, uma restrio torna uma possibilidade de design invivel. Exemplo 2.5. Um cliente especica que seu sistema de software deve ser capaz de ler dados de um leitor de cartes de um modelo especco. No entanto, ao estudar o requisito e, consequentemente, o leitor de cartes, o designer encontra a seguinte restrio. O fabricante do leitor em questo no o fornece driver necessrio para um dos sistemas operacionais em que o sistema deve executar. Podemos observar que, se no fosse por essa restrio, o design para o mdulo de entrada de dados do sistema seria simples: apenas dependeria do driver do leitor para obter os dados dos cartes. No entanto, agora o designer ter que criar um design alternativo para contornar a restrio encontrada. Para isso, podemos citar algumas possibilidades desse design. Uma possibilidade seria emular um dos sistemas operacionais suportados quando o software estivesse executando num ambiente no suportado. Isso signica que seria necessria a criao de uma camada de abstrao entre o driver do leitor e o sistema operacional onde o software est executando, onde essa camada representaria
17
o ambiente operacional suportado. Essa camada de abstrao, ento, seria implementada pelo sistema nativo ou por um emulado, caso o nativo fosse o no-suportado pelo driver. Outra possibilidade de design seria o projeto e a implementao do prprio driver para o ambiente no-suportado. 2.2.3 Alternativas Uma alternativa de design uma possibilidade de soluo. Uma vez que problemas de design geralmente possuem mltiplas solues possveis, comum que sejam geradas mais de uma alternativa para a soluo de um nico problema. Note que o designer no necessariamente documentar todas as possibilidades de soluo, mas, ao menos, considerar algumas delas para eleio de uma soluo, mesmo que informalmente. Denio 2.6 (alternativa de design). Uma possibilidade de soluo representada em nvel de conhecimento. O que precisamos observar que o designer deve realizar duas tarefas essenciais aps entender os objetivos e restries envolvidos no problema de design: gerar alternativas de design e eleger a soluo do problema dentre as alternativas geradas. A gerao de alternativas o real desao para os designers. Diferente dos problemas de deciso, onde alternativas so conhecidas ou buscadas atravs de mtodos conhecidos, problemas de design pedem a criao de alternativas. O processo de criao deve ser controlado por princpios de design, pela experincia e imaginao do designer e deve ser guiado pelos objetivos do produto impostos pelos stakeholders. Alguns princpios essenciais de design sero apresentados ainda neste captulo. J a eleio da soluo simplesmente a escolha de uma dentre as alternativas geradas, desde que essa sirva para a soluo do problema. A escolha da soluo deve ser realizada baseada em avaliaes e experincia. Exemplo 2.6. De volta ao nosso programa de ordenao, consideremos apenas uma de suas caractersticas: o algoritmo de ordenao a ser usado. Vamos observar quantas alternativas um designer poderia gerar s a partir dessa caracterstica. Uma rpida pesquisa na internet retorna nove algoritmos que respeitam o requisito imposto anteriormente de crescimento do tempo de execuo
18
(O(n log n)): binary tree sort, heapsort, in-place merge sort, introsort, library sort, merge sort, quicksort, smoothsort, strand sort. Assim, esses nove algoritmos poderiam ser transformados em nove alternativas de design. Adicionalmente, um designer mais experiente em ordenao saberia que os dados de entrada podem denir o desempenho real do algoritmo, uma vez que uma das alternativas pode ter um timo desempenho para uma determinada entrada, enquanto outra alternativa, ainda que respeitando o mesmo desempenho assinttico O(n log n), pode ter um pssimo desempenho real para a mesma entrada. Neste caso, ele deniria que dois algoritmos sero usados no design, de forma que, de acordo com os dados de entrada, o algoritmo de melhor desempenho real para esses dados seja escolhido em tempo de execuo. Assim, ainda mais alternativas de design so geradas. Devemos observar que a gerao de alternativas poderia continuar indenidamente caso o designer considerasse outros aspectos do problema. Dessa maneira, quando parar a gerao de alternativas um problema tambm a ser resolvido pelo designer, uma vez que problemas de design geralmente tm um nmero innito de solues em potencial. Essa noo de quando parar o processo de gerao de alternativas, certamente, adquirida com a experincia. 2.2.4 Representaes A representao a linguagem do design. Apesar do real produto do processo de design ser a representao de um sistema de software que possibilita sua construo, descrever o sistema no o nico propsito das representaes. A representao tambm facilita o prprio processo de design, uma vez que ajuda na comunicao dos interessados e tambm serve como registro das decises tomadas. Denio 2.7 (representao de design). A linguagem do processo de design que representa o produto do design para sua construo e tambm d suporte ao processo de design como um todo. A representao facilita a comunicao porque torna as alternativas em produtos manipulveis, que podem ser comunicados, avaliados, e discutidos, no s por seus criadores, mas tambm por outros interessados.
19
importante observar que existem diversas dimenses a serem representadas numa nica alternativa de design. Essas dimenses abrangem comportamento, estrutura, relaes entre entidades lgicas e entidades fsicas, entre outros. Essas dimenses so normalmente descritas em diferentes tipos de representaes, que, em outro momento, sero chamadas de vises. Para exemplicar representaes de design, apresentaremos duas dimenses derivadas do nosso programa-exemplo de ordenao usando duas representaes diferentes. A primeira representao, ilustrada pela Figura 2.2, mostra a dimenso estrutural de uma alternativa de design usando UML6 . Examinando essa representao, podemos observar alguns aspectos da soluo: como a soluo foi decomposta em classes funcionais, como as diversas classes da estrutura se relacionam entre si, ou at em que pontos poderamos reusar pedaos de software prontos para a construo, desde que implementem as mesmas interfaces descritas na representao. No entanto, devemos tambm observar que essa representao no autocontida, uma vez que necessrio conhecimento em UML para entend-la completamente.
Figura 2.2. Representao estrutural do programa de ordenao
J a segunda representao, Figura 2.3, mostra parte do comportamento do programa de ordenao com alto nvel de detalhe. Apesar de no conseguirmos extrair dessa representao a mesma informao apresentada na gura
6
Unied Modeling Language (UML)
20
anterior, essa nos permite analisar seu comportamento assinttico em relao ao crescimento do tamanho dos dados de entrada. Alm disso, podemos tambm analisar o espao consumido na execuo do algoritmo. Ambas as representaes mostram aspectos importantes do design de um software. No entanto, os stakeholders envolvidos no seu desenvolvimento podem ainda estar interessados em outros aspectos alm da estrutura ou anlise assinttica do algoritmo. Por isso, outras representaes podem ainda ser necessrias para mostrar outros aspectos do sistema, e papel do processo de design e do designer prov-las. Por m, se considerarmos mltiplas verses ao longo do tempo de uma nica representao, poderemos observar a evoluo das decises de design feitas ao longo desse perodo. Assim, se considerarmos as diversas verses obtidas at se alcanar o algoritmo descrito na Figura 2.3, perceberamos a evoluo desde o merge sort padro at o merge sort in-place considerado pelo designer. Ento, o histrico do design se torna pea fundamental para se entender quais decises passadas levaram ao estado atual do design e, consequentemente, do sistema. 2.2.5 Solues A soluo de design no nada alm do que a descrio que permite desenvolvedores construir um sistema de software a partir dos detalhes especicados por uma ou diversas representaes. Suas principais caractersticas sero descritas nos pargrafos a seguir. Denio 2.8 (soluo de design). A descrio do design que permite a construo do sistema de software que alcana os objetivos do design. Solues de design reetem a complexidade do problema, geralmente por mostrar diversos elementos e relaes que compem o problema. possvel observar essa caracterstica quando, por exemplo, fazendo o design do sistema de informao de uma locadora que j mencionamos anteriormente. Qualquer que seja a soluo, ela conter elementos como lmes, DVDs, clientes ou gneros de lmes, pois todos eles so inerentes ao problema em questo. No entanto, s os elementos no so o bastante para compor a soluo. A soluo deve tambm conter relaes do tipo: um cliente pode alugar um ou mais DVDs, um lme pode ter um ou mais gneros, ou um DVD pode conter um
21
Figura 2.3. Pseudocdigo do Merge sort
22
ou mais lmes. Em outras palavras, a soluo deve conter relaes similares s relaes encontradas no domnio do problema. Vale lembrar que, quando diversos elementos tm diversas relaes diferentes entre si, a complexidade emerge e por isso que fazer design difcil. Adicionalmente, para complicar ainda mais, comum que os problemas tenham muitos elementos e relaes que no so completamente conhecidos. difcil validar solues de design. A complexidade inerente ao problema faz surgir diversos pontos de possvel validao em relao aos objetivos de design. No entanto, o problema reside na preciso da descrio dos objetivos. Normalmente, para problemas complexos, objetivos so descritos num alto-nvel de abstrao que diculta ou impossibilita bastante a avaliao das solues. E, por m, a maioria dos problemas de design aceita diversas solues. Isso algo natural a problemas de design: uma vez que diversas alternativas podem ser geradas a partir de um nico problema de design, diversas solues podem ser obtidas.
2.3 Nveis de design de software

O produto do processo de design sempre uma soluo de design. Apesar de ser a descrio que permite a construo do sistema, nada foi dito sobre o nvel de detalhe contido nessa soluo. Acontece que, na verdade, o design pode ocorrer em diversos nveis de detalhe. De acordo com o Guia para o Corpo de Conhecimento em Engenharia de Software, o processo de design de software consiste em duas atividades: design de alto nvel e design detalhado. O design de alto nvel, tambm conhecido como design arquitetural, trata de descrever a organizao fundamental do sistema, identicando seus diversos mdulos (e sua relaes entre si e com o ambiente) para que se alcancem os objetivos propostos pelo cliente. Denio 2.9 (design arquitetural). Descreve a arquitetura do software ou, em poucas palavras, como o software decomposto e organizado em mdulos e suas relaes.
2.4 Princpios e tcnicas de design de software
23
Ao contrrio do design de alto nvel, o design detalhado se preocupa com a descrio detalhada de cada mdulo possibilitando a construo e se adequando ao design de alto nvel. Denio 2.10 (design detalhado). Descreve o comportamento especco e em detalhes dos mdulos que compem o design arquitetural. Apesar dessa diviso conceitual de design em duas atividades, essa diviso pode no acontecer durante o processo de desenvolvimento do software. Algumas vezes, o designer ou quem assume seu papel realiza ambas as atividades simultaneamente, concebendo assim um produto de design que permitir tanto o alcance dos requisitos de qualidade (que normalmente tarefa da arquitetura), quanto a construo precisa do sistema por meio de seus detalhes. No entanto, adotaremos a separao conceitual das duas atividades de forma que possamos nos focar no design arquitetural, que o principal assunto desse livro e que ser discutido nos prximos captulos.

Antes de iniciarmos nossos estudos em Arquitetura de Software, gostaramos de lembrar alguns princpios e tcnicas que so essenciais ao design de software. H diversos princpios, tcnicas, e abordagens nessa rea que geralmente resultam em bons produtos de design de software. Uma vez que h muitos livros e artigos sobre esse assunto, gostaramos apenas de fazer uma breve exposio do assunto nessa seo, fazendo com que o leitor relembre os princpios e tcnicas caso j os conhea e indicando referncias para um maior aprofundamento sobre o assunto. Os princpios, tcnicas e abordagens essenciais para um designer que apresentaremos so as seguintes: Diviso e conquista Abstrao Encapsulamento Modularizao Separao de preocupaes Acoplamento e coeso Separao de polticas da execuo de algoritmos Separao de interfaces de suas implementaes
24
2.4.1 Diviso e Conquista Diviso e conquista uma tcnica para resoluo de problemas que consiste em decompor um problema em subproblemas menores e independentes a m de resolv-los separadamente, para que, posteriormente, as solues sejam combinadas e formem a soluo do problema inicialmente proposto. A estratgia baseada na ideia de que atacar um problema complexo por diversas frentes mais simples e factvel de resoluo do que tentar resolv-lo completamente de uma s vez. A tcnica de diviso e conquista possui trs etapas bem denidas: Diviso: dividir o problema original em subproblemas menores; Conquista: resolver cada um dos subproblemas gerados na fase de diviso; Combinao: combinar as solues de cada subproblema, compondo a soluo para o problema inicial. Em Cincia da Computao, essa estratgia muito utilizada no projeto de algoritmos e, normalmente, instanciada atravs do uso de recurso, uma vez que os problemas devem ser decompostos e as solues dos subproblemas devem ser combinadas ao nal da execuo para compor a soluo do problema inicial. Por exemplo, o algoritmo de ordenao mergesort se utiliza dessa tcnica para ordenar uma sequncia de inteiros de maneira eciente. Esse algoritmo se baseia na idia de que dadas duas sequncias ordenadas, fcil orden-las em uma nica sequncia. Portanto, a estratgia do mergesort particionar uma sequncia em vrias subsequncias at que seja trivial orden-las, isto , sequncias de dois elementos. Por m, o algoritmo combina as sequncias em uma s sequncia ordenada. No entanto, como este livro foi escrito com foco em arquitetura de software, nada mais apropriado do que trazermos exemplos em nvel arquitetural dos assuntos que abordamos. A estratgia de diviso e conquista tambm aplicada constantemente em decises de mais alto nvel no projeto de software. Por exemplo, a deciso de organizar uma aplicao web em camadas nada mais que dividir um problema maior em diferentes nveis de abstrao, onde cada camada ser responsvel por implementar um servio mais bsico e especco (apresentao, lgica de negcio e armazenamento). Vrios so os benefcios providos pela estratgia de diviso e conquista. No nosso exemplo, a diviso da arquitetura em camadas propicia a implementao de cada camada separadamente. Alm disso, as camadas podem ser
25
tratadas como componentes reusveis de software, uma vez que implementam um servio nico e bem denido. Portanto, diviso e conquista tambm viabiliza o reuso de software. 2.4.2 Abstrao Abstrao um princpio essencial para se lidar com complexidade. Esse princpio recomenda que um elemento que compe o design deve ser representado apenas por suas caractersticas essenciais, de forma que permita a distino de outros elementos por parte do observador. Como resultado, temos a representao de um elemento do design mais simples, uma vez que detalhes desnecessrios so descartados, facilitando ento o entendimento, comunicao e avaliao. O que poderemos observar que a maioria das tcnicas empregadas por designers ajudam na elevao do nvel de abstrao do design e, assim, baixam o nvel de complexidade da soluo. 2.4.3 Encapsulamento Encapsulamento est relacionado ocultao de detalhes de implementao de um elemento de um sistema aos que usaro esse elemento. Fazendo isso, o acoplamento entre os elementos minimizado e sua contribuio para a complexidade do sistema restringida s informaes que eles expem. Encapsulamento pode ser obtido de diferentes maneiras: modularizando o sistema, separando suas preocupaes, separando interfaces de implementaes, ou separando polticas da execuo de algoritmos. 2.4.4 Modularizao Modularizao a decomposio signicativa do sistema em mdulos. A modularizao introduz parties bem-denidas e documentadas ao sistema ao decidir como estruturas lgicas do sistema sero divididas sicamente. Podemos citar alguns benefcios da modularizao: Facilita o entendimento, uma vez que cada mdulo pode ser estudado separadamente; Facilita o desenvolvimento, uma vez que cada mdulo pode ser projetado, implementado e testado separadamente;
26
Diminui o tempo de desenvolvimento, uma vez que mdulos podem ser implementados em paralelo, ou ainda reusados; e Promove a exibilidade no produto, uma vez que um mdulo pode ser substitudo por outro, desde que implemente as mesmas interfaces.
2.4.5 Separao de preocupaes A separao de preocupaes est fortemente ligada ao princpio da modularizao. De certa maneira, a separao de preocupaes dene a regra para denir os mdulos de um sistema: preocupaes diferentes ou no-relacionadas devem se restringir a mdulos diferentes. Assim, separando preocupaes, obtemos benefcios semelhantes aos da modularizao. 2.4.6 Acoplamento e coeso Acoplamento e coeso so princpios usados para medir se mdulos de um design foram bem divididos. Acoplamento a medida de interdependncia entre mdulos de software. Ou seja, quanto mais dependente um mdulo A da implementao do mdulo B, maior o acoplamento entre os mdulos A e B. Alto acoplamento implica que (1) os mdulos envolvidos sero mais difceis de entender, uma vez que precisam ser entendidos em conjunto; (2) os mdulos envolvidos sero mais difceis de modicar, uma vez que as mudanas impactaro mais de um mdulo; e (3) os mdulos envolvidos sero mais difceis de manter, uma vez que um problema num mdulo se espalhar pelos mdulos com quem est altamente acoplados. Por outro lado, coeso uma medida intramdulo. Ela a medida da relao entre tarefas realizadas dentro de um mesmo mdulo. As tarefas de um mdulo podem estar relacionadas entre si por diferentes motivos. Esses motivos so usados para classicar os diferentes tipos de coeso: Coeso funcional : as tarefas esto agrupadas por suas funes serem similares. Coeso sequencial : as tarefas esto agrupadas por elas pertencerem mesma sequncia de operaes. Elas compartilham dados a cada etapa da sequncia, mas no realizam uma operao completa quando executadas juntas.
27
Coeso comunicativa : as tarefas esto agrupadas porque usam os mesmos dados, mas no esto relacionadas de nenhuma outra maneira. Coeso temporal : as tarefas esto agrupadas por serem executadas no mesmo intervalo de tempo. Coeso procedural : as tarefas esto agrupadas porque elas devem ser executadas numa ordem especca. Coeso lgica : as tarefas esto agrupadas por compartilharem uma mesma ag de controle, que indicar qual tarefa ser realizada durante a execuo do sistema. Coeso coincidente : as tarefas esto agrupadas sem qualquer critrio. Para alcanarmos bons designs, podemos ordenar os tipos de coeso dos mais desejveis para os menos desejveis: funcional, sequencial, comunicativa, temporal, procedural, lgica, e coincidente. 2.4.7 Separao de Decises de Execuo de Algoritmos Essa tcnica realiza a separao de preocupaes apresentando uma abordagem simples: ou um mdulo deve se preocupar com as decises sensveis ao contexto do problema ou com a execuo de algoritmos, mas no ambos. Em outras palavras, alguns mdulos devem apenas executar algoritmos sem fazer qualquer deciso sensvel ao domnio do problema. Essas decises devem ser deixadas para os mdulos especcos para realizao dessas decises e que tambm sero responsveis por suprir parmetros para os mdulos de execuo de algoritmos. Essa separao facilita o reuso e a manuteno, principalmente dos mdulos de algoritmos, uma vez que eles so menos especcos que os mdulos de decises sensveis a contexto. 2.4.8 Separao de Interfaces de suas Implementaes A separao entre interfaces e implementaes tambm benecia a modularizao. Essa tcnica recomenda a descrio da funcionalidade a ser implementada por algum mdulo por meio de contratos, chamados interfaces. Assim, os mdulos implementaro as interfaces de forma a comporem o sistema. Usando essa tcnica, o acoplamento entre mdulos e seus clientes diminudo, uma vez que os clientes estaro ligados apenas a interfaces e no
28
implementaes , e benefcios como facilidade no reuso, melhor entendimento do cdigo, e menor custo de manuteno so alcanados.
Resumo
Esse captulo exps o conhecimento necessrio sobre Design de Software para o estudo de Arquitetura de Software. Espera-se que, ao nal desse captulo, o leitor saiba: o que design software, seja como produto ou como processo, e quais so suas caractersticas e benefcios; como os problemas de design de software podem ser decompostos; e o que so os princpios e tcnicas de design de software e quais seus benefcios. Pela existncia de timos livros sobre Design de Software j escritos tendo em vista o mesmo pblico-alvo que ns (o leitor ainda inexperiente), ns preferimos no nos aprofundar nos assuntos expostos nesse captulo, uma vez que nossa inteno foi de apenas introduzi-los. Para informaes mais detalhadas, recomendamos os livros e artigos sobre Design de Software apresentados na seo de referncias.
Referncias
Teoria em Design de Software Recomendamos o livro Software Design [14], de Budgen, aos interessados em mais informaes sobre a teoria em design de software. Dois artigos que apresentam discusses teis sobre o assunto so Software Design and Architecture The Once and Future Focus of Software Engineering [82], de Taylor e Van der Hoek, e Conceptual Foundations of Design Problem Solving [77], de Smith e Browne. Inclusive, este ltimo a nossa referncia sobre o arcabouo conceitual de design usado neste captulo.
29
Processo de Design Em nvel mais prtico da execuo do processo de design, citamos as seguintes referncias: The Mythical Man-Month: Essays on Software Engineering [12], de Brooks, que discute as causas da complexidade que assola o processo de design de software; Software Design: Methods and Techniques [7], que descreve as etapas que podemos encontrar no processo de design; e o Guide to the Software Engineering Body of Knowledge (SWEBOK) [1], que apresenta os nveis de design. Tcnicas e Ferramentas Por m, citamos referncias que descrevem ferramentas e tcnicas que podemos usar durante o processo de design. Sobre a linguagem de modelagem UML, mais informaes podem ser encontradas no site do Object Management Group (OMG) [65]. J sobre tcnicas de design, citamos o livro de Booch et al, Object-Oriented Analysis and Design with Applications [11], o de McConnell, Code Complete [60] e o de Buschmann et al, Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [17]. Este ltimo mais especco ao design arquitetural.
Exerccios
2.1. Quais os benefcios de se projetar sistemas? 2.2. Duas fases importantes do projeto de software so as fases de Divergncia e Convergncia. Descreva o que feito em cada fase. 2.3. Jack Reeves, em What is Software Design? [71], arma que o cdigo fonte design. Qual a sua opinio a respeito da armativa? 2.4. Qual padro de projeto viabiliza a separao de poltica e implementao? 2.5. Dena coeso e acoplamento e sugira mtricas para medi-las em software. 2.6. Cite diculdades que podem ser encontradas durante a aplicao de cada tcnica de design apresentada no captulo.
30
2.7. Represente um design de software de duas maneiras diferentes. Para isso, antes ser necessrio descrever o problema que o software deve resolver. 2.8. Elabore uma soluo de design diferente para o problema descrito na resposta do anterior e descreva-a usando os mesmos tipos de representaes usados anteriormente.
3 Estudo de Caso: SASF
Como muitos dos problemas relacionados Arquitetura de Software s fazem sentido em sistemas complexos, difcil ilustrar diversos aspectos dessa rea apenas com exemplos simples. Assim, resolvemos adotar uma abordagem de ensino orientada a estudo de caso. Essa abordagem consiste em fazer com que o leitor acompanhe a construo da arquitetura de um sistema e, dessa maneira, possa observar na prtica o uso do conhecimento encontrado no livro. Ao longo deste livro, o leitor acompanhar um processo de design e documentao de uma arquitetura que possibilitar a implementao de um sistema complexo. Assim, ser durante esse processo que sero apresentados os conceitos e generalizaes essenciais para se formar um bom arquiteto de software. Tambm faremos uso de outros exemplos capazes de expor aspectos complementares ao estudo de caso.
3.1 Apresentao do estudo de caso

O sistema atravs do qual acompanharemos o processo de design e documentao de sua arquitetura ser o Sistema de Aluguel e Streaming de Filmes (SASF). O SASF um sistema de informao com dois grandes objetivos: (1) gerenciar o processo de locao via web de vdeos e (2) proporcionar infraestrutura de software para realizar streaming de vdeos tambm via web. O SASF um sistema ctcio baseado no Netix 1 e na iTunes Store 2 .
1 2
Netix : http://www.netflix.com/ iTunes Store : www.apple.com/itunes
32
Esse sistema foi escolhido como estudo de caso por ter funcionalidades e atributos de qualidade no-triviais, alm de pertencer a um domnio de problema mais comum do que os encontrados na literatura. A no-trivialidade de suas funes e de seus atributos de qualidade servir como alvo para mostrar a necessidade e aplicao dos conhecimentos em Arquitetura de Software. J em relao abordagem de um domnio de problema relativamente simples, essa foi um dos fatores-chave para a escrita deste livro. Nos livros essenciais sobre Arquitetura de Software, bastante comum acompanharmos estudos de caso de projetos militares ou da indstria aeroespacial. Esses projetos so riqussimos em detalhes e se encaixam perfeitamente necessidade de se estudar e aplicar os conhecimentos em Arquitetura de Software. Por outro lado, esses mesmos projetos, apesar de bem prximos realidade dos autores dos livros em questo, so distantes da realidade do leitor ainda inexperiente em Engenharia de Software. Sendo assim, ao encontrar estudos de caso ou exemplos num domnio de problema pouco familiar, o leitor no se sente motivado e encontra diculdades para concretizar os conceitos expostos ao longo dos livros.
3.2 Funcionalidades do SASF

Com a popularizao da Internet, muitas empresas perceberam a oportunidade de, atravs dela, alcanar novos consumidores. O SASF se alinha com essa idia. Seu papel permitir que um cliente alugue um lme3 usando apenas um navegador, sem estar presente sicamente numa loja. Dessa maneira, esse sistema aumenta o nmero dos clientes em potencial da empresa, uma vez que eles deixam de ser apenas aqueles capazes de chegar loja fsica para ser todos aqueles presentes na rea de alcance da infraestrutura usada para entrega e coleta de vdeos. 3.2.1 Locao e Streaming de vdeo O principal usurio do SASF aquele interessado em alugar vdeos. Esse usurio, aps se cadastrar no sistema, ser capaz de (Fig. 3.1):
3
Ao longo deste livro, apesar de usarmos a palavra lme, estamos nos referindo a vdeos em geral, podendo ser tambm, seriados de TV, musicais, ou mesmo documentrios, alm de lmes. Assim, os termos lme e vdeo so intercambiveis a no ser que sejamos explcitos quanto suas diferenas.
33
enleirar lmes que sero enviados para sua casa obedecendo poltica de sua assinatura, assistir a um lme via streaming em algum dispositivo ou aplicativo integrado e autorizado a se comunicar com o SASF.
Figura 3.1. Principais funcionalidades do SASF: streaming de vdeo para diversos dispositivos e gerncia do aluguel de lmes
As opes de assinatura disponveis a esse tipo de usurio variam em relao ao nmero mximo de vdeos que ele pode ter em sua casa ao mesmo tempo. Dessa maneira, dado que o usurio enleirou inicialmente 10 vdeos para aluguel, se sua assinatura permitir apenas um vdeo em sua casa por vez, o segundo vdeo da la s ser enviado para sua casa quando o primeiro for devolvido. De maneira anloga, se a assinatura for de trs vdeos por vez, inicialmente, os trs vdeos sero enviados e, medida que eles forem devolvidos, a la ser esvaziada at que no sobre nenhum vdeo na la ou o usurio esteja com trs vdeos em sua casa. Vale notar que a la pode crescer indenidamente. Os vdeos so entregues na casa do usurio pelos correios e ele pode car com as mdias o tempo que quiser. No h qualquer tipo de penalidade se o usurio car com elas por muito tempo. O nico incentivo para que ele as devolva que ele no receber mais vdeos de sua la at que alguma mdia
34
seja devolvida. Portanto, a devoluo tambm realizada pelos correios: o usurio envia as mdias para a empresa e, assim, possibilita que mais vdeos lhe sejam enviados. Uma outra opo assistir aos lmes atravs da Internet, via streaming de vdeo usando algum aparelho ou aplicativo que saiba conversar com o SASF. Assim, no preciso esperar pela entrega da mdia pelos correios, nem esperar o tempo de download do vdeo para que se comece a assisti-lo, j que a idia do streaming consumir o arquivo de mdia transmitido medida que ele recebido. Isto, ainda por cima, economiza tempo do usurio, uma vez que ele pode assistir ao lme agora, e diminui gastos com logstica por parte da empresa, uma vez que no precisa usar os servios de uma transportadora para realizar a entrega do lme, alm de economizar com compra e manuteno de mdias. Ao prover um servio de streaming para os usurios, surgem novas preocupaes. O streaming de vdeo realizado pelo SASF pode ter vrios destinos: uma aplicao cliente executando no navegador do usurio ou como aplicativo stand-alone disponibilizado para download no prprio site, decodicadores de TV por assinatura, celulares 3G ou outros sistemas capazes de receber dados e que sejam integrados ao SASF. Por existirem tipos diferentes de destinos, abrangendo de celulares a computadores pessoais, a qualidade do vdeo transmitido deve ser tambm varivel de acordo com as caractersticas de cada destino. Assim, se o vdeo deve ser assistido num celular que tem resoluo mxima de 240x320, no h a necessidade desse ser transmitido em 1080p 4 . Um vdeo numa resoluo muito maior do que a capacidade de exibio do aparelho gera dois problemas. O primeiro a necessidade de redimensionar o vdeo para que caiba na tela, processo que pode ser bastante custoso em termos de processamento. J o segundo o gasto desnecessrio de banda passante, uma vez que, neste caso, um vdeo na resoluo suciente seria menor, signicando menos bytes sendo transferidos. Por outro lado, se o destino for um decodicador de TV por assinatura, como a tela de aparelhos de televiso tem em geral uma resoluo maior que telas de celulares, espera-se que o vdeo transmitido seja em maior resoluo. Por isso, so disponibilizadas e sugeridas diversas opes de streaming para o usurio, cada uma se adequar melhor ao destino em questo.
4
Tambm chamado de full HD. Sua resoluo de 1920x1080 pixels.
35
3.2.2 Busca, feedback e sugestes ao usurio O SASF capaz de disponibilizar centenas de milhares de ttulos de vdeos aos seus usurios. Em meio a um acervo deste tamanho, surge a necessidade de facilitar a vida do usurio para que esse encontre o que deseja. Assim, operaes de busca por ttulo (original e traduzido), atores, diretores, gnero, ano de lanamento ou palavras-chave so requisitos bsicos de um sistema deste porte. Alm da funcionalidade bsica de busca, o SASF sugere lmes ao usurio de acordo com seu histrico de aluguis. Esse mecanismo de sugesto alimentado no s pelos lmes assistidos, mas tambm pela nota dada pelo usurio aps t-lo assistido. Essa nota serve para renar o motor de sugesto e fazer com que as sugestes automticas se tornem mais precisas ao longo do tempo. Outra forma de sugesto a manual, onde um usurio sugere um ou mais lmes a um amigo. J que um membro pode receber sugestes de outros cadastrados, ele deixa de estar isolado dentro do sistema para estar agrupado com amigos de fora do SASF. Isto adiciona aspectos sociais ao sistema, alm de melhorar a preciso das sugestes, uma vez que amigos tero, em potencial, mais informaes sobre o usurio que o motor de sugesto. Isto tambm servir para estimular mais aluguis a m da realizao de sesses de cinema junto aos amigos. Para prover ainda mais informaes que ajudem na escolha de um vdeo, o SASF tambm disponibiliza trailers e crticas sobre os lmes. Os trailers so disponibilizados pelas distribuidoras assim como sua sinopse, fotos de divulgao e documentrios por trs das cmeras, todos disponveis para streaming ou leitura independente da assinatura do usurio. J as crticas podem ser feitas por qualquer um cadastrado no sistema. 3.2.3 Disponibilizao de lmes e administrao do sistema Devemos nos lembrar que os usurios que alugam lmes no so os nicos do sistema. H outros dois tipos de usurios essenciais para que o sistema tenha sucesso, so eles o Administrador e o Distribuidor de Filmes. Observe o diagrama apresentado na Figura 3.2. O primeiro o usurio que representa uma empresa distribuidora de lmes. A viso do sistema para esse tipo de usurio diferente da viso do
36
Figura 3.2. Diagrama de Casos de Uso simplicado do SASF
usurio comum. A empresa ganha dinheiro disponibilizando e incentivando o aluguel de lmes. Dessa maneira, como h o interesse em saber como anda a popularidade de seus vdeos, o SASF prov para a empresa dados sobre aluguis ao longo de intervalos de tempo customizveis. Esses dados contm informaes sobre o perl de cada usurio que alugou o lme (por exemplo, idade declarada ou sexo), mas no contm sua identidade, por motivos de respeito privacidade. Esses dados serviro para a distribuidora poder direcionar a divulgao de seus lmes ou vericar se a campanha de publicidade foi efetiva. Para cada lme disponibilizado pela distribuidora, possvel tambm adicionar sinopses, trailers, fotos de divulgao e documentrios por trs das cmeras para tornar o lme mais atrativo. Toda essa informao extra se torna disponvel a todos os usurios do SASF. J o segundo tipo de usurio essencial do SASF o administrador do sistema. Ele est interessado em manter o SASF funcionando. Sua interao com o sistema consiste em obter informaes de monitorao (por exemplo, quantos servidores esto no ar, quantas requisies por segundo cada um est recebendo no momento, o histrico de falhas de comunicao entre servido-
3.3 Capacidades do SASF
37
res, etc.) e, de acordo com estas informaes, atuar sobre ele. As aes do administrador sobre o SASF englobam: iniciar novos servidores para atender uma demanda crescente ou isol-los para manuteno, habilitar ou desabilitar funcionalidades por excesso de carga ou ns de teste e habilitar ou desabilitar contas de usurios mal-comportados.
3.3 Capacidades do SASF

O desao de desenvolver o SASF no est na implementao de suas funcionalidades, uma vez que o desao de desenvolver um sistema de locadora pequeno e que tambm j existem vrios aplicativos que realizam streaming de vdeos. O desao est no atendimento aos seus atributos de qualidade. Dessa maneira, para passarmos uma noo do tamanho do problema, citaremos alguns nmeros presentes no SASF. 3.3.1 Nmeros de usurios e aspectos de segurana O SASF desenvolvido para atender a 10 milhes de usurios cadastrados, onde cerca de 20% desses usam o sistema a cada dia. Como h diversos tipos de usurios e cada um possui informaes condenciais (por exemplo, o nmero de carto de crdito usado para pagar a assinatura), cada usurio deve ser autenticado para acess-las. A autenticao servir tambm para identicar o tipo de usurio e, assim, autoriz-lo a realizar apenas o conjunto de funes permitidas sua categoria. 3.3.2 Tamanho do inventrio e nmero de operaes por dia A principal funo do sistema executada pelo usurio que aluga lmes, e consiste na colocao de lmes em sua respectiva la de aluguis. O acervo do SASF estimado em cem mil vdeos cadastrados, que esto disponveis em 55 milhes de DVDs. Deste acervo, so realizados dois milhes de aluguis por dia. Isto signica dois milhes de execues por dia do processo de aluguel: (1) relacionar o vdeo a ser enviado ao especco usurio, (2) descobrir de qual ponto distribuidor ser enviada a mdia a partir do endereo do usurio, (3) noticar a responsabilidade de entrega da mdia ao ponto distribuidor responsvel, e (4) realizar o envio pelos correios da mdia em questo.
38
3.3.3 Transmisses simultneas J o streaming de vdeos realizado numa taxa menor que o aluguel, o que no representa uma baixa taxa de execues. So cerca de 150 mil vdeos transmitidos por dia, ou seja, um stream de vdeo sendo iniciado a cada 0.57 segundos caso as transmisses fossem distribudas uniformemente ao longo do dia. Se considerarmos que a transmisso de um vdeo dura em mdia uma hora, isso gera uma carga de pouco mais de seis mil usurios simultneos fazendo streaming. O acervo de vdeos para stream menor que o de mdias convencionais, apenas 20 mil ttulos, mas cada ttulo est disponvel em alguns nveis de resoluo e diversas taxas de amostragem. Os ttulos, inicialmente, esto disponveis em dois nveis de resoluo: Standard Denition (SD) e High Denition (HD), ou 720x480 e 1280x720 pixels respectivamente para vdeos em widescreen (16:9). importante notar que widescreen no o nico aspecto de vdeo presente no sistema, uma vez que outros podem estar presentes, como por exemplo, o aspecto Cinemascope (2.35:1). Dessa maneira, o fator determinante para qualidade do vdeo sua taxa de amostragem. Inicialmente, o SASF prov trs taxas de amostragem para vdeos em SD e duas para vdeos em HD. Assim, o usurio receber o vdeo com aquela que melhor se adequar sua conexo de internet. A tabela 3.1 mostra o tamanho esperado para vdeos de duas horas de durao em cada taxa de amostragem disponvel. A partir dessa tabela, podemos tambm ter uma noo do espao gasto no armazenamento de mdias.
Tabela 3.1. Tamanhos e amostragens disponveis
Nveis de denio SD HD Amostragem (em kbps) 375 500 1000 2600 3800 Tamanho*(em GB**) 0.314 0.419 0.838 2.179 3.185
* **
Considerando um vdeo de 2 horas de durao 1 GB = 1.073.741.824 bytes
3.3.4 Adio de informaes sobre os vdeos Os usurios do SASF tambm podem avaliar e escrever crticas sobre os vdeos que j assistiram. Essa avaliao feita atravs de uma nota dada ao lme. O SASF possui cerca de dois bilhes de notas j registradas, que podem ou
3.4 Resumo
39
no vir acompanhadas de uma crtica escrita sobre o lme. Essas crticas, inicialmente, no possuem limites de tamanho. Vale tambm observar que apenas cerca de 5% da notas so acompanhadas de crticas escritas, mas que totalizam cerca de 100 milhes de textos sobre lmes do acervo do SASF. Note que avaliao e crticas no so as nicas informaes relacionadas a cada vdeo do acervo. Cada vdeo possui ainda fotos de divulgao, trailers, sinopse, lista de usurios que j alugaram e lista de usurios com o lme na la de locao. Essas informaes devem sempre estar disponveis ao usurio para ajud-lo na deciso de alugar um lme. 3.3.5 Tempos de resposta Por m, observamos que o SASF disponibiliza um grande volume de informao, seja para o usurio comum, atravs do streaming, da busca ou do aluguel de lmes, seja para o administrador, atravs da monitorao e ao sobre o estado do sistema. Esse volume de informao aumenta naturalmente o tempo de resposta dessas operaes. Por outro lado, tempos de resposta acima do especicado ou acima da expectativa do usurio contribuem para o fracasso de um sistema. Assim, as diversas operaes providas pelo SASF devem ser realizadas na velocidade da satisfao de cada usurio em questo. No SASF, diferentes classes de usurios tm diferentes operaes sua disposio. Alm disso, essas operaes so bastante diferentes entre classes de usurios. Por exemplo, um administrador pode obter a velocidade mdia da realizao da operao de aluguel executada por dado conjunto de servidores ao longo da ltima semana, enquanto um usurio quer apenas ver as cinco ltimas crticas a determinado lme. Por isso, todas as operaes disponveis no tero o mesmo tempo de resposta, mas tempos diferentes de acordo com o volume de dados que opera, sua criticidade, e o stakeholder envolvido. Isto ser observado ao longo do livro, ao exemplicarmos mais aspectos do SASF.
3.4 Resumo
Como podemos observar atravs de suas capacidades, o SASF se mostra um estudo de caso signicativo devido relativa complexidade de seus requisitos. Esses requisitos dicultam ou mesmo impossibilitam seu desenvolvimento se
40
no houver um mnimo de planejamento para atend-los ou ainda caso no seja adotada uma abordagem, digamos, arquitetural para atend-los. Nos prximos captulos estudaremos os aspectos fundamentais para que possamos desenvolver um sistema como o SASF e, passo a passo, mostraremos como esses aspectos se aplicam ao estudo de caso em questo.
4 Fundamentos de Arquitetura de Software
No captulo introdutrio, mencionamos que o Design de Software pode ser dividido em duas atividades: design de alto-nvel ou arquitetural e design detalhado e que ambas as atividades tm um papel importante no ciclo de desenvolvimento do software. Como o objeto de estudo deste livro Arquitetura de Software, voltamo-nos agora para a primeira atividade em questo. Este captulo tem como objetivo expor o leitor aos fundamentos de Arquitetura de Software ou, em outras palavras, fazer com que seja capaz de: Reconhecer, entender, e comparar as diferentes denies existentes do termo arquitetura de software Relacionar as diferentes denies de arquitetura de software com o padro ISO/IEEE 1471 Identicar as caractersticas e benefcios proporcionados por uma boa arquitetura Avaliar os benefcios de explicitamente projetar a arquitetura durante o desenvolvimento do software
4.1 Motivao para desenvolver melhores sistemas

Desenvolver software no uma tarefa fcil. por esse motivo que muitos projetos de software fracassam durante seu desenvolvimento ou ao obter seus resultados. Entre esses maus resultados, encontramos os que custaram muito acima do oramento, os incompletos e os que no solucionam os problemas como deveriam resolver.
42
No fcil alcanar um bom produto de software devido complexidade envolvida em seu processo de desenvolvimento. Alm de lidar com a complexidade inerente ao problema, devemos tambm nos preocupar em como o software resolve esse problema. Assim, o software deve, alm de resolver o problema, resolv-lo da forma esperada. Ou em outras palavras: Espera-se que, alm de funo, o produto de software possua os atributos de qualidade esperados. Exemplo 4.1. Considere um programa que realize as quatro operaes: soma, subtrao, multiplicao e diviso. Se o tempo de resposta de suas operaes for sempre maior do que o tempo que seu usurio est disposto a esperar, esse programa no ter utilidade mesmo que sempre retorne o resultado correto. Podemos observar no Exemplo 4.1 que o programa funciona corretamente, mas, por no exibir o desempenho esperado, acaba sendo abandonado. Por outro lado, consertar esse programa para que seja til relativamente fcil. Por exemplo, se o programa no multiplica rpido o bastante, basta apenas reimplementar a funo de multiplicao para que tenha um melhor desempenho. Exemplo 4.2. Considere agora o SASF, j apresentado no Captulo 3. Considere tambm que ele se mostra incapaz de responder em menos de dois segundos s operaes de aluguel de lmes. Uma vez que os usurios no esto dispostos a esperar esse tempo pela principal operao do sistema, isso resultar numa m experincia de uso, que ser motivo para que seus usurios deixem de us-lo e tambm deixem de pagar pelo servio. Acontece que diminuir o tempo de resposta de uma funcionalidade no SASF, dado o tamanho do sistema, pode no ser to simples quanto diminuir o tempo de execuo de uma funo matemtica. O alto tempo de resposta de um servio no SASF pode ser funo de uma ou mais decises tomadas ao longo do desenvolvimento que resultaram na sua estrutura e organizao interna. Essa estrutura e organizao o que chamamos de arquitetura. Como o atendimento aos atributos de qualidade do software se deve em grande parte sua arquitetura, surge a necessidade de estud-la. E, por m, atravs do estudo das caractersticas e tcnicas de projeto de arquitetura que poderemos projetar e desenvolver melhores produtos de software.
4.3 Denio de Arquitetura de Software por Perry e Wolf
43
4.2 O que Arquitetura de Software

Desde sua primeira meno em um relatrio tcnico da dcada de 1970 intitulado Software Engineering Tecnhiques [18], diversos autores se propuseram a denir o termo arquitetura de software. Por esse motivo, ao invs de criarmos nossa prpria denio do termo, faremos uso de quatro denies existentes a m de ressaltar suas diferentes caractersticas. As trs primeiras que usaremos so as denies de facto do termo. Elas foram formuladas por autores que se destacam na rea desde sua introduo e so usadas atualmente pela grande maioria dos professores, alunos e praticantes da rea. Por outro lado, tambm mostraremos a denio de jure de arquitetura de software. Ela parte do padro ISO/IEEE 1471-2000 [39] e teve sua criao motivada justamente para fazer com que estudantes, professores e praticantes de arquitetura de software concordem sobre o termo.
4.3 Denio de Arquitetura de Software por Perry e Wolf

Perry e Wolf introduziram sua denio para arquitetura de software em seu artigo seminal Foundations for the Study of Software Architecture [68]. A denio que eles propem consiste na Frmula 4.1 e na explicao de seus termos: Arquitetura = {Elementos, Organizao, Decises} (4.1)
De acordo com essa denio, a arquitetura de software um conjunto de elementos arquiteturais que possuem alguma organizao. Os elementos e sua organizao so denidos por decises tomadas para satisfazer objetivos e restries. So destacados trs tipos de elementos arquiteturais: Elementos de processamento : so elementos que usam ou transformam informao; Elementos de dados : so elementos que contm a informao a ser usada e transformada; e Elementos de conexo : so elementos que ligam elementos de qualquer tipo entre si.
44
J a organizao dita as relaes entre os elementos arquiteturais. Essas relaes possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relaes devem ser ponderadas de modo a indicar sua importncia no processo de seleo de alternativas. Exemplo 4.3. Um elemento de dados muito presente no SASF e em sistemas de informao em geral o banco de dados. Ele o responsvel por guardar e recuperar dados no sistema. No SASF, inicialmente, esto presentes trs tipos de dados: 1. Informao textual: informaes cadastrais dos usurios e informaes textuais sobre os lmes; 2. Imagens: imagens que compem a identidade visual do sistema, foto do usurio presente em seu perl e imagens de divulgao dos lmes; 3. Vdeos: lmes completos, trailers e documentrios por trs das cmeras disponveis para streaming. Por isso, consideramos um elemento de dados para cada tipo. Assim, temos o banco de dados responsvel por informaes textuais, o banco de dados responsvel por imagens e o banco de dados responsvel por vdeos. Essa separao de responsabilidades permite que a implementao de cada elemento de dados disponha de servios diferenciados ou mesmo tire proveito da natureza de seus dados para atender a algum atributo de qualidade (desempenho, escalabilidade, etc.). Dessa maneira, o elemento responsvel por texto pode ser otimizado para busca por palavras-chave, enquanto o responsvel por vdeos pode ser otimizado para recuperar grandes massas de dados a cada requisio. Por outro lado, tambm faz sentido dividir logicamente os elementos de dados em: elemento de dados de usurios e de dados de lmes. Vale notar que essa diviso ortogonal diviso em elementos de texto, imagens e vdeos e, portanto, o elemento de dados de usurios pode ser composto por um elemento de dados textuais e outro elemento de dados de imagens, da mesma maneira que o elemento de dados de lmes pode conter o elemento de dados textuais, de imagens e de vdeos. Como exemplo de elemento de processamento, citamos a lgica de negcio do SASF. Ela contm as regras de negcio que compem o SASF. Note que podemos ainda dividir esse elemento de processamento em elementos mais especializados: o elemento de processamento responsvel por criar, editar, recu-
4.4 Arquitetura de Software por Garlan e Shaw
45
perar e remover usurios, o responsvel por criar, editar, recuperar e remover informaes de lmes, o responsvel pelo aluguel de lmes e o responsvel por controlar a sesso de streaming, entre outros. Essa diviso, assim como a diviso dos elementos de dados, pode ser feita em prol do atendimento aos atributos de qualidade1 . No entanto, um elemento no capaz de criar, editar, recuperar ou remover usurios sem se comunicar com os dados dos usurios. Da mesma maneira, o elemento responsvel por manipular as informaes dos lmes deve se comunicar com os elementos que guardam os dados dos lmes. Ou ainda, para controlar a sesso de streaming, o responsvel deve obter o lme do elemento de dados que contm os lmes completos. Essa comunicao feita pelos diversos elementos de conexo do SASF. Entre eles, podemos citar: o driver JDBC2 , que permite a comunicao com o banco de dados responsvel pelos usurios; o protocolo FTP, para transferncia de vdeos; o protocolo HTTP, para transferncias a partir do banco de imagens; ou o REST3 , que uma especializao do HTTP e usado para comunicao entre elementos de processamento. A Figura 4.1 ilustra alguns elementos que formam a arquitetura do SASF.
4.4 Arquitetura de Software por Garlan e Shaw

Alm de terem uma viso mais concreta sobre arquitetura que Perry e Wolf, Garlan e Shaw so mais explcitos quando mencionam o propsito de se aplicar conhecimentos de arquitetura num sistema de software. Para eles, arquitetura de software se torna necessria quando o tamanho e a complexidade dos sistemas de software crescem. Assim, o problema de se construir sistemas vai alm da escolha dos algoritmos e estruturas de dados certos. Esse problema envolver tambm decises sobre as estruturas que formaro o sistema, a estrutura global de controle que ser usada, protocolos de comunicao, sincronizao e acesso a dados, atribuio de funcionalidade a elementos do sistema, ou ainda sobre distribuio fsica dos elementos do sistema. Alm disso, o problema envolver decises que impactaro no comportamento do sistema em termos de escala e desempenho, entre outros atributos de qualidade [34].
1 2 3
Trataremos melhor desse assunto no Captulo 6. Java Database Connectivity. http://java.sun.com/javase/technologies/database/ REpresentational State Transfer [30]
46
Figura 4.1. Alguns elementos de processamento, de dados e de conexo do SASF
A viso sobre arquitetura de software de Garlan e Shaw se torna importante por conter trs aspectos. O primeiro por eles serem explcitos em quando devemos aplicar conhecimentos de arquitetura de software quando lidamos com grandes sistemas. O segundo por serem claros na separao de tarefas entre design detalhado e design arquitetural o primeiro se preocupa com algoritmos e estruturas de dados, enquanto o segundo se preocupa com os elementos e organizao do sistema como um todo, sendo em relao estrutura do sistema, controle, comunicao, ou implantao. E, por m, por
4.5 Arquitetura de Software por Bass et al
47
eles citarem que o processo de design da arquitetura precisa se preocupar com atributos de qualidade do sistema alcanar escalabilidade ou desempenho, por exemplo. Exemplo 4.4. A arquitetura de um sistema operacional, para atingir atributos de desempenho e portabilidade, deve se preocupar com diversos aspectos que comporo o sistema. claro que alguns algoritmos sero tambm responsveis pelo desempenho do S.O. em questo, como o responsvel pela ordenao por prioridade dos processos em execuo ou o de alocao de memria para um novo processo; mas a organizao do sistema em camadas de abstrao (abstrao de hardware, sistema de arquivos e drivers, gerncia de processos, API do sistema, bibliotecas e aplicaes), a comunicao entre elas (uma camada s pode se comunicar com a camada seguinte, ou aplicaes e bibliotecas s podem se comunicar com a API do sistema, etc.) e a sincronizao (um aplicativo sugere o arquivamento de dados, mas o sistema de arquivo decidir quando isso ser feito) tambm impactaro no seu desempenho. Note que essa organizao tambm tem impacto na portabilidade: quanto menos acoplado o resto das camadas for da camada de abstrao de hardware, mais fcil ser de realizar mudanas para que o sistema operacional esteja disponvel para uma nova plataforma de hardware idealmente, s havendo que se reimplementar essa camada.

Como veremos a seguir, a denio de Bass et al bastante similar encontrada no padro ISO/IEEE 1471-2000. No entanto, sua especicidade sobre quais propriedades dos elementos arquiteturais devem ser consideradas a faz ser mencionada: A arquitetura de um programa ou de sistemas computacionais a estrutura ou estruturas do sistema, a qual composta de elementos de software, as propriedades externamente visveis desses elementos, e os relacionamentos entre eles. [6] Como j observado por Gorton [35], essa denio explcita quanto ao papel da abstrao na arquitetura (quando fala de propriedades externamente
48
visveis), e tambm quanto ao papel das mltiplas vises arquiteturais (estruturas do sistema). Devemos tambm mencionar o uso do termo elementos de software como as peas fundamentais da arquitetura. Na edio anterior dessa denio [5], seus autores usavam componentes de software ao invs de elementos de software. Essa mudana foi feita para deixar a denio mais geral, principalmente pelo termo componente de software ter um sentido especco na rea de Engenharia de Software baseada em Componentes. Exemplo 4.5. Podemos observar a arquitetura do SASF atravs de uma viso de partes funcionais (Fig. 4.2): 1. mdulo responsvel pelo cadastro de usurios, 2. mdulo responsvel pelo cadastro de lmes, 3. mdulo responsvel pelo aluguel de lmes, 4. mdulo responsvel pela transmisso de lmes, 5. mdulo responsvel pela sugesto de lmes, etc. Esses mdulos proveem servios e informaes a outras partes do sistema: por exemplo, uma operao de aluguel ou de transmisso de lmes deve atualizar o histrico presente na conta do usurio. Isso ocorre porque o mdulo de sugesto usar periodicamente esse histrico a m de gerar listas de lmes de acordo com as preferncias do usurio.
Figura 4.2. Mdulos funcionais do SASF
Mas essa no a nica maneira de observarmos o sistema. Podemos tambm ver o sistema como um conjunto de processos executando e se comuni-
49
cando em mquinas diferentes, como observado na Figura 4.3. O navegador do usurio, que pode ser considerado parte do sistema e que est executando em uma mquina, se comunica usando o protocolo HTTPS com um servidor de aplicaes, que est executando em outra mquina e que contm parte da lgica do negcio (e os mdulos de cadastro, autenticao, e atualizao do usurio, entre outros). O servidor de aplicaes, por sua vez, se comunica de forma diferente com cada um dos sistemas de armazenamento presentes. Ele usa JDBC para obter dados de usurios, FTP para obter vdeos e HTTP para obter imagens. J o motor de sugesto visto como outro processo executando numa mquina diferente do servidor de aplicao. Esse processo, de tempos em tempos, l, processa e atualiza informaes do banco de usurios a m de gerar a lista de lmes sugeridos. Ele tambm usa JDBC para se comunicar com o banco de usurios.
Figura 4.3. Processos presentes no SASF
50
Na viso em que dividimos o sistema em partes funcionais, podemos perceber aspectos do software como a composio entre elementos ou pontos de reuso. J na viso em que dividimos o sistema em processos, podemos observar outros aspectos, como propriedades de comunicao e de interao entre as partes do sistema. Por exemplo, na primeira viso, os cadastros de lmes e de usurios podem compor um mdulo maior responsvel por todos os cadastros. J na segunda viso, percebemos que a comunicao entre o navegador e o servidor de aplicaes sncrona, enquanto a comunicao entre o motor de sugesto e o banco de dados assncrona em relao s aes dos usurios.
4.6 Arquitetura de Software pelo Padro ISO/IEEE 1471-2000

O propsito da criao do padro ISO/IEEE 1471-2000 [39] foi o de ajudar no consenso entre autores, estudantes e prossionais sobre o que e para que serve arquitetura de software. Assim, esse padro no s dene arquitetura de software, mas tambm introduz um arcabouo conceitual para descrio arquitetural. Sua denio de arquitetura de software, a qual ns adotaremos ao longo do livro, a seguinte: Denio 4.1 (Arquitetura de Software). Arquitetura a organizao fundamental de um sistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios que conduzem seu design e evoluo. Podemos perceber que a denio acima consistente com as anteriores por tambm mencionar que arquitetura compreende estrutura (ou elementos ou componentes), relaes, e decises (ou princpios). No entanto, ela vai alm adicionando mais uma preocupao arquitetura: conduzir a evoluo do software. Evoluo de software o fenmeno de mudana que ocorre no software ao longo dos anos e das mltiplas verses, desde seu incio at o completo abandono do sistema. Essa mudana no est s relacionada com a adio e remoo de funcionalidades, mas tambm est relacionada com a manuteno do cdigo ao longo do ciclo de vida do software. Essa manuteno pode melhorar ou deteriorar tanto atributos externos de qualidade do software, os
4.7 Decompondo a denio de Arquitetura de Software
51
quais so percebidos pelos usurios (e.g., desempenho, tolerncia a falhas, disponibilidade), quanto atributos internos de qualidade do software, os quais so percebidos pelos envolvidos no desenvolvimento (e.g., testabilidade, legibilidade, reusabilidade). Uma vez que um dos principais objetivos de se projetar uma arquitetura o de atingir a qualidade desejada pelos interessados no sistema, se torna claro o papel da arquitetura em conduzir a evoluo do software, uma vez que ela conter decises que contribuiro para a preservao da qualidade do sistema durante seu ciclo de vida. Antes de entrarmos em detalhes sobre os diversos aspectos de arquitetura de software, devemos entrar em consenso sobre o termo componente de software. Em Engenharia de Software, componentes tm vrios signicados divergentes. Um signicado, de acordo com o Standard Computer Dictionary [44], que um componente uma das partes que compem o sistema. Dessa maneira, componente pode ser substitudo por mdulo, unidade, ou mesmo elemento de software. esse o signicado de componente usado no padro ISO/IEEE 1471-2000 e que ser usado ao longo deste livro. Por outro lado, um componente tambm pode ter o signicado como o descrito por Kai Qian, em Component-Oriented Programming [3]: um pedao de cdigo autocontido e autoimplantvel com uma funcionalidade bem denida e que pode ser agregado com outros componentes atravs de sua interface. Esse outro signicado estritamente ligado Engenharia de Software baseada em Componentes e no ser usado a no ser que sejamos explcitos sobre ele. O padro ISO/IEEE 1471-2000 tambm dene outros termos fundamentais para o entendimento de arquitetura de software, em especial vises (views). Esse termo ser brevemente descrito na Seo 4.8 e ento detalhado no Captulo 8.

A arquitetura de software mais bem entendida atravs de suas partes. Considerando as denies expostas acima, podemos ressaltar seus dois principais aspectos, que sero os meios para alcanar os atributos de qualidade : elementos e decises arquiteturais. Detalharemos cada aspecto a seguir.
52
4.7.1 Elementos arquiteturais A arquitetura de um sistema deve denir os elementos que formaro o software. Tais elementos denem como o software particionado em pedaos menores e, assim, denem como o software entendido. Elementos arquiteturais so divididos em dois tipos: elementos estticos e elementos dinmicos. Os elementos estticos de um sistema de software denem as partes do sistema e qual sua organizao. Esse tipo de elemento reete o sistema durante o design e constitudo de elementos de software (e.g., mdulos, classes, pacotes, procedimentos, ou ainda servios autocontidos), elementos de dados (e.g., entidades e tabelas de bancos de dados, arquivos de dados, ou classes de dados), e elementos de hardware (e.g., computadores em que o sistema vai executar, ou outros tipos de hardware que o sistema usar: roteadores, cabos, ou impressoras). Elementos estticos no consistem apenas das partes estticas do sistema, mas tambm como eles se relacionam entre si. Associaes, composies, e outros tipos de relaes entre elementos de software, de dados, e de hardware formam o aspecto esttico que compe a arquitetura do sistema. O exemplo a seguir ilustra elementos estticos de um sistema de software. Exemplo 4.6. Voltando ao SASF, observar sua arquitetura sob uma tica esttica expe seus elementos estticos. Em tempo de design, alguns elementos estticos so cada pacote, mdulo ou conjunto de classes responsveis por cada funo do sistema. Alguns desses elementos so os responsveis por: criao, edio, remoo e recuperao de usurios e lmes, aluguel de lmes, autenticao e autorizao dos usurios, entre outros. Por outro lado, elementos dinmicos denem o comportamento do sistema. Esse tipo de elemento reete o sistema durante a execuo e nele esto includos processos, mdulos, protocolos, ou classes que realizam comportamento. Elementos dinmicos tambm descrevem como o sistema reage a estmulos internos e externos, como mostrado no exemplo a seguir. Exemplo 4.7. Ainda na arquitetura do SASF, podemos tambm observar o sistema sob uma tica dinmica. Essa exibe seus elementos dinmicos, a exemplo dos diversos processos executando nas diversas mquinas que compem o sistema. Esses processos pertencem aos servidores de aplicao, aos servios de armazenamento, ou mesmo aos navegadores dos usurios.
53
Elementos Arquiteturais e Atributos do Sistema Note que quando examinamos os elementos arquiteturais de um sistema, tanto os estticos quanto os dinmicos, devemos tambm prestar ateno nas relaes que os ligam. Essas relaes so importantes, pois especicam a comunicao e o controle da informao e do comportamento que formam o sistema. Assim, as relaes denem diversos aspectos do sistema, por exemplo, quais dados do objeto da classe A so visveis pelos objetos da classe B; ou quantas leituras concorrentes so feitas no elemento C; ou ainda como o elemento D autorizado a escrever dados no elemento E. Dessa maneira, essas relaes tm efeito sobre atributos de qualidade do sistema, sejam os percebidos pelos usurios, ou os percebidos pelos desenvolvedores. Os exemplos seguintes mostram casos de como relaes entre elementos arquiteturais afetam atributos de qualidade. Exemplo 4.8. Se dividirmos a arquitetura do SASF em trs camadas (apresentao, lgica de negcio, e persistncia), a camada de persistncia pode ser um recurso compartilhado por diversas instncias da lgica de negcio. Se temos diversas instncias da lgica de negcio, mesmo que algumas saiam do ar, as restantes provero disponibilidade ao sistema, desde que a camada de persistncia (e.g., o banco de dados) no falhe. Alm disso, o compartilhamento do banco de dados pode signicar tambm o acesso concorrente ao mesmo. Assim, quando uma instncia da lgica de negcio lhe faz uma requisio, essa requisio lhe ser respondida mesmo que outras instncias estejam fazendo o mesmo (obviamente, isso s ocorre se alguma instncia da lgica de negcio no esteja realizando alguma requisio que precise de acesso exclusivo aos dados). Exemplo 4.9. A separao do sistema em trs camadas (Figura 4.4) pode tambm facilitar a manuteno. Se, alm de adotar essa diviso, a camada de apresentao apenas se comunicar com a lgica de negcio, mas no com a de persistncia, mudanas na camada de persistncia afetaro apenas a camada de negcio. Portanto, caso seja necessrio mudar o fornecedor da camada de persistncia, a assinatura dos mtodos disponveis, ou mesmo o protocolo de comunicao, apenas a lgica de negcio ser afetada por essas mudanas, uma vez que no existe acoplamento entre a apresentao e a persistncia.
54
Figura 4.4. Ilustrao da diviso de uma arquitetura em trs camadas.
4.7.2 Decises arquiteturais Uma arquitetura no deve ter suas estruturas denidas aleatoriamente, uma vez que so elas que permitem o sucesso relativo aos objetivos do sistema. Dessa maneira, trabalho do arquiteto denir essas estruturas em meio s alternativas de design arquitetural existentes. O arquiteto deve decidir entre as alternativas, particionando o sistema em elementos e relaes que possibilitaro o atendimento aos atributos de qualidade. Essas decises so chamadas decises arquiteturais. Denio 4.2 (deciso arquitetural). Uma escolha entre as alternativas de design arquitetural, que se prope a alcanar um ou mais atributos de qualidade do sistema, por meio de estruturas ou regras que ela envolve ou dene.
Caractersticas As decises arquiteturais tm, basicamente, trs caractersticas que devem ser consideradas: descrio, objetivos e fundamentao. A primeira caracterstica bem clara. simplesmente a descrio do que foi decidido para o sistema, seja a descrio de um elemento, mdulo, classe,
55
ou servio que existir da arquitetura, a descrio da comunicao de um elemento da arquitetura com outro, a descrio da agregao de diversos elementos diferentes da arquitetura para formar um servio, ou a descrio de um princpio ou mais princpios que conduziro a evoluo do sistema. Exemplo 4.10 ((Deciso Arquitetural 001)). A arquitetura do SASF dividida em trs camadas lgicas: apresentao, lgica de negcio e persistncia de dados. A camada de apresentao se comunica apenas com a lgica de negcio e apenas a lgica de negcio de comunica com a camada de persistncia de dados. Toda deciso feita com um ou vrios objetivos. Assim, a segunda caracterstica trata de explicitar qual o objetivo de dada deciso, normalmente, permitindo ou restringido um conjunto de atributos de qualidade do sistema. Vale notar que, para atender aos atributos de qualidade do sistema (que podem ser muitos), uma arquitetura poder possuir dezenas ou mesmo centenas de decises arquiteturais. Exemplo 4.10 ((continuao)). Objetivo : Esta diviso diminui o acoplamento entre os elementos internos da arquitetura, facilitando o desenvolvimento e a manuteno. Por m, uma deciso arquitetural s pode ter sido alcanada em meio a alternativas com algum embasamento ou fundamentao. Ento, cabe ao arquiteto explicitar por que tal deciso foi tomada, seja por ser um padro conhecido na indstria, seja por conhecimento prvio de como satisfazer os objetivos em questo, ou pela atual deciso ter mostrado os melhores resultados em meio a uma avaliao prvia das alternativas. Exemplo 4.10 ((continuao)). Fundamentao: Projetar os elementos internos do sistema de modo que cada um pertena a apenas uma camada lgica ajuda a aumentar a coeso e diminuir o acoplamento. A coeso aumenta, pois cada elemento ser desenvolvido com o objetivo de ser parte da apresentao, da lgica ou da persistncia do sistema. Dessa maneira, cada elemento ter sua responsabilidade bem denida, mesmo que em alto nvel. Como a comunicao entre as camadas pr-denida, a de seus elementos tambm : elementos da camada de apresentao no se comunicaro com elementos da camada de persistncia, por exemplo. Assim, o acoplamento entre elementos
56
internos ser anlogo ao acoplamento entre camadas. Com o baixo acoplamento, o desenvolvimento e a manuteno dos elementos tambm facilitado, seja por possibilitar o desenvolvimento independente, seja por mudanas em um elemento terem menor impacto nos outros. Rastreabilidade Vale notar que decises denem que elementos comporo o sistema. No exemplo anterior, podemos observar que a deciso dene elementos como plug-ins, pontos de extenso, etc. Assim, por relacionarem atributos de qualidade (ou requisitos) a elementos arquiteturais, as decises contidas numa arquitetura facilitam o chamado rastreamento de requisitos. Denio 4.3 (rastreamento de requisitos). o processo/capacidade de ligar requisitos do sistema a estruturas arquiteturais. A possibilidade de se rastrear requisitos na arquitetura uma caracterstica importante porque facilita o entendimento e a manuteno do sistema representado pela arquitetura. O entendimento do sistema facilitado porque uma arquitetura permite que um interessado qualquer navegue pelos elementos que compem o sistema em dois sentidos: tanto do nvel mais abstrato do sistema para seus nveis mais concretos, ou seja, dos requisitos para os elementos arquiteturais, como mdulos, bibliotecas, servios, ou classes; quanto dos nveis concretos da arquitetura para os nveis mais abstratos, ou seja, dos elementos arquiteturais para os requisitos do sistema. Exemplo 4.11. Se observarmos a arquitetura do SASF e procurarmos pelas decises responsveis por facilitar a manuteno do sistema, encontraremos entre elas a deciso do Exemplo 4.10. Essa deciso sugere uma diviso do sistema em camadas lgicas, mas tambm inuencia na diviso em pacotes, servios ou mesmo processos. Assim, a satisfao do requisito de manutenibilidade est diretamente ligada correta diviso das partes do sistema em apresentao, lgica de negcio e persistncia. Da mesma maneira, se partirmos das partes que formam as camadas de apresentao, lgica de negcio e persistncia, observaremos que elas esto ligadas diviso do sistema (e deciso arquitetural) que se prope a atender a requisitos de manutenibilidade.
57
Alm de permitir a navegao, um aspecto que merece ser ressaltado que se os requisitos do sistema forem eventualmente ordenados por importncia para o sucesso do sistema, os elementos arquiteturais tambm possuiro diferentes nveis de importncia. Essa ordenao, ento, signicar diferentes nveis de investimento, seja em tempo ou dinheiro, na construo dos elementos arquiteturais para o sucesso do sistema. Adicionalmente, a manuteno do sistema facilitada de uma forma anloga ao seu entendimento. Se algum requisito atendido insatisfatoriamente, por meio da arquitetura possvel descobrir quais elementos do sistema esto envolvidos na insatisfao desses requisitos. Da mesma maneira, a arquitetura possibilita descobrir quais requisitos sero afetados por um dado elemento arquitetural caso esse sofra uma mudana ou manuteno. Exemplo 4.12. Se uma modicao na camada de apresentao s pode ser feita se a camada de persistncia tambm for modicada, isso pode signicar que a deciso arquitetural do Exemplo 4.10 no est sendo seguida corretamente. Portanto, o requisito de manutenibilidade tambm no est sendo atendido corretamente e essa divergncia da arquitetura deve ser corrigida o quanto antes. Evoluo Devido s suas caractersticas, se torna fcil perceber que o registro das decises arquiteturais na forma de um documento o documento arquitetural agrega valor ao ciclo de vida do software, uma vez que facilita o processo de rastreamento de requisitos. Adicionalmente, se algum tipo de registro histrico das decises arquiteturais existir, o processo de rastreamento pode tambm ser realizado para as diversas verses do sistema, facilitando assim o entendimento da evoluo do mesmo. Alm de descreverem estruturas arquiteturais, as decises tambm descrevem princpios que conduziro a evoluo do sistema. Isso signica que uma deciso no necessariamente descrever mdulos, classes, ou servios, mas tambm poder descrever regras que devero ser seguidas ao longo do desenvolvimento do sistema. A seguir, citamos e exemplicamos alguns tipos de regras a serem descritas pelas decises arquiteturais. Regras para adio de funcionalidade ao sistema.
58
Exemplo 4.13. Uma nova funcionalidade do SASF no poder adicionar uma carga maior que mil requisies por segundo ao banco de dados de usurios, considerando a mdia atual de dez mil usurios simultneos no sistema. Exemplo 4.14. Uma nova funcionalidade de um editor de imagens s ser adicionada implementando o ponto de extenso ProcessImagePlugin. Esse ponto de extenso permite obter a imagem que est aberta no workspace do usurio e seus atributos, alm de permitir a exibio de uma caixa de dilogo que permitir ao usurio entrar com parmetros que serviro para a execuo do plug-in. O retorno dessa nova funcionalidade sempre ser uma imagem (processada ou no). A nova funcionalidade, para ser adicionada, deve conter um arquivo de congurao em texto sem formatao que conter o atributo extension-class que indicar o caminho para a classe da nova funcionalidade que implementa ProcessImagePlugin. Exemplo 4.15. Uma nova funcionalidade do sistema de edio de texto no poder modicar a GUI de forma que adicione mais do que um boto na rea de trabalho em sua congurao padro. Regras para remoo ou desativao de funcionalidades, seja durante o desenvolvimento, implantao, ou execuo do sistema. Exemplo 4.16. No SASF, a remoo de um servio do mdulo responsvel pelo streaming para outros dispositivos ser feita em duas etapas. Na primeira etapa, o servio ser marcado como deprecated, retornando assim, alm da resposta padro, uma ag avisando que na prxima verso ele ser descontinuado. Ser ainda disponibilizada uma soluo que contorne a ausncia desse servio (servios alternativos, por exemplo). Na segunda etapa, que dever acontecer no mnimo 1 ms depois da primeira etapa, o servio ser desativado, retornando uma mensagem padro de erro avisando que o servio deixou de existir. Exemplo 4.17. Caso o consumo de recursos computacionais do SASF ultrapasse 80% do total, alguns de seus servios podem ser completamente ou parcialmente desativados. Um servio que pode ser desativado temporariamente sem que os usurios percebam o motor de sugesto de lmes. Como cada usurio est acostumado a ter sua lista de sugestes atualizada
59
apenas de tempos em tempos, mas no tem certeza qual o real intervalo entre cada atualizao, se dada atualizao demorar alguns minutos ou horas a mais para acontecer, dicilmente o atraso ser notado. Em casos extremos, devido ao seu grande consumo de recursos, o servio de streaming de vdeo tambm pode ser desativado. No entanto, essa deciso deve tambm levar em conta o alto grau de insatisfao de usurios que causar e que, fatalmente, poder ser convertida em perda de faturamento. Uma alternativa desativar a transmisso de vdeo para apenas algumas opes de resoluo. Assim, o grau de insatisfao ser menor, uma vez que apenas uma parte dos usurios no ser atendida pelo servio de streaming. Regras para modicao ou manuteno de funcionalidades. Exemplo 4.18. No haver modicao do Web Service que realiza busca e aluguel de lmes no SASF que disponibilizado para uso por servios externos. Se for realmente necessria a modicao, dois Web Services caro disponveis: o antigo, completamente suportado, e o novo, que passar a ser adotado por novos sistemas a partir da data de seu lanamento. O antigo s ser desativado depois da adoo do novo servio ser feita por todos os servios externos. Regras de atendimento a atributos de qualidade. Exemplo 4.19. No Exemplo 4.17, a disponibilidade de parte das funcionalidades, i.e., construo da lista de sugestes de lmes ou transmisso de vdeos, mais importante do que a indisponibilidade de todas as funes: caso o uso dos recursos computacionais alcance 100%, usurios comearo a no ser atendidos de forma descontrolada. Assim, prefere-se que uma menor parte dos usurios no seja atendida, apenas os que desejam assistir a lmes em alta denio, do que a maior parte, que so os que desejam alugar lmes ou assisti-los em denio padro. Exemplo 4.20. A disponibilizao de uma nova funcionalidade no SASF ser feita em etapas para 10%, 25%, 50%, 100% desses usurios. Dessa maneira, ser possvel avaliar o comportamento da nova funo no sistema sob carga real. Alm disso, a desativao da funcionalidade poder ser feita atravs de uma ag de controle, permitindo o retorno s funcionalidades anteriores do sistema em caso de sobrecarga dos recursos por parte da nova funcionalidade.
60
Exemplo 4.21. Antes da implantao de uma nova verso de um servio de infraestrutura, digamos, um novo banco de dados, a carga gerada pelos usurios da verso antiga ser espelhada para a nova verso. Assim, ser possvel avaliar seu comportamento com uma carga real e, portanto, saber o que esperar quando o novo banco de dados substituir a verso em produo. No Captulo 8, Documentao da Arquitetura, voltaremos s decises arquiteturais, onde aprenderemos a categoriz-las e document-las. 4.7.3 Atributos de qualidade Uma das principais preocupaes da arquitetura o atendimento aos atributos de qualidade do sistema. Atributos de qualidade, como j introduzidos no captulo anterior, so a maneira como o sistema executar suas funcionalidades. Esses atributos so impostos pelos diversos interessados no sistema e podem ser classicados em trs tipos: atributos do produto, atributos organizacionais, e atributos externos. Atributos de qualidade do produto so aqueles que ditam como o sistema vai se comportar. Exemplos clssicos desse tipo de atributo de qualidade so escalabilidade, desempenho, disponibilidade, nvel de entendimento ou mesmo portabilidade. Podemos observar requisitos de escalabilidade no Exemplo 4.22 e requisitos de portabilidade no Exemplo 4.23. Exemplo 4.22. Sistemas de redes sociais costumam ter uma grande massa de usurios. Como, a partir do lanamento de um sistema desse tipo, sua massa de usurios cresce bastante, desejvel que o crescimento do consumo de recursos em relao ao crescimento do nmero de usurios no seja muito acentuado de forma que a escala seja vivel para a gerncia do sistema. Para atender esse requisito, a arquitetura deve ser muito bem pensada em termos de consumo de recursos por usurio, tirando proveito de diversas tcnicas como caching, processamento assncrono, replicao, entre outras. Exemplo 4.23. Um requisito desejvel em um jogo de videogame que ele esteja disponvel para diversas plataformas de entretenimento. Como diferentes plataformas tm diferentes especicaes ou ainda usam diferentes tipos de hardware, atingir a portabilidade pode no ser trivial. Entre as tcnicas de portabilidade, a mais usada acaba sendo a abstrao dos aspectos especcos
61
plataforma principalmente o hardware, mais especicamente primitivas de desenho em tela ou armazenamento em disco da lgica do jogo. Assim, toda ou boa parte da camada lgica reusada, enquanto as camadas de nveis mais baixos de abstrao so portadas para as diferentes plataformas. J atributos de qualidade organizacionais, por outro lado, so consequncia de polticas ou procedimentos organizacionais. Em outras palavras, o sistema deve respeitar padres ou regras impostas por uma ou mais organizaes envolvidas para atender a esses requisitos. Exemplo 4.24. Se um sistema que servir de infraestrutura ser produzido para uma organizao ou empresa que j possui diversos sistemas que implementam o padro Web Service Distributed Management (Gerncia Distribuda de Web Services ), a adoo desse padro na arquitetura do novo sistema um requisito a ser atendido, por ser imposto pela organizao em questo. A adoo desse padro implica na disponibilizao via Web Service de servios de ativao, consulta e desativao do sistema ou parte dele, que ter impacto na arquitetura do sistema como um todo. Por m, restam os chamados atributos de qualidade externos, que no so impostos pelo processo de desenvolvimento nem pelo projeto do sistema. Neles se encaixam leis impostas sobre software ou requisitos de interoperabilidade entre sistemas. Exemplo 4.25. Para o SASF atrair usurios de outros sistemas (p. ex., redes sociais), percebeu-se que ele deve ser capaz de agregar o perl do usurio existente nos outros sistemas. Esse tipo de agregao (que permitiria no s a visualizao dos pers compartilhados entre os diversos servios, mas tambm sua edio), impactar profundamente na arquitetura do sistema, uma vez que ser necessrio organizar dados locais e dados compartilhados por terceiros, alm de manter todos os dados sincronizados ao longo do tempo e das eventuais modicaes. Medindo atributos de qualidade importante notar que para se denir o sucesso do software em relao aos atributos de qualidade, precisamos medir o quanto o sistema satisfaz a esses atributos. Em primeiro momento, essa medio de sucesso parece simples:
62
basta considerar o valor esperado do atributo de qualidade, digamos, o sistema deve estar disponvel 99,999% do tempo; medir se ele atinge os valores esperados, num perodo de 1 ano, o sistema esteve parado por 1 hora; e, por m, atestar seu sucesso ou fracasso: 1 hora equivale a 0,0114% e, portanto, o sistema no atendeu ao requisito de disponibilidade. No entanto, no fcil estabelecer mtricas quantitativas para atributos de qualidade como testabilidade, usabilidade, ou manutenibilidade so bem mais difceis de estabelecer mtricas quantitativas e, portanto, no fcil atestar o sucesso em relao a esses atributos. Relacionando atributos de qualidade Alm de serem difceis de medir, atributos de qualidade se relacionam entre si de forma que um pode permitir, ajudar ou mesmo dicultar o atendimento de outros. Essas relaes entre atributos acontecem mesmo que eles sejam de tipos diferentes. No Exemplo 4.26, notamos que o atributo de qualidade desempenho est afetando os nveis de testabilidade e entendimento do sistema. Exemplo 4.26. Uma forma de aumentar o desempenho do sistema diminuir os nveis de indireo usados na comunicao entre dois elementos quaisquer no SASF. Um caso simples seria fazer com que algumas chamadas presentes na camada de apresentao usassem diretamente a camada de persistncia, sem usar a lgica de negcio. Essa medida tornaria as chamadas da apresentao mais rpidas, uma vez que menos chamadas remotas seriam executadas. No entanto, quando diminumos as camadas de abstrao entre dois elementos inicialmente distintos, aumentamos o acoplamento entre eles e, portanto, dicultamos seu entendimento ou mesmo sua testabilidade. J no exemplo a seguir, o atributo de segurana afeta dois atributos distintos: o desempenho e a usabilidade do sistema. Exemplo 4.27. Uma forma de aumentar a segurana de um sistema operacional requerer autorizao do usurio para a realizao de certas operaes. No entanto, o processo de vericao do usurio (alm de todos os elementos e abstraes do sistema relacionados segurana: unidade certicadora, unidade vericadora, listas de controle de acesso, entre outros.) deteriorar o desempenho da aplicao, dado que consumir recursos que poderiam ser
63
destinados operao em si - no a um aspecto dito no-funcional dela. Alm disso, o sistema vai car menos usvel, uma vez que pedir uma vericao, seja senha, impresso digital, ou certicado, para cada operao sensvel a ser executada. O principal motivo que faz com que atributos de qualidade conitem por eles serem impostos por mais de um interessado no software. Assim, como preocupaes de diferentes interessados podem conitar, os atributos de qualidade tambm conitaro. Assim, cabe arquitetura resolver, ponderar, ou ao menos mediar esses conitos, considerando assim os diversos trade-os envolvidos para se alcanar os objetivos do software. O exemplo seguinte mostra atributos de desempenho e portabilidade conitando. Exemplo 4.28. Um cliente de um jogo para celular requisitou que o jogo tivesse um bom desempenho nos diversos aparelhos disponveis no mercado. No entanto, o gerente de projeto sugere que o tempo gasto para portar o software de um aparelho para outro seja mnimo, uma vez que o prazo do projeto em questo curto. Podemos ento observar dois requisitos conitantes: desempenho e portabilidade. Esse conito ocorre porque as tcnicas para alcanar ambos os requisitos so divergentes. Para alcanar portabilidade, normalmente necessrio o uso de diversas camadas de abstrao, principalmente de hardware. No entanto, a adio dessas camadas de abstrao signica uma perda em desempenho, uma vez que aumentar o nmero de chamadas necessrias para se realizar qualquer operao. E isso se torna ainda mais signicativo no caso dos aparelhos celulares, que podem ser limitados em termos de recursos computacionais como processador ou memria. Assim, a arquitetura do sistema ter que ponderar entre as tcnicas disponveis de modo que atenda em parte cada requisito e, assim, ambos os interessados quem satisfeitos. Dois outros atributos de qualidade que normalmente conitam so os atributos usabilidade e segurana, como veremos no exemplo a seguir. Nesse caso, ambos os atributos foram requisitados pelo mesmo interessado, o usurio, e, mesmo assim, se tornaram conitantes. Exemplo 4.29. Quando usando um sistema operacional, um mesmo usurio procura atributos de segurana e usabilidade para suas operaes. Para segurana, ele deseja que suas operaes no sistema ou seus resultados no sejam
64
afetados por aes de outros usurios. Esse atributo, que na arquitetura implicar em solues de autenticao, vericao, listas de permisses, etc., impor que as tarefas realizadas por qualquer usurio eventualmente tero sua autenticidade e permisso vericadas. Essa interrupo para realizar as devidas autorizaes deteriora o atendimento do atributo de usabilidade, uma vez que o usurio ter suas atividades interrompidas por algo que no gera resultado para ele. Veremos mais sobre atributos de qualidade de software, suas relaes, como alcan-los, e seus interessados no Captulo6.
4.8 Vises da Arquitetura

Como consequncia da existncia dos diversos interessados nos objetivos alcanados pelo software, a arquitetura tambm possuir diversos interessados. No entanto, uma vez que os interessados no sistema tm diferentes preocupaes e nveis de conhecimento, a arquitetura no deve ser exposta da mesma maneira para interessados diferentes. Para resolver esse problema, surge o conceito de vises arquiteturais. Exemplo 4.30. Considerando a arquitetura do SASF, vejamos as preocupaes de dois interessados diferentes: o implementador e o responsvel pela disponibilidade do sistema em produo. O implementador est preocupado com mdulos, classes e algoritmos que ele e seu time tero que construir, como e com quais subsistemas esses mdulos iro se comunicar ou ainda quais restries de comunicao foram impostas em seu design. J o responsvel pela disponibilidade est preocupado em como o SASF est distribudo entre as mquinas, que funcionalidades sero afetadas caso um conjunto especco de mquinas deixe de funcionar, ou como ser possvel realizar a troca de um servidor sem afetar o tempo de incio de uma transmisso de vdeo. Podemos observar que h preocupaes bem diferentes entre os dois interessados e assim perceber que dimenses bem diferentes da arquitetura so necessrias para satisfaz-los. Para o primeiro, a arquitetura deve mostrar que mdulos lgicos (pacotes, classes, bibliotecas) compem o sistema, alm das relaes de comunicao e restrio entre eles. J para o segundo, a arquitetura deve mostrar como o sistema est dividido sicamente, quais partes do
4.9 O Documento de Arquitetura
65
sistema esto executando em quais computadores, quais os links fsicos entre esses computadores, etc. Uma viso arquitetural uma representao da informao (ou parte dela) contida na arquitetura de forma que se adque s necessidades de um ou mais interessados. Ela facilita o entendimento da arquitetura por parte do interessado, uma vez que vai ltrar e formatar a informao de acordo com as necessidades e preocupaes do interessado em questo. Denio 4.4 (viso arquitetural). a representao do sistema ou de parte dele da perspectiva de um conjunto de interesses relacionados. No podemos esquecer que o prprio arquiteto tambm pode tirar proveito desse conceito durante o processo de design da arquitetura. Quando um arquiteto faz design, ele usa o conceito de vises arquiteturais para assim enderear as diferentes preocupaes do sistema por vez. Dessa maneira, ele divide o problema de design em problemas menores e, consequentemente, menos complexos: ele enderea cada atributo de qualidade cada aspecto do sistema que sero alcanados por essa arquitetura. Atacando uma viso por vez, o arquiteto pode, por exemplo: primeiro denir as parties lgicas, ou seja, os mdulos funcionais que comporo o sistema e assim considerar uma viso lgica do sistema; denir as parties dinmicas do sistema, ou seja, quais processos, threads e protocolos estaro presentes no sistema considerar uma viso de dinmica; denir as parties do ponto de vista de implementao, ou seja, que classes, pacotes e bibliotecas comporo o sistema considerar uma viso de desenvolvimento; e, por m, denir onde as partes dinmicas executaro, ou seja, onde e em quais mquinas os diversos executveis do software estaro implantados, alm de como eles vo se comunicar considerar uma viso de implantao do sistema.

Considerando o que mencionamos at agora sobre arquitetura de software, percebemos que ela prov diversos benefcios: proporciona atendimento de atributos de qualidade, ajuda na comunicao entre os interessados no sistema e guia a evoluo do sistema. No entanto, at agora, s falamos da arquitetura como algo abstrato. Ou seja, apenas falamos dela como uma propriedade imposta ou emergente de um sistema, mas no falamos em como
66
document-la, nem fomos especcos quanto aos benefcios proporcionados por sua documentao. 4.9.1 Benefcios Um documento de arquitetura no nada mais que um documento que descreve a arquitetura do sistema e, portanto, descreve elementos, relaes, e decises arquiteturais do sistema em questo. Assim, os benefcios de se documentar a arquitetura se tornam anlogos aos benefcios proporcionados pela prpria arquitetura. No entanto, pelo documento de arquitetura ser um artefato concreto, ele poder ser reproduzido, reusado, comunicado e analisado contra o cdigo gerado a partir da arquitetura em questo. Em resumo, a documentao da arquitetura proporcionar os seguintes benefcios: Ajudar na introduo de novos membros ao time de desenvolvimento do sistema, uma vez que um documento que abstrai o sistema a diferentes vises que representam diferentes preocupaes; Exemplo 4.31. Um novo desenvolvedor acabou de ser contratado e passou a integrar o time de desenvolvimento de um sistema que j soma 250 mil linhas de cdigo. Para esse desenvolvedor se familiarizar com o sistema, no uma boa ideia para ele mergulhar no cdigo de cabea, mas entender por partes como as coisas funcionam. Esses diversos nveis de abstrao at chegar ao cdigo propriamente dito devem estar disponveis na arquitetura do sistema, que se mostrar um bom ponto de partida para o entendimento do sistema. Servir de ponte para a comunicao entre os diversos interessados do sistema. Uma vez que a arquitetura projetada para satisfazer diversos interessados, sua documentao tambm o ser. O documento de arquitetura servir de arcabouo conceitual para comunicao entre diferentes interessados no sistema, uma vez que dene seus elementos e relaes que o compem. Exemplo 4.32. Usando a arquitetura para mapear custos s funcionalidades que o sistema prover, o gerente pode justicar ao nanciador do projeto a necessidade de se adquirir uma licena para um banco de dados
67
especco. Ou ainda citar quais as consequncias caso essa licena no seja adquirida: a funcionalidade provida pelo banco dever ser ento implementada pelo time de desenvolvimento, que precisar de dois meses para tanto. Essa possibilidade de navegar pelo sistema e pelas diversas vises, seja a de gerente, seja a de nanciador, ou de desenvolvedor, facilitada pelo documento de arquitetura. Servir como modelo do sistema para a anlise. Uma vez que uma representao manipulvel do sistema, a documentao poder ser analisada, desde que contenha informao suciente para tanto. Exemplo 4.33. A arquitetura do SASF, dividido em trs camadas (apresentao, lgica de negcio e persistncia), descreve que cada camada estar executando em mquinas diferentes. certo que a descrio de cada camada possui informaes de quantas mquinas sero necessrias para determinada carga de usurios, como mquinas da mesma camada se comunicaro e tambm como elas se comunicaro com mquinas de diferentes camadas. Assim, com essas informaes, possvel algum tipo de anlise e estimativa do custo do sistema em produo (e.g., nmero de CPUs por hora, banda passante entre as mquinas, ou banda passante disponvel para os usurios), inclusive com base no crescimento do nmero de usurios, mesmo que o sistema ainda no tenha sido construdo. Dicultar uma especicao imprecisa. Quando o arquiteto projeta a arquitetura, mas no a materializa em um documento, pode haver pontos de discordncia que eventualmente no sero avaliados por, simplesmente, no estarem explcitos. Exemplo 4.34. Num sistema de controle de voo, onde vidas esto em risco, o documento da arquitetura tambm um contrato. Ele avaliado por cada interessado em questo, que deve consentir com a forma de como sero realizadas as funes do sistema e como sero medidos seus atributos de qualidade de forma a garantir o sucesso do sistema antes mesmo que esse seja construdo. 4.9.2 Diculdades No entanto, documentar a arquitetura to ou mais difcil que cri-la. Os principais motivos so trs: o documento reete a complexidade da arquitetura, que geralmente alta; o documento reete o tamanho da arquitetura,
68
que o torna custoso para construir e ser lido; e difcil manter o documento consistente com o sistema que ele descreve, justamente por causa do tamanho e da complexidade. A complexidade do documento surge principalmente da necessidade de mostrar de diferentes maneiras os diferentes aspectos da arquitetura, ou seja, da necessidade de mostrar as diferentes vises da arquitetura. Cada viso possui uma forma de melhor ser representada e tambm deve estar consistente com as outras vises. Exemplo 4.35. Na documentao da arquitetura do SASF podemos observar, entre outras, duas vises diferentes: uma viso que mostra aspectos dinmicos e outra que mostra o sistema estaticamente. A viso esttica mostra os principais mdulos funcionais do software e, na Figura 4.5, foi representada por um diagrama de classes em Unied Modeling Language (UML) contendo os mdulos funcionais e sua descrio. Entre esses mdulos funcionais, podemos encontrar o responsvel pelo cadastro de usurios, o responsvel pelo cadastro de lmes, o responsvel por sugerir novos lmes a usurios, e o responsvel pelo streaming de lmes.
Figura 4.5. Uma viso esttica da arquitetura do SASF
69
J a viso dinmica da arquitetura se preocupa em mostrar os mdulos que possuem comportamento dinmico no sistema. Aqui, eles foram representados por um diagrama de sequncia, tambm em UML, que mostra seu comportamento e suas interaes com outros mdulos (Figura 4.6). Obviamente, os mdulos usados nessa viso devem ter correspondentes na viso esttica.
Figura 4.6. Uma viso dinmica da arquitetura do SASF, mostrando o comportamento de alguns mdulos durante o processo de transmisso de um lme.
Documentos grandes levam tempo para serem construdos. Alm disso, documentos grandes, na prtica, no so usados a no ser que proporcionem para o desenvolvimento um benefcio maior que o custo de l-lo. Essa realidade pode ser traduzida em duas fases. Na primeira, feito um grande esforo para se construir o documento de arquitetura. Ainda nessa fase, o documento completo e consistente com o sistema, alm de ter o potencial para prover os benefcios de uma arquitetura bem documentada. No entanto, a segunda fase consiste no processo de desatualizao do contedo do documento, que ocorre por falha no processo ou pelo alto custo de se manter o documento consistente, e que tem por consequncia a inutilizao do documento de arquitetura e o possvel aumento da entropia no sistema. O problema da inconsistncia da arquitetura com o cdigo acontece porque, em muitos processos de desenvolvimento, arquitetura evolui ao longo do tempo, seja uma evoluo planejada ou no. Uma evoluo no-planejada pode acontecer da forma descrita no exemplo a seguir.
70
Exemplo 4.36. Lembrando da arquitetura do SASF, que foi dividida em trs camadas: apresentao, lgica de negcio e persistncia, uma das decises impostas dita que a camada de apresentao s pode se comunicar com a lgica de negcio. No entanto, um desenvolvedor, medindo que a exibio da interface est demorando porque o carregamento das imagens necessrias est lento, resolve modicar a interface para que proceda da seguinte maneira. O pedido das imagens feito diretamente camada de persistncia, contornando assim o overhead da camada lgica para tanto. Uma vez que ele nota que o desempenho da exibio da interface com o usurio agora est satisfatrio, ele adiciona essa mudana ao cdigo. Acontece que, com isso, ele adicionou uma mudana tambm na arquitetura do sistema. A partir da, h comunicao entre o mdulo de interface e de persistncia, fazendo assim que a documentao da arquitetura esteja inconsistente em relao ao cdigo do sistema.
4.10 Por que documentar a arquitetura de software?

Como j foi mencionado no padro ISO/IEEE 1471-2000, a arquitetura de um sistema existe independentemente dela ter sido documentada ou planejada. No entanto, em pequenos sistemas, pensar, planejar, documentar e manter a arquitetura pode no ser necessrio: um conjunto de classes e pacotes ou de mdulos com suas relaes e evoluo minimamente pensados (ou uma Big Ball of Mud) pode atender aos requisitos funcionais e os atributos de qualidade do sistema. Normalmente, isso acontece quando os requisitos no so difceis de serem atendidos. Assim, todos os interessados cam satisfeitos que podem no ser muitos ou conitantes e o sistema atinge o sucesso esperado. Exemplo 4.37. Pensemos num pequeno sistema que servir para a organizao de uma modesta locadora de lmes. Ele ser capaz de cadastrar, recuperar, atualizar e remover lmes, cadastrar, recuperar, atualizar e remover DVDs de lmes, cadastrar, recuperar, atualizar e remover clientes, realizar locaes, devolues e reservas. Se a execuo desse sistema estiver restrita apenas a uma nica loja fsica, seus requisitos sero simples o suciente para nem precisarmos de uma documentao abrangente (ou mesmo precisar de qualquer documentao!):
71
ele ser desktop, ter apenas um usurio atuando sobre o sistema, sua carga, por ter apenas um usurio, ser baixssima, alm dos dados armazenados no sistema, que por maior que seja a loja, no chegar a limites intratveis por um sistema simples. Podemos observar que um sistema com esses requisitos pode ser desenvolvido e mantido at por um programador menos experiente. Em casos assim, realmente, os custos de planejar, documentar e manter a arquitetura seriam maiores que os benefcios proporcionados por ela. No entanto, quando os sistemas crescem, pensar em arquitetura nos atributos de qualidade e nas mltiplas vises e interessados envolvidos , e document-la se tornam necessrios. Observaremos essa necessidade nos dois exemplos seguintes: apesar de serem exemplos de sistemas funcionalmente semelhantes ao do exemplo anterior, eles tm requisitos no-funcionais que impem a necessidade de uma arquitetura bem pensada e documentada. Exemplo 4.38. O sistema de locadora agora tem que servir para mais duas liais. Assim, o sistema deve estar rodando nas trs lojas e deve existir um cadastro nico de novos lmes, novos DVDs e novos clientes, e tanto a locao quanto a devoluo podem ser feitas em qualquer loja da rede de locadoras. O sistema se torna multiusurio, por agora mais de um balconista us-lo ao mesmo tempo, e distribudo, por ter que manter seu estado consistente entre as diversas lojas fsicas existentes. Surgem agora preocupaes de desempenho, tolerncia a falhas e backup e consistncia de dados. Outras dvidas tambm surgem: Ser um banco de dados central para as trs lojas? Ser um banco distribudo? Se for central, o que fazer caso no seja possvel se comunicar com ele? Se for distribudo, como manter a consistncia entre os dados? Um balconista de uma loja pode acessar o sistema de outra loja? O que um balconista de uma loja tem permisso para fazer na instncia do sistema executando em outra loja? A reserva de um lme est restrita a uma loja fsica, ou ser vlida para todas? E assim por diante. Assim, podemos perceber que uma simples viso de decomposio de classes deixa de ser o nico artefato necessrio para entender o sistema. Precisamos agora de um artefato que represente os estados do sistema durante a execuo, seja em condies normais de operao (e.g., como funciona o procedimento de reserva de lmes entre as lojas da rede de locadoras) , ou seja quando surgem problemas (e.g., o link de comunicao entre as lojas caiu), apenas para exemplicar algumas poucas preocupaes.
72
Podemos notar que todas essas perguntas afetaro como o sistema estar organizado internamente, mas no afetaro suas funcionalidades, que continuaro sendo as do exemplo anterior. Inferimos tambm que a arquitetura desse sistema e sua documentao sero mais complexas que a do Exemplo 4.37. No entanto, no caso do SASF, percebemos que a arquitetura pode se complicar ainda mais, mesmo considerando quase as mesmas funcionalidades. Uma arquitetura ainda mais complexa necessita de uma documentao ainda mais completa para ajudar no desenvolvimento e manuteno desse sistema de software. Exemplo 4.39. A organizao interna do SASF mudar ainda mais em relao aos Exemplos 4.37 e 4.38. As decises que antes permitiam que o sistema rodasse para as trs lojas numa mesma cidade no sero mais vlidas quando falamos de diversos pontos de distribuio espalhados pelo pas. Dessa maneira, observamos que as decises de desempenho, disponibilidade dos dados, e polticas de acesso mudam e, como aumentam tambm em quantidade, se torna mais evidente a necessidade do registro dessas decises em algum tipo de documento para consulta, resoluo de discusses e vericao de conformidade. Adicionalmente, num sistema como o SASF, o nmero de interessados aumenta: desde o usurio que deve entender quais tipos de locao e reserva esto disponveis, passando pelos responsveis pelo suporte ao usurio, os responsveis pela disponibilidade dos diversos subsistemas (aluguel, streaming, dados, backup, etc.), gerente de marketing, time de desenvolvimento, gerente de projeto, gerente da empresa. Aumentando assim a responsabilidade de se obter um sistema capaz de satisfazer a todos eles. Cada um ter um conjunto diferente de preocupaes sobre o sistema. Seja o responsvel por manter o sistema no ar, que precisa saber quantos recursos esto sendo consumidos a cada momento; seja o time de implementao, que precisa descobrir como adicionar uma nova funcionalidade sem quebrar as anteriores; seja o gerente do projeto, que deve decidir por contratar mais desenvolvedores para implementao ou comprar solues prontas. Cada um desses estar preocupado tambm com qualidades diferentes do sistema: o responsvel pela disponibilidade do sistema quer saber como o sistema escala se a base de usurios duplicar; j o time de implementao est preocupado em deixar o sistema mais testvel para que a implementao da nova funcionalidade seja mais fcil; e, por outro lado, o gerente quer saber
73
se o desenvolvimento do sistema possvel com um time de desenvolvedores menor que o atual. Essas preocupaes sero endereadas pelo documento de arquitetura do SASF, que contm diversas vises direcionadas s diversas preocupaes dos interessados. Uma viso de implementao interessar ao responsvel pela disponibilidade, assim como uma viso de decomposio interessar ao time de desenvolvimento, assim como uma viso de implementao interessar ao gerente do projeto, fazendo ento que o documento de arquitetura possua diversas vises e se torne um documento complexo. O mais importante a se observar nesse exemplo (e no estudo do SASF) que o design e a documentao da arquitetura no so atividades fceis nem baratas. O arquiteto escolhido para resolver esse problema deve (1) conhecer os interessados, (2) conhecer os atributos de qualidade impostos ao sistema por esses interessados, (3) conhecer as relaes e trade-os entre interessados e atributos de qualidade, (4) conhecer tcnicas, padres e ferramentas que permitam o atendimento aos atributos, e (5) documentar a soluo do problema, de forma que os interessados entendam e tirem proveito do documento gerado.
Resumo
O objetivo deste livro fazer com que o leitor seja capaz de enderear todos os aspectos da arquitetura citados anteriormente, podendo realizar algumas das diversas funes realizadas por um arquiteto de software. Dessa maneira, o objetivo deste captulo foi dar uma viso geral do conhecimento necessrio para tanto, fundamentando-o com alguns exemplos e denies. Assim, esperamos que o leitor, a partir de agora: entenda e exemplique os principais conceitos relacionados arquitetura de software; entenda e exemplique as principais caractersticas e benefcios proporcionados pela arquitetura de software no processo de desenvolvimento. No prximo captulo, conheceremos os principais interessados que devem ser contemplados pela arquitetura, alm de suas caractersticas e relaes. No captulo seguinte, entenderemos melhor os atributos de qualidade impostos
74
por esses interessados, alm de apresentarmos algumas tcnicas para atender esses atributos. Em seguida, teremos um captulo focado em tcnicas para implementar esses atributos. Por m, no ltimo captulo, aprenderemos a documentar a soluo que atender aos interessados e atributos do sistema.
Referncias
Histrico da rea Apesar da nfase em Arquitetura de Software como disciplina ter acontecido apenas durante a dcada de 1990 com autores a exemplo de Perry e Wolf [68] e Garlan e Shaw [34], podemos encontrar trabalhos das dcadas de 1960 e 1970 que j citam algumas tcnicas e benefcios da rea. Entre eles, encontramos Dijkstra [25], Parnas [66] e outros. Mais informaes sobre o histrico da disciplina podem ser vistas em The Past, Present, and Future for Software Architecture, de Kruchten, Obbink e Staord [48]. Evoluo de software A evoluo de Software bem estudada no livro editado por Mens e Demeyer, Software Evolution [62] e nos trabalhos de Parnas [67], van Gurp e Bosch [83] e Eick et al [28]. Mais informaes sobre a Big Ball of Mud podem ser encontradas em Foote e Yoder [31]. Elementos de uma arquitetura A diviso dos elementos arquiteturais em estticos e dinmicos feita originalmente por Rozanski e Woods em Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [72]. J a discusso sobre classicao dos atributos de qualidade pode ser encontrada no livro Software Engineering, de Sommerville [79]. Por m, podemos citar algumas referncias importantes sobre vises arquiteturais: The 4+1 View Model of Architecture de Kruchten [49], Documenting Software Architectures: Views and Beyond Clements de Clements et al [20] e o padro ISO/IEEE 1471-2000 [39].
75
Exerccios
4.1. Quais as diferenas entre design arquitetural e design de baixo nvel? 4.2. Quais os benefcios de se projetar a arquitetura de um software? 4.3. Quais os elementos que compem a arquitetura, qual o objetivo deles? 4.4. O que so atributos de qualidade do software? Cite exemplos. 4.5. Cite algumas qualidades de software que a arquitetura ajuda a alcanar. Descreva tambm como a arquitetura ajuda no alcance dessas qualidades. 4.6. O que so decises arquiteturais e qual o seu papel na arquitetura? 4.7. Como a arquitetura permite o rastreamento de requisitos ao longo do processo de desenvolvimento? 4.8. O que evoluo de software e qual a inuncia da arquitetura nesse processo? 4.9. O que so vises arquiteturais e qual a sua importncia no processo de desenvolvimento? Descreva exemplos de vises arquiteturais. 4.10. Quais os benefcios e desvantagens proporcionados pela documentao da arquitetura. Cite exemplos.
5 Stakeholders
O ciclo de vida do software composto por diversas responsabilidades atribudas a pessoas, grupos e entidades a quem chamamos de stakeholders ou interessados. Entre essas responsabilidades, podemos citar o nanciamento, o projeto, o desenvolvimento, o teste, o uso e a manuteno do software. A arquitetura, por sua vez, tem como objetivos tanto facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender s suas necessidades. Entre as necessidades, citamos a urgncia por desempenho, diversos aspectos de segurana e usabilidade. Por sua vez, o cumprimento desses objetivos tem impacto direto nos atributos de qualidade exibidos pelo software. Logo, os stakeholders tm forte inuncia sobre a arquitetura do software e tambm sobre os atributos de qualidade que este exibir ao longo de seu ciclo de vida e por isso que dedicamos um captulo a eles. Este captulo tem como objetivo fazer com que o leitor seja capaz de: Entender o conceito de stakeholders da arquitetura de um software Identicar alguns stakeholders e sua inuncia em uma arquitetura Relacionar stakeholders com os atributos de qualidade impostos a um software Entender que stakeholders tambm se relacionam entre si, podendo, inclusive, ser conitantes
78
5 Stakeholders
5.1 Quem so os interessados em um sistema de software?

comum termos como principais interessados no ciclo de vida de um software os seus usurios e desenvolvedores. Acontece que eles no so os nicos envolvidos ou, ao menos, so grupos homogneos em termos de interesses e necessidades. Entretanto, para termos um ponto de partida, vamos considerar um cenrio em que existem apenas esses dois grupos e algumas simplicaes. Nesse cenrio, eles ambos os grupos so homogneos, ou seja, todos os usurios e desenvolvedores apresentam os mesmos interesses e necessidades, e os usurios se encarregam de impor as necessidades, enquanto os desenvolvedores cuidam para que essas necessidades sejam alcanadas atravs do produto de software. Para montarmos esse cenrio, vamos partir de um sistema parecido com o nosso estudo de caso e, pouco a pouco, retirar interesses e necessidades dos envolvidos para observar suas inuncias no software e em sua arquitetura. Esse processo ilustrado atravs do Exemplo 5.1. Exemplo 5.1. Vamos considerar uma simplicao do SASF que chamaremos SSF (Sistema de Streaming de Filmes). Ele mais simples porque realiza apenas uma das duas principais funcionalidades do SASF: transmitir lmes. Por sua semelhana, consideramos que ele possui um conjunto de interessados parecido com o do SASF. Entretanto, para compormos um cenrio sem conitos, vamos comear descartando as distribuidoras de lmes desse conjunto. Com isso, passamos a responsabilidade de disponibilizar lmes aos usurios que inicialmente usam o software apenas para assisti-los. Contudo, as distribuidoras no so consideradas interessadas apenas por disponibilizarem lmes. Elas tm tambm a preocupao com que o software respeite os direitos autorais desses lmes. Para tanto, o SASF e o SSF so obrigados a s permitir a transmisso de lmes a pessoas autorizadas e impedir a redistribuio de vdeos por parte dos usurios. Essas obrigaes tm efeito na arquitetura de ambos os produtos, que tem que prover no s meios de autenticar e autorizar usurios, para distinguir usurios que assistem dos usurios que distribuem lmes, como tambm prover meios de impedir ou dicultar a redistribuio do contedo transmitido. A autenticao e autorizao so feitas por um mdulo responsvel pelo cadastro e autenticao de usurios e criao de sesses de uso. Esse mdulo prov opes para se cadastrar como distribuidor ou consumidor de lmes.
79
Para o cadastro, o usurio deve prover informaes para contato qualquer que seja seu papel. Porm, enquanto a conta para um consumidor criada assim que o nmero de seu carto de crdito seja vericado junto a operadora, o mesmo no acontece para a conta do distribuidor. Para o cadastro de um consumidor ser efetivado, necessria uma vericao no-automtica de sua autenticidade. Essa vericao iniciada a partir de uma noticao por email, que indica o distribuidor recm-cadastrado e que enviado s pessoas do departamento responsvel pela vericao de usurios. A proteo contra redistribuio do contedo transmitido, por sua vez, feita por meio da Gesto de Direitos Digitais (GDD)1 . Por isso, a arquitetura no s dene o servidor de stream, mas tambm o aplicativo cliente e reprodutor de lmes que o nico capaz de decodicar o vdeo. Por outro lado, ao descartarmos as distribuidoras de lmes de seu grupo de interessados, o SSF ca livre das restries impostas por elas e passar a no necessitar de uma arquitetura que permita autenticao e autorizao para distribuio de lmes, nem proteo do contedo distribudo. Por isso, sua arquitetura pode ser simplicada. Uma forma de simplicar no mais usar a GDD. Dessa maneira, ca decidido que a transmisso ser feita usando qualquer formato de vdeo amplamente adotado por reprodutores de mdia. Essa deciso exclui at o que antes era a necessidade: implementar um reprodutor de lmes prprio, mas tambm melhora a usabilidade, uma vez que agora o usurio est livre para assistir a lmes com o reprodutor que desejar. Deixar de considerar um nico grupo de interessados causou mudanas profundas tanto nos atributos de segurana, quanto nos de usabilidade do sistema e, como consequncia, causou mudanas tambm na arquitetura. Se continuarmos a simplicao de nosso cenrio e desconsiderarmos o cliente do software, poderemos ento descartar a necessidade de um baixo custo de desenvolvimento e operao. Assim, para alcanarmos desempenho esperado pelos consumidores de lmes, a arquitetura do SSF poderia adotar uma tcnica simples, porm cara: para servir mais rpido, basta apenas dispor de mais recursos computacionais, por exemplo, processadores, HDs, memria e conexes maiores, mais rpidos e em maior nmero. Com essa deciso de aumentar os recursos no se importando com o preo, o SSF poder no s servir os
Digital Rights Management (DRM)
80
5 Stakeholders
usurios mais rpido, como tambm servir a mais usurios.2 Essa abordagem de apenas melhorar o hardware para servir a uma maior demanda o que no prximo captulo chamamos de escalabilidade vertical. A escalabilidade vertical costuma ser bem cara e ter um limite menor de crescimento em relao sua alternativa, que a escalabilidade horizontal. Nesse segundo tipo de escalabilidade, a organizao do software e como ele se comunica realiza um papel essencial para atender grande demanda de usurios, mesmo quando executando em hardware de menor capacidade. Em outras palavras, h um melhor aproveitamento dos recursos disponveis, algo que s pode ser alcanado por meio de uma arquitetura bem pensada. importante lembrar que dentro de um mesmo grupo de interessados podem existir interesses conitantes entre si. Anal, um grupo pode se organizar em subgrupos de interesses comuns, mas um subgrupo pode demonstrar interesses conitantes com outro subgrupo. Portanto, subgrupos diferentes de usurios ou de desenvolvedores resultam em requisitos diferentes, que signicam atributos de qualidade diferentes e que so frutos de arquiteturas diferentes. Podemos observar isso no estudo de caso (tambm citado no Exemplo 5.1), quando o grupo de usurios se organiza em dois subgrupos: os que se cadastram no sistema para alugar lmes e as distribuidoras de lmes. O resultado dessa diviso e o conito podem tambm ser observados no exemplo (e na Figura 5.1). Por um lado, as distribuidoras impem seus requisitos de proteo aos direitos autorais. Por outro, os usurios tm a forma de interao com o sistema modicada, uma vez que devem usar um reprodutor de lmes especco para que os requisitos das distribuidoras sejam alcanados. Em resumo, mesmo fazendo parte de um mesmo grupo de envolvidos, a inuncia de cada subgrupo no pode ser desconsiderada, uma vez que ela pode ser grande o bastante para modicar, inclusive, a forma de outros subgrupos interagirem com o sistema. 5.1.1 Importncia dos interessados Observe que no Exemplo 5.1 a presena ou ausncia de um interessado tem grande inuncia na arquitetura. Alm disso, comum que sua ausncia d
2
Desempenho um atributo comumente esperado pelos usurios, que nunca querem esperar pelo servio. J escalabilidade no um atributo requerido explicitamente por eles, mas se torna necessria quando o nmero de usurios aumenta e no se aceita que o desempenho degrade.
81
Figura 5.1. Stakeholders de um mesmo grupo, mas divergindo nos requisitos.
espao para simplicaes nas decises arquiteturais.3 Entretanto, no mundo real, os envolvidos no se limitam a usurios e desenvolvedores. H diversos outros tipos de envolvidos que inuenciam o desenvolvimento do software de diversas maneiras diferentes. Esses envolvidos que inuenciam o ciclo de vida do software tambm so chamados stakeholders. Devido ao conceito de stakeholder ser bastante amplo e transcender a Engenharia de Software, preocupamo-nos apenas com aqueles que impactam a arquitetura e, por isso, usamos a denio dada por Rozanski e Woods: Denio 5.1 (stakeholder). Um stakeholder em uma arquitetura de software uma pessoa, grupo ou entidade com um interesse ou preocupaes sobre a realizao da arquitetura. 4 Alguns stakeholders tm diferentes responsabilidades durante o ciclo de vida do software. Entre as responsabilidades, podemos citar nanciamento, projeto, desenvolvimento, teste, uso, manuteno e at passagem de conhecimento sobre ele. Outros stakeholders, por sua vez, esperam que o software funcione de alguma forma especca: eles tm necessidades em relao ao software. Por exemplo, comum para um usurio esperar que o resultado
3
Note que uma arquitetura mais simples no necessariamente signica um produto com desenvolvimento mais barato ou execuo mais rpida. N. Rozanski and E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley Professional 2005.
82
5 Stakeholders
alcanado pelo software seja convel ou que seja alcanado em um tempo hbil. Quando estamos no espao do problema, costumamos chamar essas responsabilidades e necessidades de requisitos do software. Por outro lado, quando estamos no espao da soluo, costumamos cham-las de atributos de qualidade. Logo, os stakeholders tm forte inuncia sobre a arquitetura de um software porque ela uma ferramenta essencial para proporcionar seus atributos de qualidade e atender aos requisitos, como, por exemplo: custo, reusabilidade, testabilidade, manutenibilidade, legibilidade, desempenho, escalabilidade, segurana, conabilidade, entre outros.
5.2 Tipos de stakeholders e sua relao com os atributos de qualidade

Entre os diversos tipos de stakeholders que inuenciam a arquitetura, podemos citar os usurios, os desenvolvedores, os gerentes, os testadores, os clientes (que podem ou no ser usurios), os designers de outros sistemas e os mantenedores, alm dos analistas e o prprio arquiteto do sistema. Considerando que esse um conjunto heterogneo de papis, natural que cada papel possua diferentes necessidades e responsabilidades que tm efeito sobre a arquitetura e que, eventualmente, resultem em conitos. Resolver conitos de interesses entre stakeholders est entre as obrigaes de um arquiteto de software. Ele deve ser consciente de que muitas vezes no ser possvel agradar perfeitamente a todos os interessados, uma vez que esses conitos podem impedir o projeto de uma soluo tima. Portanto, sua obrigao ser a de produzir uma arquitetura boa o suciente e que faa todos os stakeholders carem satisfeitos. Por isso, importante que cada envolvido seja informado de como a soluo de seu interesse foi restringida pelos interesses de outros envolvidos. A seguir, podemos observar duas situaes de divergncias entre stakeholders que resultam em conitos entre os atributos de qualidade. Exemplo 5.2. As distribuidoras esperam que os direitos autorais de seus lmes sejam protegidos, j os usurios querem apenas assistir a seus lmes sem diculdades ou interrupes. A forma encontrada para proteger os direitos autorais foi por meio da Gesto de Direitos Digitais. Essa deciso implica em restringir o reprodutor de mdia que pode ser usado e obrigar o usurio
83
a se autenticar no sistema para assistir a algum lme. Tanto a restrio do reprodutor de mdia, quanto a autenticao do usurio dicultam a tarefa de assistir a um lme, uma vez que o usurio pode no se lembrar de seu login ou senha ou ele pode no estar acostumado com o reprodutor de lmes permitido. Por isso, essa deciso de segurana tem impacto negativo na usabilidade. Portanto, podemos observar aqui um conito entre segurana e usabilidade. Exemplo 5.3. Ainda no SASF e tambm pela deciso de proteger os direitos autorais usando GDD, o arquivo contendo o lme transmitido encriptado para o cliente. Essa encriptao uma forma de dicultar a reproduo do vdeo em programas no autorizados. No entanto, o reprodutor de vdeo autorizado deve pagar um preo por isso: para decodicar um arquivo com GDD, necessrio mais processamento e, portanto, maior consumo de recursos. Isso ocasiona perda de desempenho, o que pode ser crtico em dispositivos com menos recursos, como celulares. Por isso, a deciso de segurana tambm tem impacto negativo no desempenho, caracterizando um conito entre esses dois atributos. Note que para armarmos que uma arquitetura alcanou algum sucesso, os stakeholders devem se mostrar satisfeitos com o sistema desenvolvido a partir dela. Para tanto, espera-se que o arquiteto seja capaz de projetar uma arquitetura que alcance dois principais objetivos: atendimento de requisitos e resoluo de conitos. 5.2.1 Atendimento aos requisitos como medida de sucesso O primeiro objetivo, atender aos requisitos dos stakeholders, acaba sendo bvio, pois para satisfazer os interessados, o sistema deve fazer o que eles esperam dele. Mas apesar de bvio, enfatizar esse objetivo serve para o arquiteto iniciante perceber que seu objetivo principal projetar uma arquitetura com atributos de qualidade capazes de atender aos requisitos do sistema impostos e esperados pelos stakeholders e no s por ele prprio. No exemplo a seguir, mostramos um caso quando isso no acontece. Exemplo 5.4. Em alguns celulares e outros aparelhos que executam software embarcado, espera-se que esse software tenha um bom desempenho, principalmente considerando a escassez de recursos do ambiente de execuo. Anal,
84
5 Stakeholders
o usurio no quer pressionar uma tecla e esperar vrios segundos pela resposta. Por outro lado, no se espera que o software seja extensvel, uma vez que alguns desses aparelhos nem ao menos permitem atualizaes de software. Considerando que, nesse caso, desempenho e economia de recursos so requisitos mais crticos que extensibilidade, de nada adianta o arquiteto do software para aparelhos que no permitem atualizaes projete uma arquitetura que torne o software extensvel, com diversos nveis de abstrao, quando esses nveis impactam negativamente no desempenho. Pode parecer ingenuidade tomar decises em favor da extensibilidade quando se espera desempenho, como ilustrado no Exemplo 5.4. No entanto, esse erro muito comum e no s cometido por arquitetos inexperientes. Muitos arquitetos no consideram o real impacto de suas decises e se deixam levar por modas de padres, frameworks 5 ou abordagens que prometem resolver todos seus problemas. s vezes, apenas considerado que assim ser mais fcil vender a arquitetura ao gerente do projeto. Por m, poderamos ainda armar a partir do primeiro objetivo: no importa o quanto de acordo com as boas prticas a arquitetura de um software est, se ela no atende aos requisitos que esperam que ela atenda. Ela, simplesmente, estaria acertando o alvo errado.6 Portanto, a medida de atendimento aos requisitos do sistema a melhor medida de sucesso da arquitetura, desde que se conheam os requisitos. 5.2.2 Conitos entre requisitos e atributos de qualidade Situaes de conito surgem quando requisitos de stakeholders divergem ou afetam atributos de qualidade comuns. Podemos observar que esse tipo de situao est presente, inclusive, em alguns exemplos anteriores (Exemplos 5.2 e 5.3). Nesses exemplos so ilustrados conitos entre atributos de segurana e usabilidade e entre segurana e desempenho. A seguir, citamos outros atributos de qualidade e relacionamos a alguns stakeholders que tm requisitos que comumente divergem durante o ciclo de vida do software.
5
comum que a adoo de um framework seja seguida de decises arquiteturais impostas por ele e essas decises podem comprometer ou conitar com os objetivos traados pelo arquiteto e esperados pelos stakeholders. Mas claro que as boas prticas sero ferramentas para resolver os problemas propostos pelos stakeholders.
85
Exemplo 5.5 (Desempenho versus custo). Usurios buscam por maior desempenho, enquanto clientes e gerentes costumam preferir menor custo de desenvolvimento. Esses atributos divergem porque comum que maior desempenho resulte em uma soluo que necessite de mais recursos computacionais ou ainda desenvolvedores mais qualicados na sua construo. Exemplo 5.6 (Desempenho versus escalabilidade). O cliente, que espera ganhar dinheiro a partir da popularizao do software, impe o requisito que ele seja capaz de servir a demanda crescente de usurios. J os usurios continuam buscando por desempenho do software, no se importando se h dez, mil ou um milho de usurios usando-o ao mesmo tempo. Uma forma simples de servir a demanda crescente de usurios, ou escalar, seria no se preocupar com o tempo de resposta do servio para cada usurio e aument-lo drasticamente. No entanto, o aumento do tempo de resposta um indcio de perda de desempenho, caracterizando o conito. Exemplo 5.7 (Usabilidade versus segurana). Em um ltimo exemplo, citamos o conito entre usabilidade e segurana. Usurios esperam realizar suas tarefas rapidamente, sem dvidas e sem erros causados pela diculdade de usar, ou seja, esperam usabilidade do software. Por outro lado, auditores, clientes e os prprios usurios esperam que suas informaes estejam a salvo, tanto para casos de ataques, quanto para manipulao indevida. Medidas de segurana devem ser projetadas e o software deve prover meios de autenticao, autorizao, condencialidade e auditabilidade. Ao tomar essas medidas, a usabilidade afetada negativamente, uma vez que mais passos sero necessrios para se realizar as mesmas aes. Por exemplo, para comear a usar o software, agora ser necessrio inserir uma senha para que o usurio seja autenticado. Portanto, a adoo de polticas de segurana costuma afetar negativamente a usabilidade do sistema. 5.2.3 Responsabilidades dos stakeholders Como j foi mencionado anteriormente, stakeholders tm responsabilidades durante o ciclo de vida do software. A seguir, agrupamos as responsabilidades em quatro grandes tipos e citamos seu principais interessados: Uso ou aquisio do sistema, que so responsabilidades de usurios e clientes;
86
5 Stakeholders
Desenvolvimento, descrio e documentao da arquitetura do sistema, que so responsabilidades do arquiteto do sistema; Desenvolvimento e manuteno do sistema, que so responsabilidades que envolvem o maior nmero de stakeholders: arquitetos, projetistas, programadores, mantenedores, testadores, engenheiros de domnio, gerentes de
projetos e desenvolvedores, entre outros; Avaliao do sistema e do seu desenvolvimento, que so responsabilidades de CIOs7 , auditores e avaliadores independentes.
Por m, descrevemos alguns dos stakeholders citados e qual sua inuncia da arquitetura e em sua documentao. Para tanto, mencionamos quais so seus interesses comuns e o que eles esperam da documentao da arquitetura. Usurios A principal preocupao dos usurios com as funcionalidades providas pelo sistema, pouco importando como o software foi dividido em mdulos ou como esses mdulos se comunicam entre si. Podemos armar que um usurio s pensa em um atributo de qualidade, por exemplo, em desempenho ou em segurana, quando algum desses lhe faltar. Essa despreocupao com a organizao interna do software poderia nos fazer armar ingenuamente que a arquitetura no interessa ao usurio. No entanto, ela interessa, ainda que indiretamente, uma vez que o sistema deve possuir uma arquitetura que proporcione os atributos de qualidade esperados pelos usurios para que funcione de forma satisfatria. J em relao documentao, os usurios esto interessados em saber as capacidades e o comportamento do sistema. Vale notar que essa informao pode estar em outros documentos, como em um manual do usurio, mas esse e outros documentos devem ser escritos tendo por base o documento de arquitetura, que deve conter essas informaes. Clientes Da mesma forma que os usurios, os clientes no costumam se preocupar em detalhes tcnicos da arquitetura. Eles esto interessados nas caractersticas da
7
Chief Information Ocer ou CIO o nome dado ao diretor do departamento de Tecnologia da Informao de uma empresa.
87
arquitetura ligadas ao seu negcio: se o sistema faz o que deveria fazer, seus custos, sejam de desenvolvimento ou de execuo, e o planejamento de seu desenvolvimento. Isso se faz necessrio para justicar o dinheiro investido no software. Clientes tambm se mostram interessados na justicativa de resoluo dos eventuais conitos, principalmente se essa resoluo tem impacto no negcio. Arquiteto Uma vez que o principal responsvel por projetar a arquitetura, o arquiteto tem a obrigao de conhecer os stakeholders envolvidos no sistema. Isso permitir que ele saiba o que os stakeholders esperam do sistema e, por m, seja capaz de projetar o sistema de acordo com os requisitos esperados. O arquiteto tambm responsvel por negociar os conitos de interesses entre os stakeholders, o que resultar numa arquitetura com atributos de qualidade que agradem a vrios, mesmo que parcialmente. A necessidade de conhecer e dialogar com os diversos stakeholders faz com que o arquiteto precise de habilidades tanto sociais quanto tcnicas. Em relao ao conhecimento tcnico, ser experiente no domnio do problema o ajudar a identicar previamente as diculdades e solues a serem encontradas ao longo do desenvolvimento. J as habilidades sociais o ajudam tanto na descoberta de requisitos, quanto na negociao de divergncias. Desenvolvedor O desenvolvedor v a arquitetura como base para construir o sistema. H dois extremos de como a arquitetura pode ser apresentada para ele. Ela pode ser apresentada como uma especicao, onde no h qualquer liberdade de design durante o desenvolvimento. Ou ela pode ser apresentada como um guia, que apresenta algumas restries essenciais para que o software alcance o sucesso, mas tambm possui diversas liberdades para as decises de implementao e design de baixo-nvel que cam a cargo do time de desenvolvimento. Ao longo de todo o espectro, o desenvolvedor espera pela ideia geral do sistema, onde as funcionalidades sero implementadas, quem sero os responsveis por elas e quais as decises de design de alto-nvel relacionadas a elas. Um desenvolvedor comumente espera que a arquitetura tambm seja vivel e de acordo com suas habilidades, alm de que possua as decises de design
88
5 Stakeholders
escritas de forma clara e objetiva. Ele tambm espera que o documento de arquitetura possibilite a associao dos requisitos do sistema s partes que o compem. Essa associao o que chamamos de rastreabilidade, que torna mais fcil tanto a manuteno quanto o entendimento do sistema. Testador O testador procura no documento de arquitetura as restries as quais o software deve obedecer. Alm disso, ele espera que o software seja testvel e, para tanto, sua arquitetura deve proporcionar tal atributo de qualidade. O nvel de testabilidade de um software est diretamente ligado a capacidade dele (ou de suas partes) ser posto em execuo em ambiente de desenvolvimento e de seu comportamento, interno ou externo, ser vericvel a partir do esperado. Gerente de projeto O gerente de projeto, assim como o cliente, est interessado em custos e planejamento. No entanto, ele tambm se preocupa com detalhes tcnicos da arquitetura e como ela ajudar no desenvolvimento do software. A arquitetura o ajudar a resolver problemas do tipo: como dividir o time de desenvolvimento a m de paralelizar a construo dos mdulos, quais partes do software podem ter o cdigo reusado, terceirizado ou comprado, ou ainda como as funcionalidades sero divididas entre os mltiplos releases do software.
5.3 Resumo
De maneira alguma esgotamos o assunto sobre stakeholders. Por outro lado, no devemos nos aprofundar ainda mais para no perdermos nosso foco que o design da arquitetura. Entretanto, acreditamos alcanar os objetivos deste captulo, mesmo com uma abordagem supercial sobre o assunto. Assim, esperamos que o leitor, a partir de agora: entenda e exemplique o conceito de stakeholders da arquitetura de um software; entenda a inuncia desses stakeholders;
5.3 Resumo
89
relacione os stakeholders aos atributos de qualidade esperados pelo software; e entenda que os stakeholders se relacionam entre si, podendo, inclusive, gerar demandas conitantes. Nos captulos a seguir, voltamos nosso foco aos atributos de qualidade e
s tcnicas de como se projetar uma arquitetura que atenda a esses atributos. Ainda assim, no podemos esquecer que nossos objetivos como arquitetos so descritos explicita ou implicitamente pelos stakeholders e por sua inuncia sobre arquitetura do software.
Referncias
Denio e papel dos stakeholders O padro ISO/IEEE 1471-2000 [39], alm de denir stakeholders, modela seu papel em relao aos vrios elementos relacionados arquitetura de software. nesse padro que Rozanski e Woods se baseiam para para chegar denio de stakeholders no livro Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [72], onde dedicam um captulo inteiro sobre o assunto. Outras duas importantes referncias sobre o papel dos stakeholders ao longo da vida da arquitetura so dois livros publicados pelo Software Engineering Institute, da Carnegie Mellon University: Software Architecture in Practice de Bass et al [6] e Documenting Software Architecture: Views and Beyond de Clements et al [20]. Ambos mostram a importncia de considerar os stakeholders, sendo o segundo mais completo pois tambm trata das escolhas que o arquiteto deve fazer ao criar as vises da arquitetura de acordo com os interessados. Arquiteto como stakeholder Taylor et al, no livro Software Architecture: Foundations, Theory, and Practice [81], dedicam todo um captulo sobre a responsabilidade do arquiteto como stakeholder, incluindo os diversos papis que ele pode assumir durante o ciclo de vida do software. Outros artigos importantes sobre o papel do arquiteto de software que podemos citar so o The Software Architect and The Software Architecture
90
5 Stakeholders
Team de Kruchten [47], o Who Needs an Architect? de Fowler [32] e o The Software Architect: Essence, Intuition, and Guiding Principles de McBride [58]. Responsabilidades dos stakeholders Booch discute sobre a despreocupao dos usurios em relao arquitetura em The Irrelevance of Architecture [10]. J em Goodness of Fit [9], ele escreve sobre o que seria uma arquitetura de sucesso. Por m, Hohmann, no livro Beyond Software Architecture [38] trata das diversas preocupaes ligadas aos atributos de qualidade do software. Preocupaes que no so apenas do arquiteto, mas tambm so dos diversos envolvidos no desenvolvimento do software.
Exerccios
5.1. Qual a importncia da identicao dos stakeholders na arquitetura de um sistema de software? 5.2. A identicao de muitos stakeholders em uma arquitetura aumenta a chance de sucesso. No entanto, os interesses dos stakeholders muitas vezes no so claros e podem ser conitantes e/ou contraditrios. Cite mais exemplos desses conitos/contradies. 5.3. impossvel capturar as caractersticas funcionais e as propriedades de qualidade de um sistema complexo com um simples modelo. De que forma poder-se-ia representar arquiteturalmente sistemas complexos de forma que seja gerencivel e compreensvel por uma faixa de stakeholders tcnicos e de negcio?
6 Atributos de Qualidade
Um software tem como objetivo atender aos seus requisitos funcionais e nofuncionais. Os requisitos funcionais descrevem as funes que o software deve ser capaz de realizar, ou seja, o que o sistema faz. J os requisitos nofuncionais descrevem as qualidades e restries de como o sistema realiza suas funes, ou seja, como o sistema funciona. Um software, portanto, deve exibir atributos de qualidade que atendam aos seus requisitos. Por sua vez, a arquitetura de software contm a descrio de como esse alcana aos atributos de qualidade. Essa descrio de como o software atende aos requisitos no-funcionais feita pelas diversas decises presentes na arquitetura. Para conceber essas decises arquiteturais e, portanto, para projetar a arquitetura de fundamental importncia que o arquiteto conhea tanto os objetivos a serem alcanados pelo software, quanto as ferramentas para alcan-los. Em outra palavras, essencial que ele conhea tanto os atributos de qualidade, quanto tcnicas e padres de design arquitetural que, ao serem implementados, possibilitam ao software que exiba os atributos de qualidade desejados. Considerando a importncia dos atributos de qualidade de software, dedicamos dois captulos a eles. Neste captulo, mostramos uma viso geral do assunto, abordando diversos atributos que devem ser alcanados. Este captulo tem como objetivos: Identicar o que so atributos de qualidade e qual sua inuncia na arquitetura de software; Relacionar atributos de qualidade a decises arquiteturais que os proporcionam;
92
Entender que os atributos de qualidade se relacionam e como eles se relacionam.
No captulo seguinte, apresentamos tcnicas de design arquitetural e uma srie de estudos de como alguns atributos foram alcanados na prtica em diferentes sistemas de software. Esses estudos mostram que tcnicas e padres de design arquitetural foram aplicados para alcanar tais atributos e quais seus benefcios e limitaes apresentados.
6.1 Requisitos Funcionais e No-Funcionais

O nico objetivo de um software o de atender a seus requisitos. Esses requisitos so denidos ao longo de seu ciclo de desenvolvimento e costumam ser classicados em requisitos funcionais e requisitos no-funcionais. Os requisitos funcionais descrevem as funes que o sistema capaz de realizar, ou seja, descrevem o que o sistema faz. Denio 6.1 (requisito funcional). a declarao de uma funo ou comportamento providos pelo sistema sob condies especcas. Os requisitos do software so impostos pelos seus diversos stakeholders. No entanto, os requisitos funcionais costumam ser ditados pelos clientes do software, anal so eles que esperam ter seus problemas resolvidos pelas funcionalidades do software. Exemplo 6.1. Se estamos falando do SASF, entre suas funes, podemos citar: (RF-01) O usurio deve ser capaz de inserir um lme da sua lista de aluguis; (RF-02) O usurio deve ser capaz de assistir a um lme via streaming ; (RF-03) O usurio deve ser capaz de adicionar um comentrio sobre um lme. Se o problema de desenvolver software fosse apenas o de atender aos requisitos funcionais, desenvolver software j poderia ser considerado uma tarefa difcil. Isso porque, para serem atendidos, muitos dos requisitos funcionais necessitam de conhecimento que ultrapassa os limites da Engenharia de Software, da Cincia da Computao ou mesmo da Matemtica. Anal, para se implementar sistemas para Computer-Aided Design (CAD) ou sistemas que analisam os dados extrados do Large Hadron Collider (LHC)1 preciso
1
Large Hadron Collider (LHC): http://public.web.cern.ch/public/en/LHC/LHC-en.html
93
grande conhecimento especco ao domnio do problema, ou seja, grande conhecimento de outras engenharias (por ex., Engenharia Mecnica e Civil) ou de outras cincias (por ex., Fsica e Qumica), respectivamente. Alm da necessidade de conhecimento especco ao domnio do problema, h outra diculdade no desenvolvimento de software para atender apenas aos requisitos funcionais: o cliente pode no ter certeza sobre o que ele quer do software. Esta condio bem conhecida pela Engenharia de Requisitos, que nos prov algumas tcnicas para resolv-la ou contorn-la. Mas isso no quer dizer que no possa se tornar um problema durante o ciclo de desenvolvimento. Anal, se o principal interessado no sabe bem quais funes espera que o sistema realize, no podemos armar que ser fcil desenvolver esse sistema. Por outro lado, h tambm os requisitos no-funcionais. Esses esto relacionados qualidade da realizao dos requisitos funcionais, ou seja, como essas funes so realizadas. Denio 6.2 (requisito no-funcional). a descrio de propriedades, caractersticas ou restries que o software apresenta exibidas por suas funcionalidades. Esses requisitos tambm so impostos pelos diversos stakeholders do software e esto normalmente relacionados a interfaces com o usurio, capacidades, consumo de recursos e escalas de tempo. Exemplo 6.2. Podemos citar alguns exemplos de requisitos no-funcionais do SASF: (RNF-01) O sistema deve permitir o uso por diversas interfaces diferentes: navegador de internet, celular, TV (usando um decodicador de TV por assinatura compatvel) e aplicao-cliente compatvel com as famlias de sistemas operacionais Windows, Mac OS e Linux; (RNF-02) O sistema deve suportar at 3 milhes de inseres na la de aluguis por dia (34,7 operaes por segundo); (RNF-03) Uma transmisso de vdeo via streaming no pode ser iniciada em mais do que 30 segundos. As restries feitas pelos requisitos no-funcionais so vrias e podem incluir restries ao processo de desenvolvimento, restries para atingir ou manter compatibilidade, e restries legais, econmicas ou de interoperabilidade. As restries ao processo de desenvolvimento podem ser feitas pela
94
imposio de padres de desenvolvimento ou mesmo de linguagens a serem utilizadas pelo sistema. Por exemplo, um requisito no-funcional de um sistema pode ser que ele deva ser implementado usando a linguagem JavaTM , uma vez que a equipe responsvel pela operao e manuteno aps seu desenvolvimento experiente nessa linguagem. Por m, podemos ainda citar requisitos no-funcionais conhecidos que foram impostos em prol de compatibilidade e interoperabilidade e por que no dizer de questes econmicas, que um caso relacionado ao sistema operacional Windows NT. O Windows NT possui requisitos no-funcionais que ditam que ele deve ser capaz de executar aplicativos originalmente escritos para DOS, OS/2, verses anteriores do Windows e aplicativos de acordo com o padro POSIX2 . Assim, satisfazendo aos requisitos de poder executar aplicativos originalmente escritos para sistemas operacionais anteriores, o Windows NT teria um custo de adoo mais baixo, uma vez as empresas no precisariam renovar seu ecossistema de aplicativos para poder us-lo. J o requisito de aderncia ao padro POSIX se mostra necessrio para eventuais contratos com clusulas do tipo: o sistema operacional a ser utilizado deve estar de acordo com o padro POSIX. Os requisitos no-funcionais podem ainda ser divididos em trs tipos: de produto, de processo e externos. Os requisitos no-funcionais de produto podem, primeira vista, nos parecer os nicos que deveramos estudar. Isso se d por eles estarem diretamente relacionados qualidade do software e serem denidos como os requisitos que especicam as caractersticas que o software deve possuir. No entanto, devemos lembrar que a arquitetura de software no inuencia apenas a qualidade nal do software, mas tambm inuencia (e inuenciada pela) a forma com que ele desenvolvido e at mesmo a organizao em que ela est inserida. Denio 6.3 (requisito no-funcional de produto). Requisito que especica as caractersticas que um sistema ou subsistema deve possuir. Os requisitos no-funcionais de produto, como j dito anteriormente, so relacionados qualidade do software e so alcanados pelo que chamamos de atributos de qualidade. Portanto, quando existem requisitos em que o software
2
Note que no tivemos acesso ao documento de requisitos do Windows NT. No entanto, a estrutura de seu kernel deixa bem clara esta necessidade de retrocompatibilidade e aderncia ao padro POSIX. Para mais informaes sobre esse assunto, recomendamos a leitura do captulo A Tale of Two Standards do livro Open Sources 2.0 [24].
95
deve ter algum grau de conabilidade, certo nvel de ecincia, ou ser portvel para diversos sistemas operacionais, estamos descrevendo quais atributos de qualidade o software deve exibir. Todos os requisitos presentes no Exemplo 6.2 podem ser classicados como sendo de produto. Ainda retornaremos a esse assunto neste captulo, mas antes devemos mostrar os outros tipos de requisitos no funcionais. Os requisitos no-funcionais de processo so denidos como as restries ao processo de desenvolvimento. Denio 6.4 (requisito no-funcional de processo). Requisito que restringe o processo de desenvolvimento do software. Esse tipo de requisito encontrado em muitas situaes, principalmente em grandes empresas ou organizaes. Por exemplo, comum que o desenvolvimento de sistemas de software para o Exrcito Americano tenham como requisito ter o processo de desenvolvimento de acordo com a Joint Technical Architecture 3 Por m, h os requisitos no-funcionais externos. Esses, muitas vezes, podem se classicar tanto como de produto quanto de processo e so extrados do ambiente em que o sistema desenvolvido. Esse ambiente pode ser tanto a organizao, com polticas que devem ser seguidas ou seu atual ecossistema de software com o qual ele deve interoperar, quanto a legislao vigente do pas em que o sistema est operando. Denio 6.5 (requisito no-funcional externo). Requisito derivado do ambiente em que o sistema desenvolvido, que pode ser tanto do produto quanto do processo. Por m, como exemplo de requisitos externos, podemos citar: Exemplo 6.3. O sistema de recomendao de livros deve ler as informaes do sistema de aluguel de livros de uma biblioteca, onde cada registro de livro est de acordo com o padro Dublin Core. Um requisito no-funcional externo desse sistema de recomendao :
3
A Department of Defense Joint Technical Architecture (DoD JTA) [23] um documento que descreve um conjunto de normas a que um sistema deve aderir para facilitar a interoperabilidade com outros sistemas do Exrcito Americano. A ttulo de curiosidade, o DoD JTA contm algumas centenas de normas.
96
(RNF-01) O sistema deve guardar os dados dos livros recomendados em um modelo mapevel para o modelo de dados denido pelo padro Dublin Core [69]. Note que o uso do Dublin Core s realmente necessrio porque a comunicao entre os dois sistemas esperada e que um sistema j adota esse padro. Diferenas entre requisitos funcionais e no-funcionais Apesar da classicao dos requisitos de software em requisitos funcionais e no-funcionais ser bem aceita, devemos observar que na prtica essa diviso pode no ser to clara. Isso ocorre devido ao nvel de detalhes contido em sua descrio ou mesmo devido ao tipo de sistema desenvolvido. Podemos ilustrar o caso em que o nvel de detalhes faz a diferena com o seguinte exemplo: Exemplo 6.4. Se considerarmos um requisito de segurana de condencialidade (e normalmente considerado no-funcional): (RNF-01) O sistema deve possibilitar o envio de mensagens de modo que no possam ser lidas a no ser pelos destinatrios. Uma vez que no especica nenhuma funcionalidade, esse pode ser considerado um requisito no-funcional. Por outro lado, poderamos deixar essa evidente caracterstica de requisito no-funcional um pouco mais turva se adicionarmos um pouco mais de detalhes a ele: (RF-01) O sistema deve permitir aos usurios que criptografem suas mensagens usando as chaves pblicas dos destinatrios. Agora, esse requisito seria melhor classicado como funcional, uma vez que especica uma funo do sistema, apesar do atributo de qualidade exibido pelo software ao nal do desenvolvimento ser o mesmo: segurana, mais especicamente condencialidade das mensagens enviadas. J quando mencionamos que o tipo do sistema pode inuenciar em como classicamos um requisito, basta apenas lembrarmos dos sistemas de temporeal. Neles, a corretude do comportamento do sistema no depende s do
97
resultado lgico da funo, mas tambm quando esse resultado obtido. Portanto, uma resposta cedo ou tarde demais pode estar to incorreta quanto uma resposta logicamente errada. Exemplo 6.5. Em um sistema de informao, consideramos o requisito nofuncional: (RNF-01) A busca por nome deve retornar os resultados em no mximo 100 milissegundos. J em um sistema de controle de voo y-by-wire, devemos considerar o requisito a seguir como funcional, uma vez que respostas que no respeitam o intervalo de tempo especicado so to inteis quanto a falta de resposta dos sensores (podem causar a queda do avio): (RF-01) Novas amostras de dados dos sensores da aeronave devem ser obtidas a cada 20 milissegundos. Apesar disso, vale notar que ambos os requisitos presentes no Exemplo 6.5 ditam que tanto o sistema de informao quanto o sistema y-by-wire devem exibir o atributo de qualidade desempenho, mesmo que em graus diferentes. Conitos entre requisitos Como requisitos de software tm impacto em um ou mais atributos de qualidade, pode acontecer de impactarem em atributos relacionados a outros requisitos. Quando isso ocorre, o impacto pode resultar em reforo do atributo ou em conito. Podemos perceber que no surgem grandes problemas quando dois ou mais requisitos reforam o mesmo atributo de qualidade. Anal, caso isso ocorra, o design da soluo que atenda a um dos requisitos afetar apenas positivamente o design da soluo que atenda aos outros requisitos. Apesar do caso de requisitos que se reforam no ser muito comum, podemos ilustr-lo com requisitos que afetam a segurana do software, mais precisamente autenticidade e condencialidade: Exemplo 6.6. Se temos um sistema de mensagens instantneas com os seguintes requisitos: (RNF-01) O sistema deve prover meios de autenticar os seus usurios.
98
(RNF-02) Uma mensagem enviada a um usurio no pode ser lida a no ser pelo destinatrio. Podemos observar que os requisitos RNF-01 e RNF-02 se relacionam, uma vez que afetam a alguns aspectos de segurana do sistema. Eles se reforam visto que possvel encontrarmos uma soluo para RNF-01 que facilite RNF02 e vice-versa. A soluo no caso a utilizao criptograa de chave pblica: tanto ela pode ser usada para autenticao de usurios quanto pode ser usada para encriptao de mensagens. Por outro lado, requisitos conitantes so mais comuns e adicionam diculdade durante o design das solues. Isso ocorre porque a soluo para um requisito conitante afeta negativamente outro requisito. Assim, o design do software ter que considerar diversos trade-os a m satisfazer melhor aos requisitos mais importantes, j que atender a todos de forma tima no possvel. Se adicionamos alguns requisitos de usabilidade ao Exemplo 6.6, esses novos requisitos certamente afetaro negativamente a soluo apresentada. Isso ocorre porque comum que solues de segurana afetem aos requisitos de usabilidade, visto que essas solues adicionam conceitos no familiares aos usurios (por exemplo, chaves criptogrcas) ou adicionam mais passos para que os usurios realizem suas tarefas (por exemplo, inserir login e senha). Expressando requisitos no-funcionais Grande parte do trabalho de um arquiteto consiste em projetar sistemas que devem satisfazer requisitos no-funcionais. No entanto, a Engenharia de Requisitos limitada quanto a mtodos de anlise e derivao de requisitos no-funcionais. Essa limitao, muitas vezes, obriga o arquiteto a trabalhar com requisitos que carecem de mtricas e valores-alvo. Isso diculta o processo de design, uma vez que desconhecer requisitos o mesmo que desconhecer os objetivos do design. Por este motivo, recomenda-se aos arquitetos que sempre busquem por requisitos que possuam valores e mtricas bem denidos e, desta maneira, conheam e possam medir os objetivos e o sucesso de seu design. Todavia, nem sempre possvel trabalhar com requisitos bem denidos, uma vez que encontramos alguns problemas ao express-los. Os principais motivos da diculdade de expressar requisitos no-funcionais so os seguintes:
6.2 Atributos de qualidade
99
Alguns requisitos simplesmente no so conhecidos em etapas iniciais do ciclo de desenvolvimento. Por exemplo, a tolerncia a faltas ou o tempo de recuperao podem ser muito dependentes da soluo de design.
Alguns requisitos, como alguns relacionados usabilidade, so muito subjetivos, dicultando bastante a medio e o estabelecimento de valores-alvo. E, por m, h os conitos entre requisitos. Como j foi apresentado, requisitos podem inuenciar atributos de qualidade comuns ou relacionados, at fazendo com que requisitos sejam contraditrios. Mesmo sendo difcil lidar com os requisitos no-funcionais, obrigao do
arquiteto projetar o software de modo que, ao m do desenvolvimento, este exiba os atributos de qualidade esperados pelos stakeholders.

Apesar de armarmos que o software possui requisitos no-funcionais4 a serem atendidos, comum dizermos que o software exibe atributos de qualidade que atendem aos requisitos em questo. Portanto, atributos de qualidade esto mais relacionados aos objetivos j alcanados, enquanto requisitos so os objetivos propostos. Podemos chamar de atributos de qualidade do software suas propriedades externamente visveis. Essas propriedades podem se manifestar como: capacidades ou restries de suas funes. Por exemplo, tempo de resposta de uma determinada funo ou capacidade de execuo de certa quantidade de chamadas simultneas; caractersticas no diretamente relacionadas s suas funes. Por exemplo, usabilidade ou adoo de padres para interoperabilidade; ou ainda caractersticas relacionadas ao ciclo de desenvolvimento. Por exemplo, testabilidade ou mesmo a capacidade de facilitar o desenvolvimento por mltiplos times geogracamente distribudos. Denio 6.6 (atributo de qualidade). uma propriedade de qualidade do software ou de seu ciclo de desenvolvimento, podendo se manifestar como caractersticas, capacidades ou restries de uma funo especca ou de um conjunto de funes do software.
4
Alguns autores preferem o termo requisitos de qualidade.
100
Podemos perceber a importncia dos atributos de qualidade, em especial, quando comparamos dois produtos de software que tm as mesmas funcionalidades, como fazemos no exemplo a seguir: Exemplo 6.7. Vamos considerar um projeto para construo de sistemas de buscas de sites web chamado Hounder 5 . Para deixarmos nosso exemplo ainda mais signicativo em termos de diferenas entre atributos de qualidade, vamos considerar um sistema construdo usando o Hounder, mas em que todos os seus mdulos executam em apenas um servidor. Vamos chamar esse servio de busca de HSearch6 . Uma vez que o Google Web Search 7 tambm um servio de busca de web sites, podemos armar que ambos os servios tm o principal requisito funcional em comum: (RF-01) O sistema deve retornar endereos de web sites que se relacionem s palavras-chave inseridas pelo usurio. J que ambos os servios funcionam, percebemos que ambos atendem ao requisito (RF-01), o que poderia signicar algum grau de equivalncia entre os servios. No entanto, se compararmos como ambos os sistemas atendem a esse requisito, perceberemos que eles so bem diferentes, justamente pela diferena entre os atributos de qualidade que exibem. Para funcionar, um servio de busca de web sites deve executar basicamente trs atividades: (a) crawling, que a coleta de pginas que serviro de resultados, (b) indexao, que a organizao da informao obtida na atividade de crawling de forma que facilite a busca (principalmente em termos de desempenho), e (c) busca, cujo resultado a realizao do requisito RF-01. Note que as trs atividades so I/O bound, ou seja, as atividades tm uso intensivo de entrada e sada. Portanto, elas tm seu desempenho limitado pela capacidade de entrada e sada dos recursos computacionais em que executam. Se compararmos as capacidades de ambos os sistemas, o HSearch est limitado capacidade do nico computador em que est executando. Isso signica que ele executa as trs atividades usando o mesmo recurso. Por outro lado, bem conhecido que a arquitetura do Google Web Search permite que
5 6
Hounder : http://hounder.org/ Caso o leitor deseje criar um clone do HSearch, basta seguir o tutorial de cinco minutos presente em http://code.google.com/p/hounder/wiki/5minuteTutorial Google Web Search : http://www.google.com
101
o sistema utilize diversos data centers ao redor do mundo, usando muitos milhares de processadores simultneos e, assim, podendo dividir a execuo das trs atividades entre esses recursos. Por essa diferena de utilizao de recursos, algumas mtricas de vrios atributos de qualidade, como tempo de resposta, capacidade de atender a buscas simultneas, tamanho do ndice de busca ou tolerncia a falhas de hardware sero bem diferentes entre os dois sistemas. Quando comparamos as bilhes de consultas dirias que o Google Web Search capaz de realizar com as apenas milhares ou poucos milhes do HSearch, dizemos que o desempenho do primeiro melhor. Mas o desempenho no diferente apenas em termos de operaes por unidade de tempo, mas tambm quando comparamos os tempos de resposta para cada operao ou nmero de usurios simultneos no sistema. Se considerarmos que o Google Web Search realiza um bilho de buscas por dia e cada busca dura em torno de 300 milissegundos, pela Lei de Little [55], temos cerca de 3500 buscas simultneas a qualquer momento ao longo da vida do sistema. J o HSearch s consegue realizar 3,5 buscas simultneas ao realizar 1 milho de buscas por dia a 300 milissegundos cada. Mas h outros atributos que podem ser mencionados. O HSearch dependente do funcionamento de um nico servidor. Portanto, se esse servidor falhar, todo o sistema car fora do ar. J o Google Web Search capaz de tolerar falhas de hardware, uma vez que no depende de apenas um servidor para funcionar. Assim, podemos dizer que o grau de conabilidade ou tolerncia a falhas do Google Web Search maior que o do HSearch. As respostas do HSearch so formadas apenas pelo ttulo e pequenos trechos dos web sites que contm as palavras-chave. J o Google Web Search ajuda ao usurio tambm mostrando imagens contidas no site ou mesmo trechos de vdeo, contribuindo assim para sua usabilidade. Por m, citamos tambm que o Google Web Search apresenta o atributo de integrabilidade, dado que ele contm diversos servios alm da busca numa mesma interface: entre eles calculadora, previso do tempo, converso de medidas, denio de palavras, busca de sinnimos, entre outros. a arquitetura que permite que o software exiba os atributos de qualidade especicados. J que a especicao dos atributos feita pelos requisitos (normalmente no-funcionais), requisitos e atributos de qualidade partilham
102
diversas caractersticas. Tanto que alguns autores usam ambas as expresses com o mesmo sentido. As principais caractersticas dos atributos de qualidade so as seguintes: Atributos de qualidade impem limites s funcionalidades; Atributos de qualidade se relacionam entre si; e Atributos de qualidade podem tanto ser de interesse dos usurios quanto dos desenvolvedores.
6.2.1 Limites s funcionalidades Os limites s funcionalidades acontecem da mesma forma que os requisitos podem restringir ou mesmo impedir funcionalidades, pois atributos de qualidade no se manifestam isolados no ciclo de vida do software, mas inuenciam e so inuenciados pelo meio. Por exemplo, para que o SASF tenha um time to market pequeno, ele deve ser lanado inicialmente sem possuir um cliente de streaming para dispositivos mveis, deixando para implementar essa funcionalidade em outras verses. Isso uma limitao na funcionalidade de transmisso de lmes em benefcio do atributo de qualidade custo e planejamento. tambm bastante comum encontrarmos sistemas que tm funcionalidades podadas simplesmente porque, se estas existissem, o software no exibiria os atributos de segurana esperados. 6.2.2 Relaes entre atributos de qualidade Como j foi observado, os atributos no existem isoladamente e, por afetarem partes em comum da arquitetura, afetam tambm outros atributos de qualidade. Eis que surgem os trade-os entre os atributos de qualidade. Por exemplo, um sistema mais portvel ter seu desempenho afetado negativamente, pois necessita de mais camadas de software que abstraiam o ambiente que pode ser mudado. J no caso do SASF, para se obter um nvel de segurana capaz de realizar autorizao e autenticao, a usabilidade do software prejudicada, uma vez que o usurio deve ser obrigado de lembrar sua senha ou mesmo ter o uxo de aes interrompido para que insira suas credenciais. papel do arquiteto conhecer e resolver os trade-os entre os atributos de qualidade durante as fases de design e implementao. Por isso, ao apresentar algumas tcnicas para alcance da qualidade, apresentaremos tambm quais atributos so inuenciados positiva e negativamente.
6.3 Modelo de Qualidade
103
6.2.3 A quem interessa os atributos de qualidade Uma grande gama de atributos podem ser citados. Tanto que, a seguir, quando apresentamos uma lista deles, restringiremo-nos a apenas um modelo de qualidade. Esses atributos podem interessar a vrios envolvidos no ciclo de vida do software, como usurios e desenvolvedores. Dos exemplos citados anteriormente, podemos dizer que desempenho e usabilidade so atributos importantes a usurios, enquanto custo e planejamento so mais importantes aos desenvolvedores.

Para avaliar a qualidade de um software, o ideal seria usar todos os atributos de qualidade que conhecemos. No entanto, invivel adotar esta abordagem em um processo de desenvolvimento que possua tempo e dinheiro nitos devido grande quantidade de dimenses8 do software que poderamos avaliar. Para facilitar o processo de avaliao durante o desenvolvimento, foram desenvolvidos o que chamamos de modelos de qualidade. Modelos de qualidade tm como objetivo facilitar a avaliao do software, organizando e denindo quais atributos de qualidade so importantes para atestar a qualidade geral do software. Alguns exemplos signicativos de modelos de qualidade so os de Boehm [8], o de McCall [59] e o contido no padro ISO/IEC 9126-1:2001 [41]. Vamos descrever melhor este ltimo, para assim termos uma melhor noo de quais atributos de qualidade procuramos que a arquitetura permita ao software. Denio 6.7 (modelo de qualidade). Modelo que dene e organiza os atributos do software importantes para a avaliao de sua qualidade. 6.3.1 Padro ISO/IEC 9126-1:2001 Ele um padro internacional para avaliao de software. O que nos interessa dele o contedo de sua primeira parte, que o que chamado de qualidades
8
Em Ingls, alguns autores se referem aos atributos de qualidade usando o suxo -ilities, que comum ao nome de vrios atributos. Podemos perceber isso na lista de qualidades presente no endereo: http://en.wikipedia.org/wiki/Ilities . Em Portugus, poderamos nos referir a -idades, mas preferimos usar dimenses, propriedades ou mesmo qualidades.
104
internas e externas do software. Essas qualidades so apresentadas na forma de uma lista exaustiva de caractersticas ou atributos de qualidade. Os atributos que um software deve possuir para que possamos dizer que ele de qualidade so os seguintes: Funcionalidade Conabilidade Usabilidade Ecincia Manutenibilidade Portabilidade importante enfatizar que essa lista tem como objetivo ser exaustiva. Portanto, de acordo com a norma, todas as qualidades que venham a ser requisitadas ao software esto presentes nessa lista. No padro, cada caracterstica ainda quebrada em subcaractersticas, que so mais especcas, a m de facilitar o entendimento e a avaliao. A seguir, denimos cada atributo de qualidade e mostramos algumas subcaractersticas mais importantes ao atributo. Funcionalidade Funcionalidade a capacidade do software de realizar as funes que foram especicadas. Esse primeiro atributo pode parecer bvio, mas seu propsito claro quando passamos a avaliar um sistema de software: se esse sistema faz menos que o mnimo que esperado dele, ele no serve, mesmo que o (pouco) que ele faa, ele faa de forma usvel e convel ou ecientemente. Para caracterizarmos melhor a funcionalidade do software, devemos ainda considerar as caractersticas de: adequao, ou capacidade de prover as funes necessrias para os objetivos dos usurios. Podemos observar que a mtrica deste atributo de qualidade a satisfao ou no dos requisitos funcionais do sistema. Exemplo 6.8. Para se adequar s necessidades de seus usurios, basta que o SASF atenda a seus requisitos funcionais. Se ele realizar a locao e a transmisso de lmes, ele est adequado s necessidades de seus usurios comuns. Por outro lado, para se adequar s necessidades dos usurios que
105
distribuem os lmes, uma das funes que ele deve prover a funo de upload de lmes. preciso, ou capacidade de prover os resultados com o grau de preciso adequado. Para que seja possvel medir a preciso, necessrio que ela esteja especicada possivelmente no documento de requisitos. Exemplo 6.9. Podemos observar diferentes necessidades de preciso quando comparamos como os nmeros so tratados em um sistema de software bancrio e numa calculadora. No primeiro, os nmeros so tratados apenas como racionais e truncados na quantidade de casas decimais relativa moeda do pas. No Brasil, por exemplo, o software bancrio s reconhece at centavos de Real. Portanto, se necessrio dividir R$ 1,00 em trs parcelas, cada parcela no ser representada pela dzima R$ 0,33333..., mas sim por R$ 0,34. Essa mesma preciso no poderia ser adotada em um software de calculadora. Nesse, sendo uma calculadora comum, esperado que os nmeros seja representados da forma mais prxima aos nmeros reais9 . interoperabilidade, ou capacidade de interagir com outros sistemas. Para medir o grau de interoperabilidade, o ideal que esteja especicado quais sistemas devem interagir. J para facilitar a satisfao desse atributo, a soluo mais utilizada a adoo de padres de facto. Alguns tipos de padres so os de representao de dados, como o Dublin Core ou formatos de arquivos de vdeo, ou padres de especicao de funcionalidades, como os padres WS-*.10 Exemplo 6.10. uma qualidade do SASF ser capaz de interagir com diversos sistemas capazes de reproduzir o vdeo transmitido. Para isso, foi escolhido o padro para transmisso de vdeo amplamente adotado entre sistemas. segurana, ou capacidade de funcionar segundo os princpios de autenticao, autorizao, integridade e no-repudiao. Autenticao a capa9
10
Possivelmente, a calculadora implementar o padro para aritmtica de pontoutuante IEEE 754-2008 [40] A comunidade interessada em web services especicou uma srie de padres que facilitam a interoperabilidade entre os servios. Podemos encontrar uma grande lista deles no seguinte endereo: http://bit.ly/kIEXs .
106
cidade de o sistema vericar a identidade de usurios ou de outros sistemas com que se comunica. Autorizao a capacidade de garantir ou negar direitos de uso a recursos a usurios autenticados. Integridade a capacidade de garantir que os dados no foram alterados indevidamente, principalmente durante a comunicao. E no-repudiao a capacidade de prover meios para a realizao de auditoria no sistema. No entanto, importante observar que nem todos os sistemas precisam estar de acordo com todos os princpios. Exemplo 6.11. Uma vez que recebe o nmero do carto do usurio para receber o pagamento, o SASF deve garantir que apenas o sistema de cobrana da operadora de carto de crdito seja capaz de vericar as informaes necessrias para a autorizao. Outro aspecto de segurana do SASF que ele precisa diferenciar os usurios que ainda no esto registrados (e, consequentemente, que no pagaram a assinatura), dos j registrados. Para isso, ele deve realizar a autenticao do usurio. estar de acordo com padres, ou a capacidade de aderir a normas, convenes ou leis relacionadas funcionalidade. Exemplo 6.12. Para ser executado no Brasil, o SASF obrigado por lei a emitir o cupom scal do pagamento da assinatura do usurio. Conabilidade Quando armamos que um sistema convel, estamos armando que esse sistema capaz de manter algum nvel de desempenho quando funcionando sob circunstncias determinadas. A conabilidade normalmente denida sob perodos de tempo. Ou seja, dizer apenas que o SASF deve ser convel no suciente. Temos, por exemplo, que dizer que o SASF capaz de transmitir vdeos para 6 mil usurios simultneos sob condies normais durante 99% do ano e para mil usurios simultneos durante o 1% do ano reservado para o perodo de manuteno dos servidores. Vale observar que, para uma loja online, faz mais sentido que a medida de conabilidade seja a de servir aos seus usurios com o tempo de espera das operaes de compra e busca de 50 milissegundos durante perodos normais do ano, mas, durante as semanas prximas ao Natal, ter o tempo de espera das mesmas operaes em torno
107
dos 150 milissegundos, uma vez que o nmero de usurios simultneos nessa poca do ano aumenta consideravelmente. A conabilidade pode ainda ser dividida nas seguintes caractersticas: maturidade, ou capacidade de se prevenir de falhas resultantes de faltas de software. Isso comum em sistemas distribudos, onde um componente no cona completamente no resultado provido por outro. Isso pode ser vericado em sistemas com sensores de software, onde um mdulo pode ser responsvel por julgar os valores gerados pelos sensores. Caso os valores sejam julgados invlidos, o mdulo pode simplesmente desligar o sensor defeituoso. A medio do grau de maturidade de um sistema bem difcil, mas podemos ter uma noo ao analisarmos decises que foram feitas com este objetivo. Exemplo 6.13. No caso do SASF, o mdulo de transmisso de vdeo pode vericar quantas conexes esto abertas para um mesmo destinatrio. Uma grande quantidade de conexes para um mesmo destinatrio pode signicar um ataque ou mesmo um bug no reprodutor de vdeo no lado do cliente que, eventualmente, pode consumir todos os recursos disponveis para streaming. Assim, ao detectar esse problema, o SASF pode recusar abrir novas conexes para esse cliente, prevenindo-se de um problema maior, como uma completa parada por DoS 11 tolerncia a faltas, ou capacidade de manter alguma qualidade de servio em caso de faltas de software ou comportamento imprevisto de usurios, software ou hardware. Em outras palavras, a medida de funcionamento do software, mesmo que de forma restrita, em caso de a parada de servidores, parties de rede, falhas de discos rgidos, insero ou leitura de dados corrompidos, etc. Considerando a grande quantidade de eventos que o software deve tolerar, tambm so muitas as formas de medir o grau de satisfao a este atributo de qualidade. As formas mais comuns so: medir se o servio continua funcionando em caso de falha de n servidores, medir qual a variao no tempo de resposta para as operaes mais comuns ou quantos usurios simultneos o sistema capaz de servir em caso de falhas de servidores ou
11
O Denial of Service ou DoS ocorre quando o sistema no pode atender a novas requisies porque todos os seus recursos esto sendo consumidos, possivelmente devido a um ataque de um ou vrios agentes maliciosos.
108
ainda vericar como o sistema se comporta se dados invlidos so inseridos no sistema. Exemplo 6.14. A forma mais comum de melhorar o grau de tolerncia a faltas em um servio web fazer com que no dependa de um nico recurso. Seja esse recurso hardware, como um nico processador, roteador ou disco rgido, seja esse recurso software, como depender de um nico banco de dados, um nico servio de cadastro ou um nico servio de inventrio. Assim, o SASF possui seus mdulos replicados em diferentes servidores. Desta maneira, ele evita a dependncia de um nico recurso, ou o chamado ponto nico de falhas e pode continuar a funcionar mesmo que um desses mdulos pare por completo. Note que para a replicao funcionar, devem ser adicionados arquitetura mdulos responsveis pela vericao de estado dos servidores e, assim que forem detectados problemas em algum servidor, o trfego possa ser redirecionado para rplicas sadias. Para isso ser possvel, h ainda outras complicaes, como a manuteno da consistncia de estado entre o servidor original e sua rplica. Falaremos mais sobre a eliminao do ponto nico de falhas quanto estivermos tratando das diversas tcnicas para a obteno de atributos de qualidade. recuperabilidade, tambm chamada de resilincia, a capacidade de o sistema voltar ao nvel de desempenho anterior a falhas ou comportamento imprevisto de usurios, software ou hardware e recuperar os dados afetados, caso existam. comum medirmos o grau de recuperabilidade ao medirmos quanto tempo o sistema leva para voltar aos nveis normais de desempenho. Quanto menor esse tempo, melhor a qualidade do sistema neste sentido. Exemplo 6.15. No SASF, podemos medir o tempo de substituio de um servidor de streaming pelo tempo da deteco da falha, somado ao tempo de inicializao do servidor e somado ao tempo de redirecionamento das requisies de transmisso. Uma forma de ter o tempo total de recuperao minimizado seria manter o servidor auxiliar ligado, apenas esperando a deteco da falha do servidor principal. No entanto, essa deciso signicaria mais custos, uma vez que seriam dois servidores ligados ao mesmo tempo, gastando mais energia, diminuindo a vida til do hardware e possivelmente consumindo licenas de software.
109
Usabilidade Usabilidade a medida da facilidade de o usurio executar alguma funcionalidade do sistema. Essa facilidade est ligada diretamente compreensibilidade, facilidade de aprendizado, operabilidade, a quanto o usurio se sente atrado pelo sistema e adeso de padres de usabilidade, que so as subcaractersticas desse atributo de qualidade. Apesar de muitos desses critrios serem subjetivos, h maneiras de medi-los para termos noo da usabilidade do software. A seguir, mostramos as subcaractersticas da usabilidade: compreensibilidade, ou a capacidade de o usurio entender o sistema. Esta caracterstica est ligada quantidade de conceitos que o usurio precisa saber previamente para lidar com o sistema ou qualidade ou quantidade da documentao do sistema. A compreensibilidade serve para o usurio discernir se o software serve para ele ou no. facilidade de aprendizado est ligada diretamente compreensibilidade. No entanto, neste caso, a qualidade a de o usurio aprender a usar o software, caso ele saiba que o software serve para ele. As mtricas dessa qualidade tambm esto relacionadas quantidade de conceitos ou operaes que o usurio precisa aprender para fazer com que o software funcione. operabilidade a capacidade de o usurio operar ou controlar o sistema. Esta qualidade muito importante em grandes sistemas de software, onde h um tipo de usurio que o administrador do sistema. O administrador deseja ser capaz de realizar operaes sobre o sistema que, comumente, no esto entre as funes que interessam aos usurios mais comuns: ligar, desligar ou vericar estado de servidores, realizar backup dos dados, etc. Em sistemas de redes sociais, por exemplo, entre os servios providos ao operador, ainda esto a possibilidade de expulsar usurios do sistema ou moder-los, no permitindo que esses usurios realizem algumas funes, como enviar mensagens ou mesmo barrando conexes de acordo com o endereo de origem. Ecincia A ecincia ou desempenho talvez a qualidade mais buscada durante o desenvolvimento de software, uma vez que ela a mais percebida pelos usurios. Ela a qualidade relacionada ao uso de recursos do sistema quando esse prov
110
funcionalidade e tambm a com que os desenvolvedores mais se preocupam. Quando queremos medir ecincia, medimos basicamente duas caractersticas: comportamento no tempo ou desempenho, ou a capacidade do sistema de alcanar a resposta dentro do perodo de tempo especicado. Aqui, referimo-nos a tempos de resposta, latncia, tempo de processamento, vazo (throughput ), etc. Vale observar que, ao medir essa caracterstica, devemos tambm entender as condies em que o sistema est operando. Anal, no Exemplo 6.7, mesmo que o HSearch tenha um tempo de resposta menor que o Google Web Search, o primeiro capaz de servir a apenas um milsimo da quantidade de usurios servida pelo segundo. uso de recursos, que a capacidade de o software exigir mais ou menos recursos de acordo com suas condies de uso. Normalmente, essa caracterstica tambm chamada de escalabilidade e pode tambm ser vista de outra maneira: como a adio ou remoo de recursos no sistema vai melhorar ou piorar as condies de uso. Existem dois tipos mais comuns de escalabilidade, que tambm servem para facilitar o entendimento dessa caracterstica: escalabilidade vertical e escalabilidade horizontal . Eles podem ser melhor explicados por meio de um exemplo: Exemplo 6.16. Vamos considerar um sistema servidor de arquivos. Esse servidor de arquivos usa apenas um disco rgido e capaz de servir a cinco usurios simultneos, cada um usando 10 MB/seg de banda passante (fazendo upload ou download ). Vamos desconsiderar os efeitos da rede que liga os clientes ao servidor ou qualquer outro gargalo. Podemos dizer que as condies de uso do software so: 5 usurios simultneos a 10 MB/seg cada. No Exemplo 6.16, uma forma de melhorar as condies de uso, ou mais especicamente, aumentar a quantidade de usurios simultneos, seria seria substituir um dos recursos do sistema por outro com maior capacidade. Ou seja, escalar verticalmente. Exemplo 6.16 ((continuao)). Vamos substituir o disco rgido do servidor por um que seja capaz de transferir arquivos no dobro da velocidade do anterior. Desta maneira, se o disco rgido fosse o nico fator limitante,
111
conseguiramos no mais servir 5 usurios a 10 MB/seg, mas sim 10 usurios simultneos a 10 MB/seg, como ilustrado na Figura 6.1. Alm disso, poderamos seguir melhorando verticalmente o sistema at encontrarmos um limite, que pode ser tanto o limite na velocidade possvel para um disco rgido quanto o limite nanceiro de comprarmos um disco mais rpido.
Figura 6.1. Escalando verticalmente um sistema.
Outra forma de escalar o sistema seria horizontalmente. Desta maneira, no substitumos um recurso por um melhor, mas adicionamos um novo recurso ao sistema de modo que ele faa uso tanto do recurso velho quanto do novo. Exemplo 6.16 ((continuao)). Ao invs de necessariamente comprar um disco rgido mais rpido, compramos um novo disco (que pode at ser igual ao anterior) e fazemos com que o software divida a carga de escrita e leitura entre os dois discos rgidos. Esta abordagem est ilustrada na Figura 6.2.
112
Figura 6.2. Escalando horizontalmente um sistema.
Note que a soluo do Exemplo 6.16 no vem de graa: alm da camada de software car mais complicada, h o impacto na ecincia possivelmente, o tempo de resposta ser afetado, uma vez que uma operao do usurio ter que agora decidir qual disco rgido usar. No entanto, a vantagem desta soluo reside no fato de que o teto de desempenho com a adio de novos discos ser mais alto que o teto alcanvel com discos mais rpidos.
113
Alm disso, h um limite de discos rgidos que podem ser utilizados por um mesmo sistema operacional. Para expandir ainda mais o limite de discos rgidos sendo usados simultaneamente, o prximo passo seria adicionar mais uma mquina servidora, o que deixaria o software ainda mais complexo, pois este agora teria que decidir entre discos presentes em mquinas diferentes e assim por diante. Esse apenas um exemplo de tcnica de se alcanar escalabilidade horizontal. No prximo captulo, quando falarmos de tcnicas de design, apresentaremos outras abordagens e padres de design para a escalabilidade. Manutenibilidade A manutenibilidade uma qualidade, s vezes, negligenciada pelos usurios, mas muito importante aos desenvolvedores. Ela a capacidade de o software ser modicado em seu processo de evoluo. Podemos citar as seguintes caractersticas do atributo de manutenibilidade: a analisabilidade, a modicabilidade e a testabilidade. analisabilidade : o grau de facilidade com que podemos procurar por decincias no software ou por partes que devem ser modicadas para algum m. Os nveis de modularidade, de separao de preocupaes e de acoplamento do software se relacionam a essa caracterstica. modicabilidade : a capacidade de realizar mudanas de implementao no sistema. Essa caracterstica tambm est relacionada s mtricas clssicas de software, como nveis de coeso e acoplamento e complexidade ciclomtica. Quanto mais modicvel o software, menor o impacto da mudana em reas teoricamente no relacionadas s mudanas. Exemplo 6.17. No SASF, por termos o mdulo de transmisso de vdeos separado do gestor de usurios, qualquer mudana ou adio nos formatos suportados para transmisso no deve afetar ao mdulo de usurios. Outra separao comum em sistemas web que tambm foi adotada no SASF a aplicao do padro Model-View-Controller (MVC)12 , que separa as interfaces de usurio de lgica de negcio. Isso permite modicaes na lgica de negcio que no afetam as interfaces de usurio e vice-versa.
12
Falamos mais do padro arquitetural MVC quando apresentamos as ferramentas de design de software no Captulo 7.
114
testabilidade : a capacidade de o software ter suas mudanas validadas. Para um software ser testvel, antes de tudo, devemos conhecer seus objetivos. Mas, alm disso, precisamos que o sistema seja capaz de executar de forma controlada a m de podermos medir os resultados obtidos a partir de entradas conhecidas. Sistemas pouco testveis so aqueles os quais sua execuo muito cara, pode custar vidas ou, simplesmente, no podemos medir seu comportamento deterministicamente. Vale observar que muitos sistemas distribudos, se mal projetados, podem se encaixar nesse ltimo tipo.
Portabilidade O ltimo atributo de qualidade presente no padro ISO/IEC 9126-1:2001 o de portabilidade. Esse atributo a medida de adaptaes necessrias para que o sistema tenha seus requisitos ou ambientes de execuo modicados, podendo ser o ambiente de software, de hardware ou organizacional. Esse atributo importante, por exemplo, para jogos, uma vez que desejvel que eles sejam capazes de executar no maior nmero de plataformas, mas tambm desejvel que o custo para tornar isso possvel seja baixo. Algo similar acontece com aplicativos para celulares. A necessidade de um aplicativo para celulares ser portvel existe porque comum que seus desenvolvedores queiram que ele esteja disponvel em dezenas de modelos diferentes. Isso signica que um mesmo aplicativo deve estar disponvel para dezenas de ambientes de hardware diferentes. Portanto, no faz sentido que o mesmo aplicativo seja reimplementado diversas vezes, mas sim que seja projetado de forma a minimizar o esforo para alterar o ambiente de hardware. A portabilidade pode ainda ser dividida nas seguintes caractersticas: adaptabilidade : a capacidade de o software ser portado para outro ambiente sem precisar de modicaes alm das previstas. Exemplo 6.18. O Vuze 13 um aplicativo escrito na linguagem de programao Java e que, por isso, capaz de executar em qualquer sistema operacional em que a mquina virtual Java (JVM) esteja disponvel. No entanto, apesar da portabilidade provida pela linguagem de programao em que foi escrito, ele necessita de uma pequena modicao especca
13
Vuze : http://www.vuze.com
6.4 Atributos de Negcio
115
para cada novo sistema operacional suportado pela JVM. Essa modicao consiste na criao de um instalador especco para o S.O., uma vez que diferentes sistemas possuem diferentes formas de instalao de software. No entanto, essa modicao prevista na arquitetura do Vuze e no afeta signicativamente sua adaptabilidade a novos sistemas operacionais. instalabilidade : a capacidade de o software ser instalado em algum ambiente especco. A instalabilidade medida junto com o ambiente-alvo. Portanto, por exemplo, antes do Apple Bootcamp, o sistema operacional Windows XP no era instalvel em ambientes Apple. J o sistema GNU/Linux, por sua vez, era instalvel tanto em PCs quanto em Macs. co-existncia : a capacidade de o software compartilhar recursos em um mesmo ambiente com outros sistemas.
6.3.2 Conitos entre atributos de qualidade Assim como os interesses de cada stakeholder no so isolados e podem afetar os de outro por meio dos requisitos no-funcionais, os atributos de qualidade no surgem isolados no software. Uma deciso arquitetural feita com o objetivo de alcanar um atributo de qualidade pode ter efeito em outros atributos. Por uma deciso arquitetural nunca ser isolada no design da arquitetura, o arquiteto deve sempre entender quais atributos a deciso afeta, seja positivamente ou negativamente, e fazer as devidas concesses caso ela afete atributos de qualidade conitantes. No Captulo 7, observaremos melhor as relaes entre os atributos de qualidade ao apresentarmos algumas tcnicas de design arquitetural para alcan-los. Isso acontece porque comum que essas tcnicas no afetem cada atributo de software isoladamente.
6.4 Atributos de Negcio

Apesar de a lista de atributos de qualidade apresentada anteriormente ter sido criada a m de ser exaustiva, h alguns atributos adicionais que merecem ser citados. So chamados os atributos de qualidade de negcio, que, apesar de no serem ligados diretamente ao software, tm grande inuncia sobre sua arquitetura. Eles so importantes porque inuenciam principalmente as decises de resoluo de conitos dos atributos apresentados anteriormente. Os atributos de negcio so:
116
mercado-alvo time-to-market custo e benefcio vida til do sistema agenda de lanamento
6.4.1 Mercado-alvo O arquiteto s capaz de priorizar os atributos de qualidade em seu design se conhecer o pblico e o mercado para o qual o software est sendo construdo. Por exemplo, portabilidade e funcionalidade so buscados para o pblico geral de um pacote de aplicativos de escritrio e, portanto, priorizados neste caso. Por outro lado, ao se construir um sistema de infraestrutura para uma empresa especca, o arquiteto pode priorizar a ecincia em detrimento da portabilidade e at mesmo da usabilidade, uma vez que os usurios comuns desse sistema so operadores qualicados. 6.4.2 Time-to-market Time-to-market o tempo entre a concepo do software e sua entrega no mercado. Esse atributo se torna importante, principalmente, quando a janela de oportunidade pequena devido a produtos concorrentes. O time-to-market inuencia e, quando curto, prioriza decises de compra e reuso de mdulos em detrimento do desenvolvimento in house ou de investimento em decises que dizem respeito a atributos considerados secundrios ao negcio. 6.4.3 Custo e benefcio Como os recursos nanceiros para se desenvolver o software so limitados, cada deciso arquitetural deve ter seu custo e o benefcio proporcionado analisados e, com base nessa anlise, priorizados ou at mesmo descartados. Essa anlise deve levar em conta o ambiente de desenvolvimento em questo: capacidades do time de desenvolvimento, ferramentas disponveis para o reuso e os objetivos do software.
6.5 Design Arquitetural para Qualidade de Software
117
6.4.4 Vida til O design de sistemas de grande vida til deve priorizar diferentes atributos de qualidade se os compararmos com o design de sistemas de vida mais curta, como prottipos. No primeiro tipo de sistemas, atributos de manutenibilidade e portabilidade so mais valorizados; no segundo, so priorizados atributos de ecincia e funcionalidade. 6.4.5 Agenda de lanamento O design do software muito dependente de como ele vai ser disponibilizado a pblico. Por exemplo, se o software ser disponibilizado em fases distintas que englobaro diferentes conjuntos de funcionalidades, ele deve ser dividido de modo que funcione sem as partes que ainda no foram disponibilizadas, mas que tambm facilite tanto a modicabilidade, uma vez que desejvel que novas funcionalidades sejam adicionadas com menor esforo, quanto a interoperabilidade entre diferentes verses, que eventualmente ocorrer. J se o software ser disponibilizado sem possibilidade de posterior atualizao, como acontece em muitos sistemas embarcados, preocupaes de modicabilidade e interoperabilidade entre verses podem ser descartadas.

A principal responsabilidade do arquiteto a de conceber o design que possibilite ao software ser construdo de modo que satisfaa os requisitos de qualidade impostos pelos stakeholders. Para que o processo de design arquitetural tenha sucesso, essencial que o arquiteto conhea os objetivos do software, ou seja, conhea os requisitos funcionais e de qualidade para os quais ele est projetando. Alm disso, ele deve conhecer tanto as tcnicas e prticas de design arquitetural que podem ajud-lo na concepo da arquitetura. Ele deve tambm conhecer como documentar a arquitetura projetada, uma vez que preciso comunic-la aos outros membros do time de desenvolvimento. Neste captulo, ns aprendemos sobre os objetivos que devem ser alcanados pelo design da arquitetura e esperamos que o leitor agora seja capaz de:
118
Identicar o que so atributos de qualidade e qual sua inuncia na arquitetura de software; Relacionar atributos de qualidade com algumas decises arquiteturais que os proporcionam; e Entender quais os atributos de qualidade e como eles se relacionam. A seguir, no Captulo 7, apresentaremos tcnicas e prticas de design que
o arquiteto deve conhecer para projetar sistemas com determinados atributos de qualidade. Por m, no Captulo 8, apresentaremos como documentar o design arquitetural.
Referncias
Requisitos funcionais e no-funcionais Os livros Software Engineering [79], de Sommerville, Requirements Engineering: Processes and Techniques [46], de Sommerville e Kotonya, Software Engineering: A Practitioners Approach [70], de Pressman, dedicam alguns captulos a este assunto. No entanto, o foco desses livros no papel dos requisitos de software no processo de desenvolvimento. J o artigo Dening Non-Functional Requirements [57], de Malan e Bredemeyer, mais voltado inuncia dos requisitos na arquitetura. Diferenas entre requisitos funcionais e no-funcionais A discusso sobre a inexistncia de diferenas prticas entre requisitos funcionais e no-funcionais pode ser encontrada tanto no livro Requirements Engineering: Processes and Techniques [46], de Sommerville e Kotonya, quanto no artigo Distinctions Between Requirements Specication and Design of RealTime Systems [43], de Kalinsky e Ready, e no livro Real-Time Systems: Design Principles for Distributed Embedded Applications [45], de Kopetz. Essa discusso se mostra bastante presente em sistemas de tempo-real porque os requisitos de desempenho denem a funcionalidade desses sistemas ao contrrio do que encontramos, por exemplo, em sistemas de informao, onde os requisitos de desempenho so considerados requisitos no-funcionais.
119
Atributos de Qualidade Bass et al, no livro Software Architecture in Practice [6], mostra o papel dos atributos de qualidade na arquitetura de software. Alm dele, Gorton faz uma pequena introduo a este assunto ao tratar do estudo de caso presente em Essential Software Architecture [35]. Os livros Software Systems Architecture [72], de Rozanski e Woods, e Code Complete [60], de Steve McConnell, tambm dedicam sees aos atributos de qualidade de software, sendo o primeiro em nvel de design arquitetural e o segundo em nvel de design detalhado. Atributos de Negcio Por m, podemos encontrar informaes sobre atributos de qualidade de negcio nos livros Software Architecture in Practice [6], de Bass et al, e Beyond Software Architecture [38], de Hohmann.
Exerccios
6.1. O que so requisitos funcionais e no-funcionais? Qual sua inuncia no projeto arquitetural? 6.2. Descreva brevemente como mudanas nos requisitos no-funcionais podem acarretar mudanas no projeto arquitetural. Exemplique. 6.3. Cite mais exemplos em que a diferena entre requisitos funcionais e nofuncionais no muito evidente. 6.4. Descreva casos em que os requisitos relacionados a diferentes stakeholders entram em conito. 6.5. Quais so as diculdades encontradas no processo de identicao de requisitos no-funcionais? 6.6. Como os atributos de qualidade se manifestam no software? Cite exemplos. 6.7. Faa uma comparao entre dois produtos de software de forma que possamos observar que, apesar de ambos os produtos possurem requisitos funcionais semelhantes, seus os atributos de qualidade se mostram bem diferentes.
120
6.8. Descreva casos em que requisitos de qualidade limitam os requisitos funcionais durante o ciclo de vida do software. 6.9. Descreva casos em que requisitos de qualidade limitam outros requisitos de qualidade durante o ciclo de vida do software. 6.10. Em que diferem os modelos de qualidade descritos por Boehm [8] e por McCall [59] em relao ao apresentado no captulo? 6.11. Escolha alguns atributos de qualidade e descreva brevemente uma arquitetura que implementa esses atributos. 6.12. Cite quais stakeholders so mais afetados pelos atributos de negcio e descreva como eles so afetados.
7 Tcnicas de Design Arquitetural
Ao introduzirmos design de software, citamos alguns princpios e tcnicas que so fundamentais ao processo, pois facilitam a representao e a escolha da soluo entre as alternativas de design. No entanto, no fomos explcitos sobre como estes princpios e tcnicas so fundamentais ao processo de design arquitetural. J no captulo sobre atributos de qualidade, mencionamos a existncia de tticas arquiteturais que ajudam na implementao de alguns requisitos de qualidade, mas no apresentamos essas tticas a no ser de forma breve e apenas por meio de exemplos. Este captulo, por sua vez, tem como objetivo tanto apresentar os princpios de design em nvel arquitetural, quanto apresentar algumas tticas arquiteturais que implementam requisitos de qualidade. Neste captulo, descrevemos os seguintes princpios de design arquitetural: uso da abstrao ou nveis de complexidade; separao de preocupaes; e uso de padres e estilos arquiteturais.
Em relao s tticas arquiteturais, apresentamos as que implementam os seguintes atributos de qualidade: desempenho e escalabilidade; segurana; tolerncia a faltas; compreensibilidade e modicabilidade; e operabilidade.
122
7.1 Princpios e Tcnicas de Design Arquitetural

H alguns princpios e tcnicas que, quando aplicados, geralmente resultam em boas solues de design. Entre eles, podemos citar: diviso e conquista, abstrao, encapsulamento, modularizao, separao de preocupaes, acoplamento e coeso, separao de interfaces de suas implementaes, entre outros. Inclusive, muitos destes j foram apresentados no Captulo 2, mas sem o devido foco em design arquitetural. Por isso, nesta seo, descrevemos novamente alguns deles, desta vez mostrando seu papel na arquitetura. Os princpios e tcnicas que apresentamos a seguir so trs: uso da abstrao ou nveis de complexidade, separao de preocupaes e uso de padres e estilos arquiteturais. 7.1.1 Abstrao Abstrao a seleo de um conjunto de conceitos que representam um todo mais complexo. Por ser um modelo do software, a arquitetura j elimina, ou em outras palavras, abstrai naturalmente alguns detalhes do software. Por exemplo, comum que no tenhamos decises em nvel algortmico na arquitetura. Mesmo assim, podemos tirar proveito do uso de nveis de detalhe (ou de abstrao) ao projet-la. Podemos nos beneciar do uso da abstrao ao realizarmos o processo de design de forma iterativa, onde cada passo realizado em um nvel de detalhe. De forma simplicada, podemos dizer que a sequncia de passos pode ocorrer seguindo duas estratgias de acordo com os nveis de abstrao do software. A primeira estratgia a top-down (do nvel mais alto de abstrao para o mais baixo). Se o design ocorre no sentido top-down, o arquiteto usa elementos e relaes arquiteturais descritos em alto nvel de abstrao para iniciar o projeto da arquitetura. No primeiro nvel de abstrao, o mais alto, comum que os elementos arquiteturais usados no projeto mostrem apenas o que realizam e no como realizam suas responsabilidades. A partir da, a cada passo do processo, o arquiteto segue renando o design, adicionando mais detalhes aos elementos arquiteturais e s suas relaes, at que possuam informaes sobre como realizar suas responsabilidades. Neste ponto, comum termos elementos arquiteturais que realizam funes e servios mais bsicos ou de infraestrutura e que, eventualmente, faro parte da composio das funcionalidades em nveis mais altos.
123
Um problema recorrente ao se aplicar a estratgia top-down o de quando parar. Anal, podemos notar que o arquiteto poderia seguir indenidamente adicionando detalhes arquitetura at que o design deixe de ser um modelo para ser o prprio sistema. Para denir o ponto de parada do processo de adio de detalhes, o arquiteto deve avaliar se o nvel atual de abstrao contm ou no informaes sucientes para guiar o time de desenvolvimento na implementao dos requisitos de qualidade do software. Devemos ainda observar que os dois extremos da condio de parada podem trazer desvantagens: se as informaes presentes na arquitetura so insucientes, a liberdade proporcionada ao design de baixo nvel pode resultar numa soluo que no implementa os requisitos de qualidade esperados. Por outro lado, se so excessivas, a arquitetura pode: (1) custar mais tempo do que o disponvel para ser projetada; (2) desmotivar o time de desenvolvimento, por engessar o design de baixo nvel pela grande quantidade de restries; e (3) ser invivel, por ter sido projetada sem o conhecimento que muitas vezes s pode ser obtido durante o processo de implementao1 . A outra estratgia, mais usada por quem possui experincia no domnio do problema, a bottom-up. Esta estratgia consiste em denir elementos arquiteturais bsicos e com maior nvel de detalhe (servios ou funes de infraestrutura, por exemplo), e compor servios presentes em maiores nveis de abstrao a partir desses elementos. A experincia no domnio do problema necessria justamente na denio dos elementos mais detalhados, ou seja, experincia necessria para denir o nvel de abstrao mais baixo que servir de ponto de partida do processo de design. Nesta estratgia, detalhes excessivos ou insucientes no nvel mais baixo de abstrao trazem as mesmas desvantagens j apresentadas quando falamos sobre o ponto de parada da estratgia top-down. 7.1.2 Separao de preocupaes A separao de preocupaes a diviso do design em partes idealmente independentes. Entre estas partes, podemos citar aspectos funcionais e nofuncionais do sistema. Os aspectos funcionais, como de se esperar, so o que
1
Devemos nos lembrar que alguns requisitos de qualidade no so completamente conhecidos em etapas iniciais do ciclo de desenvolvimento. Por exemplo, a tolerncia a faltas ou o tempo de recuperao podem ser muito dependentes da soluo de design de baixo nvel.
124
o sistema capaz de fazer. J os no-funcionais so os aspectos de qualidade do sistema, como desempenho, segurana, monitorao, etc. A separao dos diferentes aspectos permite que cada uma das partes seja um problema de design a ser resolvido de forma independente, permitindo maior controle intelectual por parte do arquiteto, uma vez que agora ele s precisa se focar em um aspecto da arquitetura de cada vez. Vale observar que a separao completa das diferentes preocupaes (ou dos diferentes aspectos) da arquitetura do software o caso timo da aplicao deste princpio, mas no o caso comum. Isto ocorre porque, como j vimos anteriormente, diferentes funcionalidades e qualidades do software se relacionam entre si. Portanto, apesar de ser vantajoso pensar na soluo de design de cada aspecto separadamente, o arquiteto deve tambm projetar a integrao desses aspectos. Esta integrao fundamental por dois motivos. O primeiro, mais bvio, que o software composto por seus aspectos trabalhando em conjunto e no separadamente. J o segundo motivo que a prpria integrao inuencia nas diferentes solues de design dos aspectos do software. Por exemplo, aspectos de armazenamento devem estar de acordo com aspectos de segurana do software, ou aspectos de desempenho devem trabalhar em conjunto com aspectos de comunicao ou mesmo localizao dos elementos da arquitetura. 7.1.3 Padres e estilos arquiteturais Outro princpio muito usado durante o processo de design arquitetural o uso de padres. Os padres podem ser considerados como experincia estruturada de design, pronta para ser reusada para solucionar problemas recorrentes. Um padro de design arquitetural dene elementos, relaes e regras a serem seguidas que j tiveram sua utilidade avaliada em solues de problemas passados. A principal diferena entre um padro arquitetural2 e um padro de design que o primeiro lida com problemas em nvel arquitetural, se tornando assim mais abrangente no software. Por outro lado, a aplicao de um padro de design tem efeito mais restrito na soluo. Mais uma vez, devemos lembrar que essa diviso no absoluta e que podemos encontrar padres inicialmente descritos como arquiteturais tendo efeito apenas local no design e vice-versa.
Tambm chamado de estilo arquitetural.
125
De acordo com McConnell3 , podemos citar os seguintes benefcios do uso de padres em um projeto: Padres reduzem a complexidade da soluo ao prover abstraes reusveis. Um padro arquitetural j dene elementos, servios e relaes arquiteturais, diminuindo assim a quantidade de novos conceitos que devem ser introduzidos soluo. Padres promovem o reuso. Como padres arquiteturais so solues de design para problemas recorrentes, possvel que a implementao (parcial ou total) do padro j esteja disponvel para reuso, facilitando o desenvolvimento. Padres facilitam a gerao de alternativas. Mais de um padro arquitetural pode resolver o mesmo problema, s que de forma diferente. Portanto, conhecendo diversos padres, um arquiteto pode avaliar e escolher qual ou quais padres iro compor a soluo do problema, considerando os benefcios e analisando as desvantagens proporcionadas por eles. Padres facilitam a comunicao. Padres arquiteturais facilitam a comunicao da arquitetura porque descrevem conceitos e elementos que estaro presentes no design. Portanto, se uma soluo de design contm padres que so conhecidos por todos os participantes da comunicao, os elementos e conceitos denidos pelos padres no precisam ser explicitados, uma vez que os participantes j devem conhec-los tambm. A seguir, citamos alguns padres arquiteturais que foram popularizados por Buschmann et al 4 : Layers (ou Camadas): este padro dene a organizao do software em servios agrupados em camadas de abstrao. As camadas so relacionadas de modo que cada uma s deve se comunicar com a camada adjacente acima ou abaixo dela. Se apresentamos gracamente as camadas empilhadas, as camadas dos nveis superiores apresentam um nvel de abstrao maior, mais prximas aos servios disponveis aos usurios. Enquanto isso, nas camadas inferiores, temos servios mais bsicos, normalmente de infraestrutura, e que servem para compor os servios de camadas mais acima.
3 4
No livro Code Complete. segunda edio [60]. No livro Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. [17]
126
Como exemplo de arquitetura que usa este padro, podemos citar a arquitetura da pilha de protocolos TCP/IP. Ela organizada em cinco camadas, sendo elas: Aplicao, Transporte, Rede, Enlace e Fsica. Pipes & Filters : este padro organiza o software para processar uxos de dados em vrias etapas. Dois elementos bsicos so denidos: os chamados lters, que so os elementos responsveis por uma etapa do uxo de processamento; e os chamados pipes, que so os canais de comunicao entre dois lters adjacentes. Note que a arquitetura pode conter diferentes pipes e lters, de modo que possam ser reusados e recombinados para diferentes propsitos. O exemplo cannico de uso do padro Pipes & Filters a arquitetura de um compilador, que pode ser dividida nos seguintes lters : analisador lxico, analisador sinttico, analisador semntico, gerador de cdigo intermedirio e otimizador, que so conectados por diferentes pipes. Entre eles, encontramos o pipe que conecta o analisador lxico ao sinttico e que transmite um uxo de tokens ; o pipe que transporta a rvore de derivao sinttica do analisador sinttico para o analisador semntico; o pipe que transporta a rvore de sintaxe do analisador semntico para o gerador de cdigo intermedirio; e, por m, o pipe que conecta o gerador de cdigo intermedirio ao otimizador. Model-View-Controller : este padro, por sua vez, divide a arquitetura em trs elementos distintos: a lgica de negcio (ou model ), que representa as funcionalidades e os dados do sistema; vises (ou views ), que representam a forma de exibir o estado da lgica de negcio ao usurio; e os controladores (ou controllers ), que so responsveis pela entrada de dados dos usurios. O padro tambm dene que deve existir um mecanismo de propagao de mudanas, de forma que a interface com o usurio (composta das vises e dos respectivos controladores) se mantenha consistente com a lgica de negcio. Este padro comum em sistemas interativos e foi tambm popularizado em sistemas web por meio de frameworks, a exemplo de JSF 5 , Struts 6 e Spring MVC 7 . Microkernel : este padro a base de arquiteturas extensveis orientadas a plugins. Ele dene um elemento arquitetural que ser o ncleo do sistema e elementos chamados pontos de extenso. Este ncleo prov servios de in5 6 7
JavaServer Faces Technology (JSF) : http://java.sun.com/javaee/javaserverfaces/ Apache Struts : http://struts.apache.org/ Spring Framework : http://www.springsource.org/
7.2 Tticas de Design
127
fraestrutura para compor as funcionalidades mais bsicas do sistema e um servio de registro e congurao de componentes em tempo de execuo. O servio de registro e congurao tem como responsabilidade a adio de novas funcionalidades a partir dos pontos de extenso pr-denidos. Estes pontos de extenso servem para guiar e restringir os tipos de funcionalidades a serem adicionadas. Como exemplo de aplicao do padro Microkernel, podemos citar o sistema operacional MINIX 8 , o ambiente de desenvolvimento Eclipse 9 e diversos sistemas de manipulao de imagens que so extensveis por meio de plugins, como o GIMP 10 e o ImageJ 11 .

Por meio da aplicao de padres, somos capazes de reusar a experincia de outros projetistas por meio de solues estruturadas de design. No entanto, h outra forma de reuso de experincia de design e que no propriamente denida no formato de padres. Esta forma chamada de ttica de design e, apesar de cada ttica ter objetivos bem denidos, seu contedo menos estruturado, normalmente contendo apenas ideias ou dicas de projeto que ajudam na implementao de atributos de qualidade. A principal diferena entre tticas e padres de design que, ao contrrio dos padres, as tticas no necessariamente descrevem elementos arquiteturais que devem existir na soluo. Desta maneira, responsabilidade do arquiteto deni-los de forma a seguir as dicas contidas nas tticas. Ao aplicar as tticas ao design, assim como durante a aplicao de padres, o arquiteto deve tambm considerar os trade-os existentes: por um lado, uma ttica pode aumentar o grau de atendimento a um atributo de qualidade, mas, por outro lado, pode afetar negativamente outros atributos. Por isso, para facilitar a avaliao dos trade-os durante o design, apresentaremos algumas tticas de acordo com as qualidades que elas implementam, mas tambm seremos explcitos sobre o que afetado negativamente. A seguir, apresentamos tticas de design de acordo com os seguintes atributos de qualidade:
8 9 10 11
MINIX : http://www.minix3.org/ Eclipse : http://www.eclipse.org/ The GNU Image Manipulation Program (GIMP): http://www.gimp.org ImageJ - Image Processing and Analysis in Java : http://rsbweb.nih.gov/ij/
128
desempenho e escalabilidade; segurana; tolerncia a faltas; compreensibilidade e modicabilidade; e operabilidade.
7.2.1 Desempenho e escalabilidade Para melhorar desempenho de uma aplicao ou facilitar a adio de recursos computacionais para atender a uma maior demanda, podemos citar as seguintes tticas arquiteturais. No mantenha estado Se os elementos da arquitetura so projetados de forma a no manter estado (stateless ), ou seja, que eles sejam capazes de realizar suas funes apenas com os parmetros presentes nas requisies, ca mais fcil replic-los para dividir a carga de requisies entre as rplicas. Basta apenas que seja denido uma balanceador de carga para distribuir as chamadas entre estes elementos. Note que se a demanda aumenta, pode-se tambm aumentar o nmero de elementos stateless para suprimir a demanda sem muito esforo. Basta ento informar ao balanceador sobre os novos elementos para que ele os considere na distribuio de novas requisies. importante observar que nem todos os elementos arquiteturais podem ser stateless. Por exemplo, elementos de dados essencialmente mantm estado (e, portanto, so stateful ). Assim, possvel que, em algum ponto da arquitetura, os diversos elementos stateless precisem de dados ausentes nos parmetros das requisies e portanto tero que fazer novas requisies aos elementos stateful. Se os elementos que mantm estado no forem capazes de responder a esta carga de novas requisies, eles se tornaro o gargalo da arquitetura, prejudicando o desempenho de todo o sistema. Partio de dados Para melhorar o desempenho e a escalabilidade de elementos de dados, podemos dividir o conjunto de dados entre elementos de execuo. Cada um destes elementos que possui parte dos dados chamado de partio (ou shard ). H
129
duas tcnicas de partio de dados que merecem ser citadas: a partio horizontal e a partio vertical. Primeiro, vamos apresentar a partio horizontal por meio de um exemplo. Se pensamos em dados relacionais, que esto organizados em linhas e colunas, a partio horizontal a diviso em grupos de linhas entre os elementos arquiteturais de dados em execuo. Por exemplo, se temos um banco de dados com dois milhes de usurios e temos dois servidores, A e B , executando esse banco de dados, os usurios com ndices de zero a um milho devem estar localizados no servidor A e o restante dos usurios devem estar localizados no servidor B . A partir desta diviso, para um cliente do banco de dados encontrar as informaes de um dado usurio, agora ele deve ser capaz de localizar em qual servidor os dados esto de acordo com o ndice que procura. Note que isso uma forma de dividir a carga de requisies entre elementos de execuo, mesmo usando elementos stateful. J a partio vertical consiste na seleo de algumas colunas do modelo de dados para serem servidas por elementos de execuo diferentes. Assim, se temos novamente os servidores A e B , informaes sobre todos os usurios esto em ambos os servidores. No entanto, informaes mais requisitadas (por exemplo, nome do usurio e grupo de permisses o qual ele pertence no sistema) podem ser encontradas no servidor A, que dispe de hardware melhor, enquanto informaes menos requisitadas podem ser encontradas no servidor B . Da mesma forma que no caso anterior, o cliente deve ser capaz de localizar em qual servidor os dados esto. S que agora, a localizao feita de acordo com o tipo de dados requisitados e no o seu ndice. Caching Em um sistema, existem algumas informaes que so mais requisitadas que outras. Por exemplo, a pgina de algum muito popular numa rede social ou as notcias de primeira pgina de um portal de notcias. Portanto, podemos nos aproveitar desta caracterstica ao projetar sistemas. Se algumas informaes so muito mais requisitadas que outras, o desempenho aparente de um sistema pode ser melhorado se conseguirmos servir essas informaes com melhor desempenho. Uma forma de conseguir isso usando um cache. Um cache um elemento arquitetural capaz de servir informaes com maior desempenho do que o elemento de dados que guarda essas informaes originalmente. Portanto, ao requisitar alguns dados, o cliente pode
130
primeiro requisitar ao cache. Caso o cache possua os dados requisitados, eles sero retornados mais rapidamente do que se o cliente tivesse requisitado apenas ao elemento de dados original. No entanto, precisamos observar que para desempenhar melhor do que os servidores de dados, o cache normalmente armazena um conjunto limitado de dados. Esta limitao o obriga a implementar as chamadas polticas de caching, que so diferentes formas de comportamento para maximizar a quantidade de acertos nas requisies de disponibilidade de informao e manter a consistncia entre o cache e o elemento de dados original. Tticas de processamento Entre as tticas de processamento para melhorar o desempenho da aplicao (em oposio s tticas de dados vistas anteriormente: partio de dados e caching ), podemos citar: partio, paralelizao e distribuio de processamento. A partio de processamento a diviso do processamento entre elementos arquiteturais distintos para tirar proveito das caractersticas de cada elemento de execuo do software. Um exemplo simples distribuir um grande processamento de dados entre os elementos da arquiteturais mais prximos a esses dados, com a nalidade de evitar ao mximo a transferncia de arquivos. Assim, a caracterstica do elemento de execuo procurada para realizar a distribuio se o elemento possui ou no os dados necessrios para o processamento. Por exemplo, se observarmos a arquitetura de um sistema de processamento de grandes conjuntos de dados chamado MapReduce 12 (ou de sua implementao open source, o Hadoop 13 ), percebemos que ele divide o processamento em tarefas menores e tenta associar cada tarefa ao processador que esteja mais prximo dos dados necessrios. Com esta poltica de atribuio de tarefas, o MapReduce consegue processar grandes massas de dados em tempo relativamente pequeno. J a paralelizao de processamento consiste em permitir que linhas de execuo independentes, por exemplo, chamadas de usurios diferentes em um sistema web, ocorram simultaneamente. Essa paralelizao pode ser realizada de diferentes maneiras: em diferentes threads dentro de um mesmo
12
13
A arquitetura do MapReduce brevemente apresentada por Dean e Ghemawat no artigo MapReduce: Simplied Data Processing on Large Clusters [22]. Apache Hadoop : http://hadoop.apache.org/
131
processo, em diferentes processos dentro de um mesmo sistema operacional e em diferentes elementos de execuo de um sistema (tipicamente, em diferentes servidores). Esta paralelizao melhora o desempenho porque aumenta a vazo de respostas e pode utilizar recursos, inicialmente, ociosos. Por m, h a distribuio de processamento ao longo do tempo. Esta ttica consiste em permitir que algumas tarefas de processamento requisitadas pelo usurio no sejam executadas sincronamente e, portanto, no fazendo com que ele espere pelo processamento de algo que no utilizar no momento. Assim, aumentamos o desempenho aparente do software. Um exemplo de distribuio de processamento ao longo do tempo o de tratamento de imagens em sistemas de redes sociais. Quando um usurio faz o upload de uma imagem, essa imagem precisa ser otimizada para ocupar menos espao de armazenamento no sistema. No entanto, este tratamento no feito de forma sncrona, ou seja, quando o usurio envia a imagem, mas sim agendado para ser executado em algum momento no futuro. Menos camadas de abstrao Apesar de projetar um sistema em diversas camadas de abstrao melhorar o reuso (pela possibilidade das camadas serem reusadas), o entendimento (porque diferentes camadas representam diferentes nveis de abstrao, facilitando o controle intelectual da complexidade) e at mesmo a testabilidade do sistema (dado que as camadas podem ser desenvolvidas e testadas separadamente), a presena de muitas camadas em um sistema pode prejudicar seu desempenho. Isto ocorre porque quanto mais camadas de abstrao existem no design, principalmente se desnecessrias, mais recursos sero consumidos. Entre os recursos consumidos, podemos citar a memria, uma vez que mais camadas de implementao signicam mais camadas a serem carregadas durante a execuo, e mais ciclos de processamento, para realizar a comunicao entre diferentes camadas. Desvantagens das tticas de desempenho e escalabilidade Podemos observar que as tticas que acabamos de apresentar aumentam a complexidade da arquitetura, uma vez que apresentam novos elementos tanto em nvel de design, quanto em nvel de execuo. Em nvel de design, os novos elementos podem prejudicar a modicabilidade e a compreensibilidade
132
do software, dado que adicionam novas relaes e conceitos e at sugerem a diminuio dos nveis de abstrao. J em nvel de execuo, novos elementos podem dicultar: a segurana, porque agora os dados estaro ainda mais distribudos no sistema e mais entidades podero acess-los; a tolerncia a falhas, porque podem surgir mais pontos nicos de falhas; e a operabilidade, considerando que os novos elementos de execuo impem mais tarefas de congurao. 7.2.2 Segurana Para implementar a segurana em um sistema de software, o arquiteto deve conhecer, alm de tcnicas de autorizao, autenticao, criptograa e auditabilidade, os seguintes princpios. Princpio do menor privilgio O princpio do menor privilgio consiste em garantir ao usurio, cliente do software ou mdulo do sistema apenas os privilgios necessrios para que sejam capazes de concluir suas tarefas. Assim, caso este usurio, cliente ou mdulo sejam comprometidos (passem a se comportar de forma nociva ao sistema), a quantidade de dano que podero causar ao sistema ser limitada. Princpio da falha com segurana O princpio de falha com segurana (fail-safe ) o de garantir que em caso de qualquer problema, seja de comunicao, autenticao ou falta em um servio, o comportamento padro seja um comportamento seguro. Por exemplo, se um usurio com privilgios de acesso tenta ler um arquivo privado e o sistema de autorizao est indisponvel, o comportamento padro do sistema de leitura deve ser o de negar o acesso ao arquivo. Dessa maneira, mesmo que usurios autorizados sejam privados do acesso aos seus arquivos, os no-autorizados no conseguiro acesso indevido. O mesmo princpio deve ser aplicado, por exemplo, em sistemas de controle de trfego. Se os indicadores de estado dos semforos esto com problemas, os semforos devem falhar no estado pare, uma vez que fazer com que todos os veculos parem nas vias de um cruzamento mais seguro do que fazer com que mais de uma via seja indicada para seguir.
133
Princpio da defesa em profundidade O princpio da defesa em profundidade sugere que a arquitetura deve aplicar diferentes tcnicas de segurana em diferentes nveis do software. Por exemplo, um cliente autenticado do software deve no s ser autorizado a chamar uma funo, mas a funo chamada deve tambm ser autorizada a acessar as informaes necessrias para o dado cliente. Esta tcnica tanto permite que medidas de segurana mais especcas ao contexto possam ser utilizadas, quanto permite manter a segurana do software mesmo durante a falha de alguma medida de segurana adotada. Desvantagens das tticas de segurana Podemos observar que, assim como as tticas de desempenho e escalabilidade, as tticas de segurana aumentam a complexidade da arquitetura. Isto ocorre porque tambm adicionam novos elementos arquiteturais soluo. Estes novos elementos, por serem novos conceitos, prejudicam a compreensibilidade do sistema em tempo de design e a operabilidade durante a execuo. Alm disso, as tticas de segurana tambm requerem a execuo de passos adicionais de processamento (por exemplo, criptografar uma mensagem ou checar se senha inserida vlida), o que prejudica o desempenho da aplicao. 7.2.3 Tolerncia a Faltas A rea de sistemas distribudos contribui com muitas tcnicas que podem ser aplicadas arquitetura para que os sistemas sejam projetados para serem mais tolerantes a faltas. Entre estas tcnicas, podemos citar as seguintes. Evitar ponto nico de falhas Se muitas funcionalidades dependem de apenas um servio que executa em apenas um recurso computacional, todo o sistema estar comprometido se esse nico servio falhar. Este nico servio ou recurso computacional no qual o sistema depende o que chamamos de ponto nico de falhas. Portanto, para que o software no seja completamente dependente de um nico elemento, o arquiteto deve se preocupar em evitar os pontos nicos de falhas a partir do design. Para isso, ele pode distribuir responsabilidades entre diferentes elementos da arquitetura ou mesmo replicar processamento, de forma que o ponto nico seja eliminado.
134
Partio de dados J mostramos que a partio de dados benca para o desempenho e a escalabilidade do sistema. No entanto, ao particionarmos os dados por diversos elementos de armazenamento, distribumos tambm as responsabilidades do servidor de dados. Portanto, se um dos elementos de armazenamento falha, ainda podemos ter o sistema disponvel para parte dos usurios (aqueles os quais as informaes ainda esto disponveis por meio dos elementos de armazenamento que no falharam). Partio e distribuio de processamento Obtemos benefcios semelhantes aos de particionar os dados quando particionamos e distribumos processamento por diferentes elementos da arquitetura. Diferentes responsabilidades atribudas a diferentes elementos da arquitetura permitem que o software continue funcionando, mesmo que parcialmente, em caso de faltas. Alm disso, quando usamos processamento sncrono, amarramos a conabilidade no processamento aos dois ou mais elementos que esto relacionados sincronamente. Por exemplo, se o elemento A realiza uma funo que precisa chamar uma funo sncrona no elemento B , a funo de A s ser executada com sucesso caso B tambm esteja disponvel. No entanto, se a chamada a B for assncrona, a funo chamada em A pode ser executada com sucesso mesmo que B esteja indisponvel temporariamente. Dessa maneira, assim que B estiver novamente disponvel, sua funo poder ser executada. Redundncia No s podemos distribuir diferentes responsabilidades de processamento a diferentes elementos da arquitetura, como tambm podemos atribuir a mesma responsabilidade a diferentes elementos. Assim, durante a execuo, em caso de qualquer problema com um dos responsveis, outro pode assumir seu lugar e retornar corretamente a resposta. Isso o que chamamos de atribuir redundncia a alguns elementos da arquitetura, sejam elementos de dados ou de processamento. Vale observar que no basta apenas replicar a responsabilidade do elemento em questo, mas decidir (1) se o elemento redundante car sempre ativo ou apenas entrar em execuo quando a falha do original for
135
identicada, (2) como as falhas sero identicadas durante a execuo e (3) como os clientes do elemento que falhou redirecionaro suas chamadas para o elemento redundante. Desvantagens das tticas de tolerncia a faltas Como as tticas de tolerncia a faltas se aproveitam de algumas tticas de desempenho e escalabilidade, elas proporcionam as mesmas desvantagens em relao compreensibilidade, modicabilidade e operabilidade, uma vez que aumentam a complexidade da soluo de design. 7.2.4 Compreensibilidade e Modicabilidade Algumas tcnicas que aumentam a compreensibilidade e a modicabilidade da arquitetura j foram mencionadas anteriormente: uso de camadas de abstrao; separao de preocupaes; aplicao de padres; alta coeso e baixo acoplamento. No entanto, no discutimos as desvantagens comuns a essas tcnicas. Por ser comum que ambos os atributos sejam alcanados por meio da abstrao de detalhes e que a abstrao leva adio de novas camadas de implementao, podemos notar que as tcnicas mencionadas anteriormente necessitam de mais recursos computacionais para a execuo, afetando negativamente o desempenho. No entanto, ao termos processadores e canais de dados cada vez mais rpidos, alm de memria e sistemas de armazenamento cada vez mais baratos, o efeito negativo causado por essas tcnicas pode ser irrisrio comparado ao benefcio da compreensibilidade e da modicabilidade no processo de desenvolvimento. 7.2.5 Operabilidade Por m, para proporcionar operabilidade ao sistema de software, o arquiteto deve aplicar as seguintes tcnicas durante o design da arquitetura.
136
Monitorao e anlise do estado do sistema O operador s capaz de agir sobre o software, se ele possuir informaes sobre seu estado interno. Para isso, vantajoso que a arquitetura permita a monitorao do estado de seus elementos mais importantes durante a execuo. Note que em um grande sistema, o conjunto de elementos monitorados pode ser grande, gerando assim uma grande massa de dados de monitorao. Portanto, a monitorao pode ser tornar um problema, uma vez que a gerao e o consumo dos dados pode necessitar de muitos recursos computacionais (canal de comunicao, caso os dados sejam transferidos entre elementos do sistema, e armazenamento, caso os dados sejam armazenados, e processamento, para extrair informaes dos dados). Portanto, a arquitetura deve proporcionar meios de gerao e anlise dos dados de monitorao, mas deve tambm implementar meios de agregao e compactao dos dados de forma que poupem o consumo de recursos computacionais. Computao autonmica Uma forma ainda mais eciente de proporcionar operabilidade ao software a de delegar tarefas que antes seriam de responsabilidade do operador ao prprio software. Portanto, permitir que o software seja capaz de pr ou retirar de execuo servidores, realizar backups, ou realizar outras atividades para a melhoria da qualidade de servio. Realizar automaticamente estas e outras atividades baseadas apenas no estado atual do sistema e sem interveno humana o que chamamos de computao autonmica. Para permitir a adio de aspectos de computao autonmica ao software, sua arquitetura deve estar preparada de forma que dados sobre o estado atual do sistema no sejam apenas coletados, mas tambm sejam analisados automaticamente e os resultados dessa anlise sejam capaz de ativar automaticamente tarefas de administrao do sistema. Desvantagens das tcnicas de operabilidade Como j mencionamos anteriormente, a monitorao e a anlise do estado atual do sistema podem consumir muitos recursos computacionais, impactando negativamente no desempenho. Por outro lado, ao possibilitarmos a anlise do software em tempo de execuo, podemos identicar problemas
137
inicialmente desconhecidos na arquitetura, como gargalos de desempenho ou pontos nicos de falhas. Com estes problemas identicados, o arquiteto pode ento corrigi-los na arquitetura, melhorando assim o desempenho e a tolerncia a faltas do software.
Resumo
Este captulo exps o que um arquiteto deve saber em relao s tcnicas e princpios de design arquitetural. Devemos admitir que seu objetivo ambicioso, uma vez que que existem muitos livros e artigos de Design de Software sobre o mesmo assunto. No entanto, a maioria dos livros e artigos disponveis no so explicitamente escritos sobre Arquitetura de Software ou no tm como pblico-alvo o leitor ainda inexperiente. Da nossa tentativa de preencher esta lacuna. Ao nal deste captulo, esperamos que o leitor conhea os seguintes princpios de design arquitetural: uso da abstrao ou nveis de complexidade; separao de preocupaes; e uso de padres e estilos arquiteturais.
Mas, alm disso, esperamos que o leitor tambm reconhea algumas tticas que implementam os seguintes atributos de qualidade: desempenho e escalabilidade; segurana; tolerncia a faltas; compreensibilidade e modicabilidade; e operabilidade.
Para informaes mais detalhadas sobre os princpios e tcnicas apresentados, deixamos uma lista de referncias para estudos posteriores.
Referncias
Abstrao e separao de preocupaes Sobre os benefcios e aplicao da abstrao e separao de preocupaes no design de software, recomendamos a leitura do livro Code Complete [60], de
138
McConnell. Alm dele, podemos citar os seguintes artigos sobre o assunto: The Structure of The THE-multiprogramming System [25], de Dijkstra, e o On The Criteria to Be Used in Decomposing Systems Into Modules [66], de Parnas. Padres e estilos arquiteturais H diversos padres e estilos arquiteturais, inclusive catalogados de acordo com seus objetivos. Apesar de termos citado apenas quatro padres que foram inicialmente descritos por Buschmann, existem muito mais padres descritos por este autor e outros autores na srie de livros Pattern-Oriented Software Architecture [17, 75, 15, 16]. Recomendamos tambm sobre o assunto os livros Patterns of Enterprise Application Architecture [33], escrito por Fowler, e o Software Architecture in Practice [6], escrito por Bass et al. Tcnicas arquiteturais Sobre tcnicas arquiteturais, podemos citar o livro Beautiful Architecture [80], editado por Spinellis e Gousios. Ele mostra na prtica a aplicao de diversas tcnicas para o alcance de requisitos de qualidade por meio do design arquitetural. Sendo menos prtico, porm mais abrangente na exposio de tcnicas arquiteturais, podemos citar tanto o livro Software Architecture: Foundations, Theory, and Practice [81], de Taylor et al, quanto o livro Software Systems Architecture [72], de Rozanski e Woods. O livro The Art of Systems Architecting [56], de Maier e Rechtin, descreve poucas (porm valiosas) tcnicas de arquitetura de software. Neste livro, as tcnicas so chamadas de heursticas. Podemos ainda mencionar alguns artigos sobre desempenho de software em geral: Performance Anti-Patterns [76], de Smaalders; sobre replicao de dados: Optimistic Replication [74], de Saito e Shapiro; e sobre segurana: In Search of Architectural Patterns for Software Security [73], de Ryoo et al. Por m, mencionamos dois blogs que contm muitas descries de problemas arquiteturais reais e como foram resolvidos na indstria: o HighScalability.com [36] e o Engineering @ Facebook [29].
139
Exerccios
7.1. Descreva exemplos de uso de nveis de abstrao em projetos de arquitetura. 7.2. Quais os benefcios proporcionados pela separao de preocupaes durante o design arquitetural? Quais as desvantagens? 7.3. Quais os benefcios proporcionados pelo uso de padres? Quais as desvantagens? 7.4. Descreva brevemente projetos que aplicam os seguintes padres: Layers, Pipes & Filters, Model-View-Controller e Microkernel ( possvel que um projeto use mais de um padro). Cite as vantagens alcanadas com o uso de cada padro no projeto. 7.5. Descreva um projeto que, ao usar uma ttica de desempenho ou escalabilidade, teve sua compreensibilidade afetada negativamente. 7.6. Descreva um projeto que, ao usar uma ttica de desempenho ou escalabilidade, teve sua operabilidade afetada negativamente. 7.7. O que um ponto nico de falhas? Cite exemplos em design arquitetural. 7.8. Descreva um exemplo de ponto nico de falhas que pode surgir ao se aplicar a tcnica de partio dos dados. 7.9. Descreva um projeto que, ao usar uma ttica de segurana, teve sua operabilidade afetada negativamente. 7.10. Descreva como tcnicas de tolerncia a faltas afetam a operabilidade do software.
8 Documentao da Arquitetura
Aps entendermos os conceitos e a importncia e termos noes de design de arquitetura de software, precisamos saber como capturar a informao do projeto e document-lo. Para isso, introduzimos os conceitos de vises e de pontos de vista arquiteturais, que facilitam a documentao por mostrar diferentes dimenses que uma arquitetura apresenta. Este captulo no dita uma nica linguagem ou modelo de documentao de arquitetura, mas apresenta exemplos de como faz-lo. Este captulo tem como objetivo fazer com que o leitor seja capaz de entender que: O documento de arquitetura auxilia no processo de design, uma ferramenta de comunicao entre stakeholders e pode servir de modelo de anlise do software; Toda informao presente numa arquitetura uma deciso arquitetural; Decises arquiteturais podem ser existenciais, descritivas ou executivas; Decises arquiteturais se relacionam, podendo restringir, impedir, facilitar, compor, conitar, ignorar, depender ou ser alternativa a outras decises arquiteturais; e Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto. Por isso, a necessidade de mltiplas vises arquiteturais;
142
8.1 Arquitetura e Documento da Arquitetura

A arquitetura de um software existe independente dela ser projetada ou documentada. No entanto, ao deixarmos a arquitetura simplesmente emergir a partir do software, ou seja, evoluir ao longo do processo de desenvolvimento sem projeto ou documentao, corremos o risco de no tirar proveito dos benefcios que ela proporciona. Por outro lado, apenas realizar o design arquitetural e no document-lo (ou document-lo de forma precria), pode minimizar as vantagens a serem obtidas pela arquitetura. Isto pode ocorrer porque documentar a arquitetura, alm de auxiliar o prprio processo de design, tambm proporciona: uma ferramenta de comunicao entre os stakeholders; a integridade conceitual ao sistema e ao processo de desenvolvimento; um modelo para anlise antecipada do sistema; e uma ferramenta de rastreabilidade entre os requisitos e os elementos do sistema. 8.1.1 Auxlio ao Processo de Design Apesar de dividirmos conceitualmente o processo de design do processo de documentao, comum que ambos aconteam em paralelo na prtica. Quando isto ocorre, a documentao ajuda no design, principalmente no sentido de separao de preocupaes. Ao documentarmos vises arquiteturais diferentes separadamente, preocupamo-nos separadamente com o design de diferentes aspectos do software. Entre os diversos aspectos de um software, podemos citar os aspectos funcionais, de dados, de concorrncia, de desenvolvimento, de implantao e operacionais. Esta separao se torna benca porque h diferentes linguagens, que podem ser grcas ou textuais, que melhor se encaixam descrio de cada aspecto, ajudando no s numa melhor representao, como tambm numa melhor modelagem e avaliao em relao aos objetivos. A seguir, vemos dois exemplos que ilustram a documentao de algumas decises arquiteturais relacionadas a aspectos diferentes do SASF. No Exemplo 8.1, podemos observar como o SASF est dividido em grandes mdulos funcionais e, assim, podemos inferir quais so suas principais funcionalidades
143
e algumas de suas relaes entre si. Podemos dizer que as decises arquiteturais do exemplo so apresentadas sob o ponto de vista funcional do sistema, constituindo uma viso funcional do software. Note tambm que esta no a melhor forma de representar, por exemplo, que o desenvolvimento do cadastro dos usurios ser terceirizado ou ainda que o servio de transmisso de vdeos deve executar em 7 servidores durante dias teis e em 15 servidores nos nais de semana e feriados, quando demanda aumenta. Exemplo 8.1 ((Deciso Arquitetural 001)). O SASF dividido em cinco grandes mdulos funcionais. Cada mdulo responsvel por prover um conjunto de funcionalidades relacionadas entre si. Os grandes mdulos do SASF so: Locadora de Filmes; Transmissor de Filmes; Motor de Sugestes; Cadastro de Usurios; Cadastro de Filmes.
As principais funcionalidades providas por cada mdulo e suas relaes de uso esto descritas no diagrama representado na Figura 8.1. Objetivos : A diviso em mdulos funcionais possibilita a diviso da implementao entre os times de desenvolvimento de acordo com a especialidade de cada time. Fundamentao : As diversas funes a serem providas pelo SASF foram agrupadas em preocupaes comuns (cadastro de dados, locao e transmisso de lmes, e sugestes ao usurio). O cadastro deve ser especializado em dois tipos para dividir o esforo de desenvolvimento: cadastro de lmes e de usurios. O motor de sugestes deve ser alimentado com dados de histrico de locaes do usurio e informaes sobre a base de lmes no sistema. No Exemplo 8.2, mostramos o SASF sob um ponto de vista de implantao. Neste exemplo, podemos observar informaes de congurao para implantao de servios para executar o SASF informaes que estavam ausentes no exemplo anterior. Exemplo 8.2 ((Deciso Arquitetural 002)). A implantao do mdulo que implementa as funcionalidades do servio de transmisso de lmes deve depender apenas de um parmetro:
144
Figura 8.1. Mdulos funcionais do SASF descritos usando UML. O esteretipo Mdulo do diagrama indica os mdulos funcionais que compem o sistema. J o esteretipo usa indica relaes de uso entre os mdulos para que possam implementar suas funes. Por m, o esteretipo especializao indica uma relao de especializao dos dados guardados no elemento responsvel pelo cadastro.
endereos.servidores.congurao : lista de endereos IP dos servidores que constituem o servio de congurao do SASF.
Os outros parmetros de congurao devem ser obtidos a partir da comunicao com o servio de congurao. Objetivos : Facilitar a operabilidade do sistema. Fundamentao : O servio de congurao do SASF, que descrito em detalhes na [Deciso Arquitetural 011], um centralizador da congurao do sistema. Nele, o operador do sistema insere endereos de servios para que estejam disponveis para a congurao de uma nova instncia. Quando a instncia do servio de transmisso de lmes iniciada, ela faz requisies ao servio de congurao pelos endereos dos servios de cadastro e dos servios de armazenamento de lmes, por exemplo.
145
8.1.2 Ferramenta de Comunicao J sabemos que diferentes stakeholders demonstram diferentes preocupaes sobre diferentes aspectos do sistema. Como a documentao da arquitetura versa sobre as muitas preocupaes dos stakeholders, ela serve de ferramenta para comunicao, uma vez que prov um vocabulrio comum sobre o sistema, alm de registrar as relaes entre as preocupaes e de que forma os eventuais conitos foram ou devem ser resolvidos. Note que para servir de ferramenta de comunicao, o documento arquitetural deve ser construdo de forma que respeite o conhecimento e as necessidades dos stakeholders. Para que isto seja possvel, deve-se conhecer para quem o documento est sendo escrito. Portanto, devemos escrever a arquitetura de forma que possua partes que interessem aos usurios, aos clientes, aos desenvolvedores, aos testadores, ao gerente de projeto ou a outros stakeholders envolvidos no processo. Por exemplo, os usurios buscam pelas funcionalidades, capacidades e comportamento do sistema, no como ele foi dividido em mdulos, como os mdulos se comunicam entre si ou se eles foram desenvolvidos do zero ou tiveram partes reutilizadas de outros sistemas. Clientes e gerentes tm alguns interesses semelhantes, como custos de desenvolvimento ou cronograma de lanamento. No entanto, os clientes tambm se preocupam com o alinhamento do software ao seu negcio, enquanto o gerente procura como minimizar os custos para se adequar ao oramento, ou como as tarefas de implementao sero divididas entre seu time de desenvolvimento. Finalmente, desenvolvedores e testadores esto interessados em aspectos tcnicos do design, por exemplo, qual a diviso em mdulos do sistema, quais as alternativas de design disponveis ou como os atributos de qualidade (desempenho, escalabilidade, tolerncia a faltas, etc.) devem ser implementados, cada um motivado pelo seu papel no processo de desenvolvimento. 8.1.3 Integridade Conceitual Por outro lado, o documento precisa demonstrar consistncia entre os diversos aspectos do design da arquitetura para que haja comunicao e integridade conceitual. A consistncia necessria porque, apesar da separao de preocupaes ser uma ferramenta poderosa de design, as solues para as diferentes preocupaes trabalham interligadas durante a implementao, ou
146
seja, quando resolvem o problema. Assim, precisamos de integridade em dois nveis: entre os stakeholders e entre os diversos aspectos do documento de arquitetura. A integridade conceitual entre stakeholders a defendida por Brooks, em The Mythical Man-Month, porque facilita o sucesso no desenvolvimento de sistemas de software. Se os stakeholders e principalmente os desenvolvedores no tm em mente o mesmo design que se transformar em produto, so poucas as garantias de que o produto implementado ser o projetado. Por isso, no processo, o documento de arquitetura serve para restringir eventuais deslizes conceituais em relao ao design arquitetural e prevenir futuras discordncias entre stakeholders, inclusive de interesses similares. O Exemplo 8.3 ilustra um caso de restrio aos desenvolvedores, mas que benca por proporcionar a integridade conceitual entre times de desenvolvimento. Este caso a denio das interfaces entre dois servios presentes no sistema. Exemplo 8.3. No SASF, se dividirmos os desenvolvedores em mais vrios times, comum que haja uma maior interao entre os membros de um mesmo time do que entre times diferentes. Vamos considerar que delegamos a um time a implementao do servio responsvel pelas funcionalidades do mdulo Cadastro de Filmes, j apresentado no Exemplo 8.1, e a outro time o mdulo Transmissor de Filmes. Para que a implementao dos dois mdulos possa ser paralelizada e para que sejam evitadas suposies errneas ou desnecessrias por parte de cada time sobre outros mdulos (e, portanto, seja menos custosa a integrao), devemos denir cuidadosamente as interfaces dos mdulos, sejam os mtodos disponveis, a forma de comunicao e os tipos de dados usados como parmetros ou retorno. A integridade conceitual tambm se mostra necessria durante a incluso de novos membros equipe de desenvolvimento e ao longo da evoluo e manuteno do software. Novos membros precisam de uma descrio da arquitetura porque normalmente so inseridos ao time sem qualquer conhecimento prvio do design. J ao longo da evoluo e manuteno do software, o conhecimento das regras de design a serem seguidas se faz necessrio para que os requisitos de qualidade permaneam implementados, mesmo durante mudanas. O exemplo a seguir ilustra uma regra de design para que um software de manipulao de imagens continue exercendo alta portabilidade.
147
Exemplo 8.4. O software de manipulao de imagens ImageJ 1 desempenha bem dois atributos de qualidade: a extensibilidade e a portabilidade. Sua extensibilidade garantida por ter sua arquitetura baseada no uso de plugins. Com isso, ele composto de um ncleo de funcionalidades bsicas e prov meios para que novas funcionalidades sejam adicionadas em tempo de execuo. J sua portabilidade garantida por ele ter seu ncleo e plugins implementados usando a linguagem de programao Java, permitindo sua execuo em qualquer ambiente que disponha da mquina virtual Java. Como o cdigo-fonte do ImageJ de domnio pblico, qualquer programador pode baix-lo, us-lo e escrever novos plugins para ele. Inclusive, possvel usar o mecanismo Java Native Interface (JNI) para realizar chamadas a bibliotecas escritas em outras linguagens. No entanto, se o programador deseja manter o alto grau de portabilidade do ImageJ, ele deve respeitar a regra de design do software que de nunca realizar chamadas nativas durante a implementao de novas funcionalidades. Existe tambm a integridade entre os diversos aspectos da arquitetura no documento ou, em outras palavras, a integridade entre as vises da arquitetura. Este tipo de integridade deve ser mantido para que as partes do design funcionem em conjunto e que, portanto, o design seja passvel de implementao. A consistncia entre vises se faz necessria por que, apesar da separao de preocupaes e de elementos arquiteturais facilitar o design, em conjunto que eles so construdos e executados. Portanto, se h no documento mais de uma viso sobre os mesmos elementos do sistema, essencial que na documentao dessas vises exista um mapeamento entre as diferentes representaes desses elementos. O Exemplo 8.5 ilustra a consistncia entre vises sobre o armazenamento no SASF. Nele, podemos observar (1) os servios providos pelo sistema de armazenamento do SASF por meio da viso funcional; (2) que boa parte dos servios de armazenamento no sero implementados do zero, uma vez que sero obtidos pelo Sistema de Gerncia de Banco de Dados adotado, por meio da viso de desenvolvimento; e (3) que o sistema de armazenamento estar executando, no mnimo, em trs servidores, por meio da viso de implantao. Note que, se alguma das vises for inconsistente com as outras, podem surgir dvidas sobre: (1) quais servios esto disponveis para quem usa ar1
ImageJ - Image Processing and Analysis in Java : http://rsbweb.nih.gov/ij/
148
mazenamento, (2) o que ser implementado e o que ser aproveitado durante a implementao da soluo de armazenamento do SASF e, por m, (3) que tipo de hardware ser necessrio para executar a soluo de armazenamento. Exemplo 8.5. Na [Deciso Arquitetural 001], descrita no Exemplo 8.1, apresentamos trs mdulos que devem lidar diretamente com armazenamento: Cadastro de Usurios, Cadastro de Filmes e Transmissor de Filmes. No entanto, apenas as funes que eles devem implementar foram descritas, no como devem implementar. As decises a seguir mostram alguns aspectos de como essas funes devem ser implementadas. (Deciso Arquitetural 002). O armazenamento das informaes dos mdulos Cadastro de Usurios e Cadastro de Filmes ser realizado usando um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) de modo a permitir criao, edio, obteno e remoo das entradas. As informaes guardadas no SGBDR so os atributos dos Usurios e Filmes e so essencialmente textuais ou metainformaes para localizao de arquivos de mdia (fotos ou vdeos). O armazenamento de arquivos de mdia tratado na [Deciso Arquitetural 003]. J o armazenamento de arquivos textuais que no so atributos dos Usurios ou Filmes, por exemplo, mensagens para usurios ou comentrios sobre lmes tratado em outra deciso arquitetural que no descrita aqui. Objetivo : Permitir a persistncia dos atributos dos Usurios e Filmes, facilitando o desenvolvimento. Fundamentao : Os atributos de Usurios e Filmes so essencialmente relacionais, se encaixando perfeitamente ao paradigma usado para armazenamento. Alm de ser um paradigma bem conhecido pelo time de desenvolvimento. (Deciso Arquitetural 003). O armazenamento de arquivos de mdia (fotos de Usurios, fotos de Filmes e arquivos de vdeo) sero armazenados usando uma Rede de Fornecimento de Contedo (Content Delivery Network ou CDN). Objetivo : Permitir a persistncia de arquivos de mdia, facilitando a implementao e permitindo desempenho e controle de carga. Fundamentao : Os arquivos de mdia presentes no SASF so contedo esttico, que pode ser distribudo por uma CDN e, assim, tirar proveito de replicao, distribuio geogrca e caching, sem ter que implementar estas tcnicas.
149
J as decises da viso de implantao, devem descrever os servidores que executaram os SGBDR e o servio que se comunica com a CDN para o envio de arquivos. 8.1.4 Modelo para Anlise A arquitetura um modelo do sistema, uma vez que descreve suas caractersticas. Ao documentar a arquitetura, obtemos um modelo manipulvel do sistema que tem utilidade no s ao arquiteto, mas tambm a outros stakeholders. Com o modelo manipulvel, possvel avaliar as decises arquiteturais registradas e valid-las em relao aos requisitos que o software deve satisfazer. Alm disso, o documento pode ainda servir de ferramenta que permita a vericao de se implementao est de acordo com o design, podendo prevenir eventuais deslizes arquiteturais. Podemos citar trs categorias2 de validao da arquitetura em relao aos requisitos: anlise baseada em inspees, anlise baseada em modelos e anlise baseada em simulaes. No entanto, a possibilidade de aplicao de uma tcnica de uma dada categoria de validao est diretamente ligada representao usada no documento de arquitetura. Anlise baseada em inspees Anlises baseadas em inspees so conduzidas por bancas de reviso compostas por vrios stakeholders. Entre os stakeholders, podemos encontrar, alm do arquiteto e dos desenvolvedores, interessados menos tcnicos, como o gerente de projeto e, em alguns casos, o cliente. Durante o processo de inspeo, os stakeholders denem os objetivos da anlise e estudam as representaes da arquitetura de forma a avali-la de acordo com seus objetivos. Esta categoria de validao serve para vericar um conjunto amplo de propriedades da arquitetura e faz uso de mltiplas representaes do design, tanto em linguagens formais, quanto informais. Por ser um processo essencialmente manual, um tipo de anlise mais caro do que os de outros, mas que possibilita tambm a inspeo em busca de qualidades menos formais do software, a exemplo de escalabilidade, manutenibilidade ou operabilidade. Outra vantagem deste tipo de anlise a de permitir o uso de representaes
2
Esta diviso foi feita originalmente por Taylor et al em Software Architecture: Foundations, Theory, and Practice [81].
150
informais ou parciais do design da arquitetura, alm de possibilitar a anlise considerando mltiplos objetivos de mltiplos stakeholders. Como exemplos de anlises baseadas em inspees, podemos citar alguns mtodos de avaliao de arquitetura criados pelo Software Engineering Institute, da Carnegie Melon University : o Software Architecture Analysis Method (SAAM), o Architectural Trade-O Analysis Method (ATAM) e o mtodo Active Reviews for Intermediate Designs (ARID).3 Anlise baseada em modelos Anlises baseadas em modelos so menos custosas do que as baseadas em inspees, uma vez que demonstram maior nvel de automao. Este tipo de anlise utiliza ferramentas que manipulam representaes da arquitetura com o objetivo de encontrar algumas de suas propriedades. Para possibilitar a manipulao, as representaes devem ser escritas em linguagens formais ou semiformais como ADLs (architecture description languages ou linguagens de descrio de arquitetura), como por exemplo, ACME, SADL e Rapide, mquinas de estado nito ou UML. Esta categoria de validao utilizada na busca de propriedades formais da arquitetura, como corretude sinttica ou ausncia de deadlocks e, apesar de seu alto grau de automao, pode necessitar que o arquiteto guie a ferramenta de validao utilizada considerando os resultados parciais. Uma desvantagem desta categoria seu desempenho na anlise de grandes sistemas. Uma vez que as representaes da arquitetura podem levar exploso de estados, a anlise de todo o espao de estados do sistema pode ser invivel. Portanto, comum que apenas partes da arquitetura sejam analisadas de preferncia partes mais crticas. Como exemplos de anlises baseadas em modelos, podemos citar o uso da linguagem Wright para a vericao de ausncia de deadlocks 4 e o uso da linguagem de modelagem MetaH para anlise de propriedades conabilidade e segurana (safety )5 .
3
Podemos encontrar a descrio desses mtodos no livro Evaluating Software Architectures, de Paul Clements et al [21]. Tcnica apresentada por Allen e Garlan no artigo A Formal Basis for Architectural Connection [2] Mais informaes sobre a linguagem MetaH podem ser encontradas no site: http://www.htc.honeywell.com/metah/index.html
151
Anlise baseada em simulaes Anlises baseadas em simulaes se utilizam de modelos executveis da arquitetura para extrair caractersticas do software ou de partes dele. Assim como a anlise baseada em modelos, esse tipo de anlise tambm se utiliza de ferramentas que automatizam o processo, deixando-o mais barato. No entanto, este tipo de anlise produz resultados restritos s propriedades dinmicas do software e esto sujeitas s imprecises dos modelos de execuo. Para possibilitar a execuo, as representaes utilizadas devem ser formais, o que diminui sua aplicao na indstria, mas que proporciona resultados mais precisos em relao s qualidades estruturais, comportamentais e de interao entre as partes do software, como por exemplo qualidades de desempenho e conabilidade. Como exemplos de anlises baseadas em simulaes, podemos citar o uso de simulao de eventos discretos para anlise de desempenho ou o uso da ferramenta XTEAM 6 , que utiliza ADLs e processos de estado nito para diferentes tipos de anlises arquiteturais. 8.1.5 Ferramenta de Rastreabilidade Por m, a documentao permite rastreabilidade entre os requisitos e os elementos da arquitetura e implementao que satisfazem esses requisitos. Ao documentar as decises arquiteturais, registramos (1) seus objetivos, que normalmente so qualidades a serem alcanadas pelo software, e (2) como esses objetivos so alcanados, por meio da descrio dos elementos que compem o sistema e suas relaes e regras de design que devem ser respeitadas durante a implementao. Este registro serve de ponte entre dois extremos do processo de desenvolvimento: os requisitos e a implementao, e assim permite a navegao entre pontos relacionados, sejam eles requisitos, decises de design ou partes da implementao. A rastreabilidade nos permite analisar qual o impacto de uma deciso de design, tanto em termos de quais requisitos ela afeta, quanto quais elementos de software ela dita a existncia ou, em caso de manuteno, quais elementos so ou devem ser afetados por mudanas nos requisitos ou nas decises.
6
A ferramenta eXtensible Tool-chain for Evaluation of Architectural Models (XTEAM) descrita por Edwards et al no artigo Scenario-Driven Dynamic Analysis of Distributed Architectures [27].
152
O exemplo a seguir mostra aspectos de rastreabilidade na documentao da arquitetura do SASF. Exemplo 8.6. Se observarmos a arquitetura do SASF e procurarmos pelas decises responsveis por facilitar a manuteno do sistema, encontraremos entre elas a deciso de diviso do sistema em camadas. Essa deciso sugere uma diviso do sistema em camadas lgicas, mas tambm inuencia na diviso em pacotes, servios ou mesmo processos. Assim, a satisfao do requisito de manutenibilidade est diretamente ligada correta diviso das partes do sistema em apresentao, lgica de negcio e persistncia. Da mesma maneira, se partirmos das partes que formam as camadas de apresentao, lgica de negcio e persistncia, observaremos que elas esto ligadas diviso do sistema (e deciso arquitetural) que se prope a atender a requisitos de manutenibilidade.
8.2 Decises Arquiteturais

Em captulos anteriores, denimos arquitetura de software usando o padro ISO/IEEE 1471-2000, que diz que ela a organizao fundamental de um sistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios que conduzem seu design e evoluo. Aps a denio, mencionamos tambm que a arquitetura composta de diversas decises de design (no caso, design de alto-nvel ou arquitetural) e que cada deciso contm, ao menos em nvel conceitual, uma descrio, objetivos e algum argumento ou motivao. Como a arquitetura formada por decises arquiteturais, devemos conhecer os tipos de decises arquiteturais para ento sermos capazes de documentar a arquitetura. Uma deciso arquitetural, como tambm j denido anteriormente, uma escolha entre as alternativas de design arquitetural, que se prope a alcanar um ou mais atributos de qualidade do sistema, por meio de estruturas ou regras que ela envolve ou dene. Em outras palavras, podemos dizer que uma deciso arquitetural descreve parte do design, onde essa descrio pode: (1) ditar a existncia ou inexistncia de partes do sistema, (2) especicar propriedades que, durante a construo, partes do sistema devem satisfazer, ou (3) citar tcnicas que devem ser seguidas durante a construo de partes do sistema. Podemos ento dividir as decises arquiteturais em:
153
Decises arquiteturais existenciais (e no-existenciais); Decises arquiteturais descritivas (ou de propriedades); e Decises arquiteturais executivas.
8.2.1 Decises existenciais Uma deciso existencial aquela que indica a presena de um ou vrios elementos arquiteturais no design e na implementao. Os elementos arquiteturais j foram apresentados anteriormente, mas vamos relembr-los aqui. Estes elementos so as partes em que o software dividido e podem ser classicados em dois tipos: elementos arquiteturais estticos e elementos arquiteturais dinmicos. Os elementos estticos descrevem a estrutura do sistema em tempo de design e so constitudos de elementos de software (por exemplo, classes, pacotes, procedimentos, servios remotos), elementos de dados (por exemplo, entidades e tabelas de bancos de dados, arquivos ou classes de dados), e elementos de hardware (por exemplo, servidores em que o sistema vai executar ou armazenar dados). Por sua vez, os elementos dinmicos descrevem o comportamento do sistema em tempo de execuo e entre eles podemos incluir processos, mdulos, protocolos, ou classes que realizam comportamento. Note que as relaes entre os elementos arquiteturais, tanto estticos quanto dinmicos, so representadas tambm como elementos arquiteturais. Estes elementos so chamados de conectores e podem ser associaes, composies, generalizaes, entre outros. No Exemplo 8.1, observamos uma deciso arquitetural que divide o SASF em diversos mdulos menores, constituindo assim uma deciso existencial que dene diversos elementos e as relaes entre si. J no Exemplo 8.7, observamos uma deciso arquitetural que tambm dita a presena de elementos na arquitetura do SASF. No entanto, ao contrrio do exemplo citado anteriormente que dita elementos estruturais do software, o Exemplo 8.7 dita elementos comportamentais esperados nele. Assim, podemos encontrar decises existenciais que sejam decises estruturais ou comportamentais. As decises comportamentais so mais relacionadas implementao dos requisitos de qualidade. Exemplo 8.7 ((Deciso Arquitetural 005)). Os dados do Cadastro de Usurios e do Cadastro de Filmes devem ser particionados horizontalmente.
154
Objetivo : Distribuir carga, melhorar o desempenho e aumentar o nmero de pontos de falhas. Fundamentao : Ao particionar horizontalmente os dados, permite-se a distribuio da carga de requisies entre vrios servidores de armazenamento, que estaro executando instncias do SGBDR. Com menor carga, o desempenho pode ser melhorado. Alm disso, caso uma partio que inacessvel (por falha, por exemplo), parte dos dados ainda estaro acessveis, no inviabilizando o sistema por completo. Na prtica, importante observarmos que a diviso entre decises estruturais e comportamentais no absoluta. Podemos encontrar decises que, para descrever um comportamento, necessitem de novas estruturas arquiteturais. Assim, por convenincia, melhor descrever estas novas estruturas na prpria deciso comportamental do que documentar uma nova deciso estrutural. Podemos observar este caso no exemplo anterior, onde descrevemos as parties do conjunto de dados para ento descrever o comportamento de particionamento dos dados e assim conseguir algum nvel de escalabilidade horizontal. Por outro lado, h decises que probem a existncia de elementos arquiteturais. Essas decises so chamadas de decises no-existenciais e elas servem para restringir as alternativas de design de baixo nvel. Alguns padres arquiteturais, como o 3-tier ou mesmo o padro Camadas, probem a comunicao entre alguns dos elementos que eles descrevem, constituindo decises no-existenciais. 8.2.2 Decises descritivas Decises de descritivas (ou de propriedades) no determinam a existncia de partes do software, mas apresentam alguma qualidade ou caracterstica que uma ou mais partes devem exibir. O papel deste tipo de deciso o de guiar tanto o design de baixo nvel, quanto a implementao, uma vez que descreve os princpios e regras ou restries de design que devem ser respeitadas ao longo do desenvolvimento. Os exemplos mais comuns de decises de propriedades so as decises sobre preocupaes transversais ao software, como por exemplo, decises de logging, decises de tolerncia a faltas ou mesmo decises sobre a preciso na obteno dos resultados. Podemos observar uma ilustrao mais completa deste tipo de
155
deciso nos exemplos 8.8 e 8.9. Note que, em ambos os exemplos, as decises no descrevem a existncia de elementos que devem estar na arquitetura, mas descrevem as propriedades de elementos arquiteturais que foram descritos em outras decises. Exemplo 8.8 ((Deciso Arquitetural 008)). Os mtodos pblicos de cada servio que implementa os mdulos descritos na [Deciso Arquitetural 001] devem seguir as seguintes regras de logging : Deve-se registrar todos os parmetros das chamadas em nvel de DEBUG. Este modo deve poder ser ligado ou desligado em tempo de execuo. Todas as excees lanadas devem ser logadas em nvel de ERROR e registrar os parmetros usados durante a execuo. Os tempos de execuo de cada chamada ao mtodo devem ser registrados, para possibilitar a monitorao de desempenho do sistema. O canal de logging utilizado neste caso deve ser especializado para coleta de mtricas de desempenho. Objetivo : Estas regras facilitam a operabilidade do sistema. Fundamentao : O registro dos acontecimentos inesperados no sistema facilita o diagnstico dos problemas e a possibilidade de aumentar o nvel de detalhe dos registros em tempo de execuo permite que esse diagnstico seja mais rpido. Por outro lado, o registro de mtricas de desempenho do sistema permite anlise de capacidade, podendo indicar se o sistema est precisando de mais recursos computacionais. Exemplo 8.9 ((Deciso Arquitetural 010)). Os servios que implementam os mdulos descritos na [Deciso Arquitetural 001] devem ser replicados, evitando assim pontos nicos de falha. Para facilitar a replicao, os mdulos no devem manter estado, delegando esta responsabilidade aos servios de armazenamento. Objetivo : Replicando instncias de servios, elimina-se os pontos nicos de falha, aumentando a conabilidade do sistema e a tolerncia a faltas. Fundamentao : Implementando servios stateless, a replicao ca trivial, uma vez que a requisio pode usar qualquer uma das rplicas ativas. Note que sempre necessrio o registro no balanceador de carga da uma nova rplica em execuo. Servios de armazenamento no podem utilizar esta tcnica sem adaptaes, uma vez que dados so fundamentalmente stateful.
156
8.2.3 Decises executivas A ltima classe de decises arquiteturais que apresentamos a executiva. Este tipo de deciso est mais relacionado ao processo de desenvolvimento do que aos elementos de design. Entre as decises executivas, podemos encontrar decises que descrevem: a metodologia utilizada durante desenvolvimento, como o time est dividido durante a implementao do sistema, como o treinamento de novos membros deve ocorrer, ou quais tecnologias e ferramentas devem ser adotadas para auxiliar o processo. Os exemplos a seguir mostram algumas decises executivas. Exemplo 8.10. Neste exemplo, apresentamos uma deciso hipottica do software Vuze 7 . (Deciso Arquitetural 001). O software ser escrito usando a linguagem de programao Java. Objetivo : Permitir a portabilidade para vrios sistemas operacionais. Fundamentao : Como um dos objetivos do Vuze alcanar o maior nmero de usurios possvel, no queremos impor a barreira de instalao em um ou outro sistema operacional especco. Uma vez que programas escritos em Java podem executar em qualquer sistema operacional que seja capaz de executar a Mquina Virtual Java (JVM) e que a maioria dos sistemas para usurios nais j dispem da JVM, esta linguagem deve ser usada para poupar o trabalho de portar o Vuze para diferentes sistemas. Exemplo 8.11 ((Deciso Arquitetural 011)). O time de desenvolvimento ser dividido em equipes menores e cada equipe ser responsvel pela implementao do servio responsvel pelas funcionalidades de mdulo descrito na [Deciso Arquitetural 001]. Objetivo : Minimizar o tempo de desenvolvimento. Fundamentao : A possibilidade de paralelizar o desenvolvimento pode diminuir o tempo total de construo do software. No entanto, deve-se respeitar as decises arquiteturais que denem as interfaces entre os mdulos, para que sua integrao seja facilitada.
Vuze : http://www.vuze.com/
157
8.2.4 Atributos das decises arquiteturais No Captulo 4, mostramos que as decises arquiteturais devem possuir uma descrio, objetivos e alguma fundamentao. Estes atributos se tornam essenciais ao processo de design das decises, pois representam, respectivamente, o que deve ser feito, para que deve ser feito e a justicativa da soluo. No entanto, h outros atributos que so especialmente teis quando precisamos documentar as decises arquiteturais. So eles o escopo, o histrico, o estado atual e as categorias da deciso arquitetural. Entre as vantagens que eles proporcionam, podemos dizer que esses atributos facilitam a manuteno de um registro histrico das decises e a rastreabilidade entre requisitos e elementos do software. A seguir, mostramos cada atributo de uma deciso arquitetural separadamente: Descrio O atributo de descrio, como j mencionamos no Captulo 4, simplesmente a descrio da deciso, que mostra o que foi decidido na arquitetura. Na descrio, podemos encontrar (1) quais elementos arquiteturais devem estar presentes, caso seja uma deciso existencial; (2) quais propriedades devem se manifestar nos elementos ou quais regras ou princpios de design devem ser seguidos, caso seja uma deciso de propriedade; ou (3) qual metodologia deve ser seguida, como o time deve ser dividido para a implementao dos mdulos ou qual ferramenta deve ser utilizada para integrao, caso seja uma deciso executiva. A descrio pode ser representada usando diversas linguagens, podendo ser textuais ou grcas e formais ou informais. A escolha da linguagem que ser utilizada na descrio depende dos objetivos da deciso e dos stakeholders interessados. Se, entre os seus objetivos, queremos que a deciso permita tambm gerao automtica de parte da implementao, anlise baseada em modelos ou simulaes, ou vericao de conformidade, a descrio deve utilizar linguagens formais ou semiformais que facilitam estas atividades. Por outro lado, se esperamos que a deciso apenas informe que elementos devem estar na arquitetura e suas caractersticas, mas no esperamos gerao, anlise ou vericao automticas, linguagens semiformais ou mesmo informais podem ser utilizadas, como a lngua Portuguesa ou diagramas caixas e setas,
158
desde que a ambiguidade seja evitada por meio de legendas ou explicaes mais detalhadas. Vale observar que tanto a utilizao de linguagens formais, quanto a utilizao de linguagens informais na descrio proporcionam vantagens e desvantagens que devem ser consideradas durante o processo de documentao. Ao utilizarmos linguagens formais, permitimos a automatizao de processos, que podem poupar bastante trabalho durante o desenvolvimento. Por outro lado, no so todos os stakeholders que as entendem perfeitamente, podendo restringir assim o entendimento da deciso. As linguagens informais, por sua vez, tm como vantagem a maior facilidade de entendimento por parte dos stakeholders (inclusive no-tcnicos, como gerentes, clientes e at usurios). No entanto, o entendimento s facilitado se a descrio evitar ambiguidades, que so comuns em linguagens informais. Uma forma de se conseguir mais vantagens nas decises seria utilizar tanto linguagens formais quanto informais nas descries das decises. Nada impede que isso seja feito, obtendo assim preciso na descrio, possibilidade de atividades automatizadas, e entendimento por parte dos stakeholders tcnicos e no-tcnicos. O problema reside apenas na grande quantidade de trabalho empregado ao descrever cada deciso com duas ou mais linguagens e, ainda por cima, ter que manter a consistncia da descrio entre elas. A seguir, mostramos a descrio da deciso arquitetural j apresentada no Exemplo 4.10 usando diferentes linguagens diferentes. O primeiro exemplo mostra a deciso escrita em Portugus. Exemplo 8.12 ((Deciso Arquitetural 001)). A arquitetura do SASF dividida em trs camadas lgicas: apresentao, lgica de negcio e persistncia de dados. A camada de apresentao se comunica apenas com a lgica de negcio e apenas a lgica de negcio de comunica com a camada de persistncia de dados. J o exemplo a seguir mostra a descrio usando tambm um cdigo que pode ser interpretado pela ferramenta DesignWizard 8 e que permite a vericao automtica de conformidade do cdigo implementado com a arquitetura. Exemplo 8.13 ((Deciso Arquitetural 001)). A arquitetura do SASF dividida em trs camadas lgicas: apresentao, lgica de negcio e persistncia de da8
O artigo Design tests: An approach to programmatically check your code against design rules [13], de Brunet et al contm mais informaes sobre o DesignWizard.
159
dos, que sero mapeadas respectivamente para os pacotes: com.sasf.webui, com.sasf.service, com.sasf.storage. Os testes presentes na Listagem 8.1, que podem ser executados usando o DesignWizard, descrevem as regras de comunicao entre as camadas. Listagem 8.1 Testes para comunicao entre tiers. public class ThreeTierDesignTest extends TestCase { public void test_communication_web_ui_and_services() { String sasfClassesDir = System.getProperties("sasf.classes.directory"); DesignWizard dw = new DesignWizard(sasfClassesDir); PackageNode services = dw.getPackage("com.sasf.service"); PackageNode webUI = dw.getPackage("com.sasf.webui"); Set<PackageNode> callers = services.getCallerPackages(); for (PackageNode caller : callers) { assertTrue(caller.equals(webUI)); } } public void test_communication_services_and_storage() { String sasfClassesDir = System.getProperties("sasf.classes.directory"); DesignWizard dw = new DesignWizard(sasfClassesDir); PackageNode services = dw.getPackage("com.sasf.service"); PackageNode storage = dw.getPackage("com.sasf.storage"); Set<PackageNode> callers = storage.getCallerPackages(); for (PackageNode caller : callers) { assertTrue(caller.equals(services)); } } }
160
Objetivo O objetivo da deciso serve para registrarmos o motivo da deciso estar sendo tomada. Como decises de design so conduzidas por requisitos, sejam eles funcionais ou de qualidade, a identicao dos requisitos deve estar presente neste atributo. Os objetivos das decises arquiteturais ajudam na rastreabilidade da arquitetura. No Exemplo 8.14, percebemos duas formas de meno aos requisitos implementados pela deciso. A primeira forma presena o identicador do requisito de qualidade, RNF-01. J a outra forma uma breve descrio do requisito alcanado. Exemplo 8.14 ((continuao da Deciso Arquitetural 001)). Objetivo : Atendimento ao requisito no-funcional: RNF-01. Esta diviso diminui o acoplamento entre os elementos internos da arquitetura, facilitando o desenvolvimento e a manuteno. Fundamentao Uma deciso arquitetural deve ser tomada com alguma fundamentao, seja ela uma anlise das alternativas de design, baseada na experincia prvia do arquiteto, ou baseada em padres de design. Esta fundamentao resulta no julgamento das vantagens e desvantagens das alternativas e servem para justicar a soluo proposta. No atributo fundamentao, registramos a justicativa da deciso para que haja um registro histrico das motivaes e consideraes feitas pelo arquiteto para chegar soluo de design. Este registro essencial para que este tipo de informao no seja esquecido ao longo do ciclo de vida do software, pois importante para o seu processo de evoluo. Por exemplo, durante uma atividade de refatorao do cdigo, um novo desenvolvedor pode se interessar pelo motivo de um mdulo ter sido criado aparentemente de forma desnecessria. Se no existir algum tipo de registro do motivo para existncia do mdulo em questo, o novo desenvolvedor pode, simplesmente, modic-lo ou mesmo remov-lo ignorante dos efeitos que pode causar no design. A fundamentao normalmente feita por meio de uma descrio textual, mas deve possuir referncias a outros documentos e a outras decises arqui-
161
teturais relacionadas. O exemplo a seguir ilustra a fundamentao de uma deciso arquitetural. Exemplo 8.15 ((continuao da Deciso Arquitetural 001)). Fundamentao: Projetar os elementos internos do sistema de modo que cada um pertena a apenas uma camada lgica ajuda a aumentar a coeso e diminuir o acoplamento. A coeso aumenta, pois cada elemento ser desenvolvido com o objetivo de ser parte da apresentao, da lgica ou da persistncia do sistema. Dessa maneira, cada elemento ter sua responsabilidade bem denida, mesmo que em alto nvel. Como a comunicao entre as camadas pr-denida, a de seus elementos tambm : elementos da camada de apresentao no se comunicaro com elementos da camada de persistncia, por exemplo. Assim, o acoplamento entre elementos internos ser anlogo ao acoplamento entre camadas. Com o baixo acoplamento, o desenvolvimento e a manuteno dos elementos tambm facilitado, seja por possibilitar o desenvolvimento independente, seja por mudanas em um elemento terem menor impacto nos outros. importante observar que uma deciso arquitetural pode estar relacionada a mais de um atributo de qualidade e, como veremos a seguir, a mais de uma categoria. Isso ocorre porque decises arquiteturais se interrelacionam da mesma forma que os atributos de qualidade e os requisitos impostos pelos stakeholders. Portanto, na fundamentao que devemos tambm descrever as relaes entre as decises arquiteturais, ou seja, se uma deciso restringe, probe, possibilita, conita, sobrepe, compe ou composta de, depende de, ou uma alternativa a outras decises. Escopo Nem todas as decises arquiteturais so vlidas durante todo o ciclo de vida do software ou vlidas em todos os mdulos que o compem. Por isso, surge a necessidade de registrar o escopo da deciso. Este registro tipo de registro se torna importante em decises de propriedades, uma vez que normalmente tratam de preocupaes transversais e abrangem grandes partes do sistema, e em decises executivas, que devem, por exemplo, especicar quais etapas do processo de desenvolvimento devem usar tais metodologias.
162
O Exemplo 8.16, a seguir, descreve o escopo da Deciso Arquitetural 001, que bem abrangente. J no Exemplo 8.17, podemos observar que o escopo da deciso de usar JMX9 como tecnologia de monitorao mais limitado. Exemplo 8.16 ((continuao da Deciso Arquitetural 001)). Escopo : Esta deciso vlida para todos os servios que implementam lgica e que tm interface com o usurio. Exemplo 8.17. Escopo : A deciso de usar JMX para exposio das mtricas de desempenho s vlida para os casos denidos na [Deciso Arquitetural 008]. Histrico A documentao da arquitetura, assim como o que ela representa, evolui ao longo do tempo. Decises so tomadas, avaliadas, modicadas ou mesmo contestadas ao longo do ciclo de vida da arquitetura. Portanto, de se esperar que exista um registro histrico da evoluo de cada deciso arquitetural. Por isso consideramos o atributo histrico. O atributo histrico deve conter, para cada modicao da deciso, uma marca de tempo, o autor da modicao e um resumo da modicao. Se o documento estiver armazenado em um wiki ou outra forma eletrnica, o histrico pode conter links para as verses anteriores da deciso. O Exemplo 8.18 ilustra o registro histrico da Deciso Arquitetural 001. Exemplo 8.18 ((continuao da Deciso Arquitetural 001)). Histrico : sugerida (G. Germoglio, 2009/07/15); revisada, Escopo modicado. (G. Germoglio, 2009/07/17); aprovada (J. Sauv, 2009/07/18). Estado Atual O atributo estado atual de uma deciso serve para permitir mais uma dimenso de organizao das decises. Da mesma forma que as decises evoluem ao longo do tempo, elas podem ter diversos estados que merecem ser registrados. Como o conjunto de estados que podem ser atribudos a uma deciso arquitetural depende do processo de desenvolvimento adotado, citamos apenas alguns estados mais comuns:
9
Java Management Extensions (JMX): http://java.sun.com/products/JavaManagement/
8.3 Vises arquiteturais
163
Sugerida: deciso que ainda no foi avaliada; Revisada: deciso sugerida e revisada pelo arquiteto ou time arquitetural; Aprovada: deciso sugerida, revisada e aprovada; Rejeitada: deciso sugerida, revisada e rejeitada. Ela deve se manter na documentao para referncias futuras.
Categoria Assim como o estado atual, o atributo categoria serve para possibilitar a organizao das decises arquiteturais em grupos relacionados. Normalmente, esse atributo composto por uma lista de palavras-chave associadas s decises. Esse atributo permite, por exemplo, que os stakeholders selecionem decises relacionadas a um atributo de qualidade especco. Portanto, se um membro do grupo de garantia de qualidade do software (Software Quality Assurance ou SQA) precisa das decises arquiteturais necessrias para realizar uma anlise de desempenho do projeto do software, ele deve procurar pelas decises da categoria desempenho.

Como consequncia da existncia dos diversos interessados na arquitetura e que esses interessados tm diferentes preocupaes e diferentes nveis de conhecimento, as decises arquiteturais no so documentadas da mesma maneira para interessados diferentes. Para resolver este problema, fazemos uso do conceito de mltiplas vises arquiteturais. Vises arquiteturais so representaes do sistema ou de parte dele da perspectiva de um conjunto de interesses relacionados. A vises arquiteturais proporcionam vantagens tanto para o processo de design, quanto para a documentao da arquitetura. Durante o design, o arquiteto pode se focar em diferentes vises separadamente, podendo abstrair os detalhes desnecessrios e s se ater s preocupaes da viso corrente. Por exemplo, inicialmente, o arquiteto se pode utilizar de uma viso funcional para projetar os servios primitivos do sistema que constituiro servios mais complexos e que, por sua vez, serviro de base para as funcionalidades expostas aos usurios. Em seguida, o arquiteto pode se utilizar de uma viso de concorrncia para projetar como as funes sero
164
executadas ao longo do tempo: de forma sequencial ou em paralelo, de forma sncrona ou assncrona. E, por m, focando-se numa viso informacional, ele pode denir como os dados esto organizados. Por outro lado, durante o processo de documentao, o arquiteto pode documentar as vises com diferentes nveis de detalhes e utilizar diferentes linguagens, uma vez que diferentes vises interessam a diferentes stakeholders. As vises so concretizaes do que chamamos pontos de vista arquiteturais10 . Um ponto de vista arquitetural a especicao dos elementos conceituais que devem ser usados para se construir uma viso. Um ponto de vista apresenta tambm qual o seu propsito e quem so os stakeholders interessados nas vises criadas a partir dele. Em outras palavras, um ponto de vista arquitetural denido como: Denio 8.1 (ponto de vista arquitetural). um arcabouo conceitual que dene elementos, conexes e tcnicas que compem uma viso arquitetural, alm especicar seu propsito de acordo com seus interessados. Para documentarmos a arquitetura, devemos denir um conjunto pontos de vista que serviro de base para as vises da arquitetura e que estaro presentes no documento. Cada viso ter uma ou mais decises arquiteturais, que sero descritas a partir dos elementos, conexes e tcnicas denidos pelo ponto de vista a que pertence. Como j existem diversos conjuntos de pontos de vista prontos para uso na literatura, no h motivo para criarmos o nosso prprio conjunto. Portanto, a seguir, apresentamos alguns conjuntos os quais achamos essencial o conhecimento. So eles: 4+1 de Kruchten; Pontos de vista de Rozanski e Woods. Pontos de vista do Software Engineering Institute ;
8.3.1 4+1 de Kruchten O conjunto de pontos de vista 4+1 de Kruchten foi descrito inicialmente no artigo The 4+1 View Model of Architecture [49] e um dos primeiros a serem
10
Viewpoints, de acordo com o padro ISO/IEEE 1471-2000, ou viewtypes (tipos de viso), de acordo com Clements et al em Documenting Software Architectures: Views and Beyond.
165
descritos na literatura. Inicialmente, os pontos de vista so chamados pelo autor de vises. No entanto, se analisarmos a denio e o uso das vises empregados pelo autor, percebemos ela so compatveis com nossas denies e usos dos pontos de vista. O conjunto composto por quatro pontos de vista, sendo cada um especializado em um aspecto da arquitetura, e um ponto de vista redundante, que contm cenrios de uso. Os pontos de vista mais relevantes desse conjunto so: Lgico, de Processos, de Desenvolvimento e Fsico. Como o conjunto de Rozanski e Woods uma evoluo do 4+1, ao descrev-lo na Seo 8.3.2, apresentaremos melhor os pontos de vista de Kruchten. 8.3.2 Viewpoints de Rozanski e Woods Outro conjunto importante de pontos de vista o descrito por Rozanski e Woods no livro Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [72]. Ele uma evoluo do conjunto 4+1, pois adiciona dois novos pontos de vista ao conjunto de Kruchten, e prov mais informaes que ajudam no design do que na documentao. Os pontos de vista presentes neste conjunto so: Funcional : representa o aspecto funcional do software descrito. Vises derivadas deste ponto de vista contm decises sobre as funes presentes no software e os mdulos e submdulos que implementam essas funes. Este ponto de vista especializado em mostrar a estrutura esttica do software, mostrando suas partes, suas relaes e suas interfaces. Seu equivalente no conjunto de Kruchten o ponto de vista Lgico. de Concorrncia : representa os aspectos dinmicos e comportamentais do software. Vises derivadas deste ponto de vista contm decises sobre concorrncia, sincronia ou assincronia de chamadas e aspectos temporais em geral do software e de suas funes. Seu equivalente no conjunto de Kruchten o ponto de vista de Processo. de Desenvolvimento : representa os aspectos e relaes entre os stakeholders e o processo de desenvolvimento do software. Vises derivadas deste ponto de vista contm decises de divises de mdulos, subsistemas, pacotes e classes e decises sobre a atribuio de tarefas de construo, teste e reuso de partes do sistema aos participantes da equipe de desenvolvimento. Seu equivalente no conjunto de Kruchten homnimo.
166
de Implantao : representa os aspectos de implantao do software e suas relaes com o ambiente fsico. Vises derivadas deste ponto de vista contm decises de quantos servidores sero necessrios para execuo de um servio ou como os diferentes servios so implantados ou atualizados durante o ciclo de vida do software. Seu equivalente no conjunto 4+1 o
ponto de vista Fsico. Informacional : representa os aspectos relacionados aos dados presentes no software. Vises derivadas deste ponto de vista contm decises sobre o modelo de dados e sobre o armazenamento, manipulao, gerenciamento e distribuio das informaes ao longo da vida do sistema em produo.
Operacional : representa os aspectos operacionais do software. Ou seja, vises derivadas deste ponto de vista contm decises com estratgias de execuo, administrao e suporte do software em produo.
8.3.3 Viewtypes do Software Engineering Institute (SEI) O ltimo conjunto de pontos de vista que apresentamos o descrito por Clements et al no livro Documenting Software Architectures: Views and Beyond [20]. Este conjunto foi criado com o objetivo de facilitar a documentao, ao contrrio da maioria descrita na literatura, que tm seu foco no auxlio do projeto da arquitetura. O conjunto do SEI possui apenas trs pontos de vista, que devem ser especializados por meio dos chamados estilos arquiteturais. Os pontos de vista deste conjunto so: de Componentes e Conectores : este ponto de vista se preocupa em descrever os aspectos dinmicos e de comportamento e interaes entre os elementos da arquitetura. nele em que encontramos os estilos arquiteturais: Pipes-and-lters, Publish-Subscribe, Cliente-Servidor, Peer-to-Peer e outros. de Mdulos : este ponto de vista se preocupa em descrever a estrutura esttica da arquitetura e em como ela se divide em unidades de cdigo. O estilo arquitetural Camadas uma especializao desse ponto de vista. de Alocao : este ponto de vista se preocupa em descrever as relaes entre o software e o seu ambiente. O ponto de vista de Alocao se especializa em trs aspectos diferentes: aspectos de implantao, que descreve as relaes entre as partes do software e os recursos fsicos utilizados (como servidores
8.4 Documentando a Arquitetura
167
ou roteadores); aspectos de implementao, que descreve o mapeamento das partes do software e as partes do cdigo (como pacotes, classes ou estrutura de diretrios); e aspectos de atribuio de trabalho, relacionados distribuio de responsabilidades do projeto entre os membros do time de desenvolvimento.

A partir dos conceitos de decises, vises e pontos de vista arquiteturais, estamos aptos a registrar o design da arquitetura em um documento. O primeiro passo para sermos capazes de escrever um bom documento arquitetural conhecer os interessados na arquitetura. Esse conhecimento um parmetro fundamental para o processo de escolha dos pontos de vista a serem usados. Depois de denir os pontos de vista relevantes aos stakeholders da arquitetura, devemos ento registrar as decises arquiteturais que descrevem o design em vises derivadas a partir dos pontos de vista escolhidos. Devemos observar que os processos de denio dos stakeholders, de escolha dos pontos de vista arquiteturais e de descrio das decises em vises so dependentes do processo de desenvolvimento seguido pelo time de desenvolvimento. Alm disso, apesar de descrevermos separadamente o processo de documentao do processo de design, possvel (e bastante comum) que ocorram em paralelo, uma vez que a documentao e o design se ajudam mutuamente para alcanar seus objetivos. 8.4.1 Diculdades da Documentao Apesar dos benefcios proporcionados pela documentao da arquitetura, document-la no fcil. A diculdade de documentar a arquitetura reside, principalmente, em trs caractersticas que descrevemos a seguir: o documento reete o tamanho da soluo; o documento reete a complexidade do design da soluo; custoso manter o documento consistente com o design atual ao longo do ciclo de vida do software.
168
O tamanho do documento Projetos de grandes sistemas de software so os que mais se beneciam com o design e com a documentao da arquitetura. Isto ocorre porque o design e a documentao proporcionam orientao na implementao dos requisitos de qualidade, ajuda no controle intelectual sobre a complexidade da soluo e servem de ferramenta que promove a integridade conceitual entre os stakeholders. No entanto, um grande sistema de software implica numa grande soluo de design, que deve conter muitas decises arquiteturais e que devem ser apresentadas a muitos stakeholders, que demandam vises diferentes. A consequncia disso que a arquitetura de um grande sistema dever ser apresentada em um documento extenso. Documentos muito extensos podem ser fonte de alguns problemas durante o processo de desenvolvimento. Entre estes problemas, podemos citar que eles levam muito tempo para serem construdos e que, em geral, geram uma certa resistncia para serem lidos ou atualizados durante o desenvolvimento. Se o documento no lido ou no atualizado durante o desenvolvimento (e isso pode ocorrer porque a arquitetura pode evoluir ao longo do tempo, seja a evoluo planejada ou no), ele corre o risco de car inconsistente com a realidade do software, tornando-se uma fonte de informao intil e, portanto, deixando de proporcionar as vantagens de se projetar e documentar a arquitetura. A complexidade do documento Tanto o tamanho do documento quanto a complexidade do design inuenciam na complexidade do documento da arquitetura. Um documento muito complexo, que usa muitas vises e diferentes linguagens para descrever diferentes aspectos do software, difcil de se construir e de se manter consistente em caso de mudanas durante a evoluo da arquitetura. Como j mencionamos anteriormente, existem tcnicas de vericao de conformidade entre o documento de arquitetura e o software implementado a partir dele, que podem ajudar na manuteno da consistncia do documento com a realidade. No entanto, devemos nos lembrar que h tambm o esforo de se manter as diferentes vises arquiteturais consistentes entre si. Isso pode at ser facilitado se usarmos algumas linguagens especcas e ferramentas para
169
descrever as decises arquiteturais, como a ferramenta SAVE11 . Por outro lado, estas linguagens no so capazes de descrever todos os tipos necessrios de decises arquiteturais e isso limita o processo de automao na manuteno de consistncia entre vises, tornando-o custoso. Consistncia entre o design atual e o documento A consistncia entre a implementao e o documento condio fundamental para que o processo de desenvolvimento se benecie da arquitetura. Por isso, deve existir um esforo para a manuteno desta consistncia, tanto durante a evoluo da arquitetura, quanto durante a implementao do software. Se a manuteno da consistncia no realizada, temos o chamado deslize arquitetural (architectural drift ). O deslize arquitetural a inconsistncia entre implementao do software e o design planejado. Esta inconsistncia tem dois efeitos. O primeiro que se a implementao no est seguindo o que foi planejado, ela pode tambm no estar alcanando os objetivos propostos. J o segundo, como foi mencionado anteriormente, que a inconsistncia do documento com a realidade do software, inutiliza o documento, pois o transforma numa fonte de informao intil. Assim, considerando que custoso o processo de criao do documento de arquitetura, todo o trabalho realizado para tanto pode ter sido em vo. Para a evitar o deslize arquitetural, recomenda-se que sejam periodicamente utilizadas durante todo o processo de desenvolvimento tcnicas de vericao de conformidade. Essas tcnicas, quando aplicadas, indicam se a implementao est de acordo com o design. H basicamente dois tipos de tcnicas de vericao de conformidade: as tcnicas manuais, que so baseadas em inspees do cdigo; e as tcnicas automticas, que s podem ser realizadas se a descrio da arquitetura utilizar linguagens que permitam esse tipo de vericao. Assim como os tipos de anlise arquitetural, as tcnicas de vericao manuais so mais custosas, mas tm um maior alcance, podendo vericar aspectos do software que no so formalizados. J as tcnicas de vericao automticas, se beneciam do baixo custo, mas so limitadas aos aspectos que podem ser descritos pelas linguagens formais que utilizam.
11
Software Architecture Visualization http://fc-md.umd.edu/save/default.asp
and
Evaluation
(SAVE):
170
Resumo
O objetivo deste livro no s fazer com que o leitor saiba projetar arquiteturas, mas tambm que tenha noes de como documentar o projeto. Dessa maneira, o objetivo deste captulo foi fazer com que o leitor conhea a importncia e a tcnica primordial da documentao da arquitetura, que represent-la por meio de mltiplas vises. Assim, esperamos que a partir de agora o leitor, alm de conhecer alguns conjuntos de pontos de vista arquiteturais de referncia, seja capaz de entender que: O documento de arquitetura auxilia no processo de design, uma ferramenta de comunicao entre stakeholders e pode servir de modelo de anlise do software; Toda informao presente numa arquitetura uma deciso arquitetural; Decises arquiteturais podem ser existenciais, descritivas ou executivas; Decises arquiteturais se relacionam, podendo restringir, impedir, facilitar, compor, conitar, ignorar, depender ou ser alternativa a outras decises arquiteturais; e Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto. Por isso, a necessidade de mltiplas vises arquiteturais.
Referncias
Benefcios da documentao Muitos autores armam que a documentao do design arquitetural benca para o processo de desenvolvimento do software. Alm dos trabalhos j referenciados ao longo do texto, citamos: o livro The Art of Systems Architecting [56] de Maier e Rechtin, que descreve os benefcios proporcionados quando o documento de arquitetura consistente entre suas mltiplas vises; o artigo de Wirfs-Brock, Connecting Design with Code [84], que cita a importncia de documentar as decises de design em diversos nveis de detalhe, inclusive o arquitetural; o livro Software Architecture: Foundations, Theory, and Practice [81], de Taylor et al, que mostra este assunto de forma bem abrangente; e o livro Code Complete [60], de McConnell, que arma a arquitetura uma ferramenta para o controle da complexidade do software.
171
Arquitetura como conjunto de decises O documento de arquitetura descrito como um conjunto de decises arquiteturais o tema de diversos artigos. Entre eles, podemos citar: Building Up and Reasoning About Architectural Knowledge [51], An Ontology of Architectural Design Decisions in Software Intensive Systems [52] e The Decision Views Role in Software Architecture Practice [50], de Kruchten et al e que so focados em descrever a arquitetura como decises arquiteturais e em montar um arcabouo conceitual de como descrever decises arquiteturais, propondo inclusive um ponto de vista neste sentido; Architecture Knowledge Management: Challenges, Approaches, and Tools [4], de Babar e Gorton, que mostram ferramentas para organizar e documentar as decises arquiteturais; e The Decision View of Software Architecture [26], de Dueas e Capilla, e Software Architecture as a Set of Architectural Design Decisions [42], de Jansen e Bosch, que mostram a importncia das decises na arquitetura. Vises e pontos de vista Alm dos trabalhos que apresentam conjuntos de pontos de vista e que j foram referenciados na Seo 8.3, podemos citar o livro Software Design [14], de Budgen, que arma que diferentes representaes lidam com diferentes qualidades e interesses, alm de mostrar alguns benefcios de se documentar a arquitetura por meio de vises. J o artigo Four Metaphors of Architecture in Software Organizations: Finding Out the Meaning of Architecture in Practice [78], de Smolander, descreve como alguns stakeholders percebem a arquitetura na prtica e assim justica o uso de vises arquiteturais. Por m, citamos o livro Applied Software Architecture [37], de Hofmeister et al, que apresenta mais um conjunto de pontos de vista. Ferramentas para anlise Em relao a anlises baseadas em inspees, citamos o livro da srie do SEI, Evaluating Software Architectures [21], de Clements et al, que descreve os mtodos SAAM, ATAM e ARID, inclusive com estudos de casos. J sobre ADLs, citamos dois surveys sobre o assunto: um conduzido por Clements, A Survey of Architecture Description Languages [19], e outro por
172
Taylor e Medvidovic, A Classication and Comparison Framework for Software Architecture Description Languages [61]. E, nalmente, apresentamos alguns trabalhos sobre vericao de conformidade: Software Reexion Models: Bridging The Gap Between Design and Implementation [63] e Software Reexion Models: Bridging The Gap Between Source and High-Level Models [64], por Murphy et al ; Bridging the Software Architecture Gap [54], de Lindvall e Muthig; e Design tests: An approach to programmatically check your code against design rules [13], de Brunet et al.
Exerccios
8.1. Quais os benefcios proporcionados pela documentao da arquitetura? 8.2. Descreva um caso em que a documentao serve de ferramenta de comunicao durante o processo de desenvolvimento. 8.3. Pesquise exemplos para cada tipo de anlise da arquitetura, descreva-os brevemente e cite suas vantagens e desvantagens de uso. 8.4. O que so decises arquiteturais? Cite exemplos. 8.5. Que tipos de decises arquiteturais podem ser encontradas em um documento de arquitetura? Cite exemplos. 8.6. Descreva agora as decises arquiteturais citadas como resposta dos Exerccios 8.4 e 8.5 usando os atributos de decises apresentados neste captulo. 8.7. Escolha uma das decises da resposta do exerccio anterior e descreva-a usando linguagens de representao diferentes. Quais os benefcios das linguagens utilizadas? Quais as desvantagens? 8.8. O que so vises e pontos de vista arquiteturais? Qual o seu papel na arquitetura e no processo de desenvolvimento? 8.9. Descreva decises arquiteturais utilizando os pontos de vista do conjunto de Kruchten [49]. 8.10. Descreva decises arquiteturais utilizando os pontos de vista do conjunto de Rozanski e Woods [72]. 8.11. Descreva decises arquiteturais utilizando os pontos de vista do conjunto do SEI [20].
Referncias
1. Alain Abran, James W. Moore, Pierre Bourque, Robert Dupuis, and Leonard L. Tripp. Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE, 2004. 2. Robert Allen and David Garlan. A formal basis for architectural connection. ACM Trans. Softw. Eng. Methodol., 6(3):213249, July 1997. 3. Andy and Kai Qian. Component-Oriented Programming. Wiley-Interscience, March 2005. 4. Muhammad A. Babar and Ian Gorton. Architecture Knowledge Management: Challenges, Approaches, and Tools. In Software Engineering - Companion, 2007. ICSE 2007 Companion. 29th International Conference on, pages 170171, 2007. 5. Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1 edition, 1998. 6. Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley Professional, 2 edition, April 2003. 7. L. Belady. Foreword. In Software Design: Methods and Techniques (L.J. Peters, author). Yourdon Press, 1981. 8. B. W. Boehm, J. R. Brown, and M. Lipow. Quantitative Evaluation of Software Quality. In International Conference on Software Engineering, pages 592605, San Francisco, 1976. IEEE Computer Society Press. 9. G. Booch. Goodness of t. Software, IEEE, 23(6):1415, 2006. 10. Grady Booch. The Irrelevance of Architecture. Software, IEEE, 24(3):1011, 2007. 11. Grady Booch, Robert A. Maksimchuk, Michael W. Engel, Bobbi J. Young, Jim Conallen, and Kelli A. Houston. Object-Oriented Analysis and Design with Applications. Addison-Wesley Professional, 3rd edition, April 2007.
174
Referncias
12. Frederick P. Brooks. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Addison-Wesley Professional, August 1995. 13. J. Brunet, D. Guerrero, and J. Figueiredo. Design tests: An approach to programmatically check your code against design rules. In Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, pages 255258, 2009. 14. David Budgen. Software Design. Addison Wesley, 2 edition, May 2003. 15. Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt. Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. Wiley, May 2007. 16. Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt. Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages. Wiley, June 2007. 17. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons, August 1996. 18. J. N. Buxton and B. Randell. Software Engineering Techniques. Technical report, NATO Science Committee, Rome, Italy, April 1970. 19. P. C. Clements. A survey of architecture description languages. In Software Specication and Design, 1996., Proceedings of the 8th International Workshop on, pages 1625, 1996. 20. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Staord. Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional, September 2002. 21. Paul Clements, Rick Kazman, and Mark Klein. Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley Professional, January 2002. 22. J. Dean and S. Ghemawat. MapReduce: Simplied Data Processing on Large Clusters. 6th Symposium on Operating Systems Design & Implementation (OSDI04), 2004. 23. Defense Information Systems Agency. Department of Defense Joint Technical Architecture, Version 6.0. Volume 2. U.S. Department of Defense, October 2003. 24. Chris Dibona, Mark Stone, and Danese Cooper. Open Sources 2.0 : The Continuing Evolution. OReilly Media, Inc., October 2005. 25. Edsger W. Dijkstra. The Structure of The THE-multiprogramming System. Commun. ACM, 11(5):341346, 1968. 26. Juan C. Dueas and Rafael Capilla. The Decision View of Software Architecture. pages 222230. 2005. 27. George Edwards, Sam Malek, and Nenad Medvidovic. Scenario-Driven Dynamic Analysis of Distributed Architectures. pages 125139. 2007.
Referncias
175
28. S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and A. Mockus. Does code decay? assessing the evidence from change management data. Software Engineering, IEEE Transactions on, 27(1):112, 2001. 29. Facebook Team. Engineering @ Facebook. http://www.facebook.com/notes.php?id=9445547199 . 30. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. 31. Brian Foote and Joseph W. Yoder. Big Ball of Mud. In N. Harrison, B. Foote, and H. Rohnert, editors, Pattern Languages of Program Design, volume 4, pages 654692. Addison Wesley, 2000. 32. M. Fowler. Design - who needs an architect? Software, IEEE, 20(5):1113, 2003. 33. Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, November 2002. 34. David Garlan and Mary Shaw. An Introduction to Software Architecture. Technical Report CMU-CS-94-166, Carnegie Mellon University, Pittsburgh, PA 15213-3890, January 1994. 35. Ian Gorton. Essential Software Architecture. Springer, June 2006. 36. Todd Ho. High Scalability: Building bigger, faster, more reliable websites. http://highscalability.com/ . 37. Christine Hofmeister, Robert Nord, and Dilip Soni. Applied Software Architecture. Addison-Wesley Professional, November 1999. 38. Luke Hohmann. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional, January 2003. 39. IEEE and ISO/IEC. Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems. ISO/IEC 42010 IEEE Std 1471-2000 First edition 2007-07-15, pages c124, July 2007. 40. IEEE Std 754-2008. IEEE Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers, 2008. 41. ISO 9126-1:2001. Software engineering Product quality Part 1: Quality model. International Organization for Standardization, Geneva, Switzerland. 42. A. Jansen and J. Bosch. Software architecture as a set of architectural design decisions. In Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, pages 109120, Washington, DC, USA, 2005. IEEE Computer Society. 43. D. Kalinsky and J. Ready. Distinctions Between Requirements Specication and Design of Real-Time Systems. In Software Engineering for Real Time Systems, 1989., Second International Conference on, pages 2630, 1989. 44. Freny Katki, Louise Mcmonegal, Bennett Meyer, John Lane, Paul Wilson, Jane Radatz, Mary Yee, Hugh Porteous, and Fredrick Springsteel, editors. IEEE
176
Referncias Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., The, 1991.
45. Hermann Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. Springer, April 1997. 46. Gerald Kotonya and Ian Sommerville. Requirements Engineering: Processes and Techniques. John Wiley & Sons, September 1998. 47. P. Kruchten. The Software Architect and The Software Architecture Team. Software Architecture; TC2 First Working IFIP Conference on Software Architecture (WICSA1), 2:565583. 48. P. Kruchten, H. Obbink, and J. Staord. The past, present, and future for software architecture. Software, IEEE, 23(2):2230, 2006. 49. P. B. Kruchten. The 4+1 View Model of Architecture. Software, IEEE, 12(6):42 50, 1995. 50. Philippe Kruchten, Rafael Capilla, and Juan C. Dueñas. The Decision Views Role in Software Architecture Practice. IEEE Software, 26(2):3642, 2009. 51. Philippe Kruchten, Patricia Lago, Hans van Vliet, and Timo Wolf. Building up and exploiting architectural knowledge. In WICSA 05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA05), pages 291292, Washington, DC, USA, 2005. IEEE Computer Society. 52. Philippe Krutchen. An Ontology of Architectural Design Decisions in Software Intensive Systems. In 2nd Groningen Workshop Software Variability, pages 54 61, October 2004. 53. Herbert Lin. The development of software for ballistic-missile defense. Sci. Am., 253(6):4653, 1985. 54. M. Lindvall and D. Muthig. Bridging the software architecture gap. Computer, 41(6):98101, June 2008. 55. John D. C. Little. A Proof for the Queuing Formula: L= W. Operations Research, 9(3):383387, 1961. 56. Mark W. Maier and Eberhardt Rechtin. The Art of Systems Architecting. CRC, 2 edition, June 2000. 57. Ruth Malan and Dana Bredemeyer. Dening Non-Functional Requirements. Online at: http://www.bredemeyer.com/pdf_les/NonFunctReq.PDF, August 2001. 58. Matthew R. McBride. The software architect: Essence, intuition, and guiding principles. In OOPSLA 04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pages 230235. ACM Press, 2004.
Referncias
177
59. McCall, J. . Factors in Software Quality: Preliminary Handbook on Software Quality for an Acquisiton Manager, volume 1-3. General Electric, November 1977. 60. McConnell, Steve. Code Complete. Microsoft Press, second edition, June 2004. 61. N. Medvidovic and R. N. Taylor. A Classication and Comparison Framework for Software Architecture Description Languages. Software Engineering, IEEE Transactions on, 26(1):7093, 2000. 62. T. Mens and S. Demeyer, editors. Software Evolution. Springer, March 2008. 63. G. C. Murphy, D. Notkin, and K. J. Sullivan. Software Reexion Models: Bridging The Gap Between Design and Implementation. Software Engineering, IEEE Transactions on, 27(4):364380, April 2001. 64. Gail C. Murphy, David Notkin, and Kevin Sullivan. Software Reexion Models: Bridging The Gap Between Source and High-Level Models. In SIGSOFT 95: Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software engineering, pages 1828, New York, NY, USA, 1995. ACM. 65. Object Management Group, Inc. Unied modeling language.
http://www.uml.org, Agosto 2009. 66. D. L. Parnas. On the criteria to be used in decomposing systems into modules. Classics in Software Engineering, pages 139150. 67. David L. Parnas. Software aging. In ICSE 94: Proceedings of the 16th international conference on Software engineering, pages 279287, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press. 68. Dewayne E. Perry and Alexander L. Wolf. Foundations for The Study of Software Architecture. SIGSOFT Software Engineering Notes, 17(4):4052, October 1992. 69. Andy Powell, Mikael Nilsson, Ambjrn Naeve, Pete Johnston, and Thomas Baker. DCMI Abstract Model. DCMI Recommendation, June 2007. 70. Roger Pressman. Software Engineering: A Practitioners Approach. McGrawHill Science/Engineering/Math, 6 edition, April 2004. 71. Jack W. Reeves. What is Software Design? C++ Journal, 1992. 72. Nick Rozanski and Ein Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, April 2005. 73. Jungwoo Ryoo, Phil Laplante, and Rick Kazman. In search of architectural patterns for software security. Computer, 42(6):98100, 2009. 74. Yasushi Saito and Marc Shapiro. Optimistic Replication. ACM Comput. Surv., 37(1):4281, March 2005. 75. Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. PatternOriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects. John Wiley & Sons, September 2000.
178
Referncias
76. Bart Smaalders. Performance anti-patterns. Queue, 4(1):4450, 2006. 77. G. F. Smith and G. J. Browne. Conceptual Foundations of Design Problem Solving. Systems, Man and Cybernetics, IEEE Transactions on, 23(5):1209 1219, 1993. 78. Kari Smolander. Four metaphors of architecture in software organizations: Finding out the meaning of architecture in practice. In ISESE 02: Proceedings of the 2002 International Symposium on Empirical Software Engineering, Washington, DC, USA, 2002. IEEE Computer Society. 79. Ian Sommerville. Software Engineering. Addison Wesley, 8 edition, June 2006. 80. Diomidis Spinellis and Georgios Gousios. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. OReilly Media, Inc., January 2009. 81. R. N. Taylor, Nenad Medvidovi, and Irvine E. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, January 2009. 82. Richard N. Taylor and Andre Van der Hoek. Software Design and Architecture The Once and Future Focus of Software Engineering. In FOSE 07: 2007 Future of Software Engineering, pages 226243, Washington, DC, USA, 2007. IEEE Computer Society. 83. Jilles van Gurp and Jan Bosch. Design Erosion: Problems and Causes. Journal of Systems and Software, 61(2):105119, March 2002. 84. Rebecca J. Wirfs-Brock. 25(2):2021, 2008. Connecting Design with Code. Software, IEEE,
ndice
arquitetura de software, 50 atributos de negcio, 115 agenda de lanamento, 117 custo e benefcio, 116 mercado-alvo, 116 time-to-market, 116 vida til, 117 atributos de qualidade, 15, 99 adaptabilidade, 114 adequao, 104 analisabilidade, 113 caractersticas, 102 compreensibilidade, 109 conabilidade, 106 desempenho, 110 ecincia, 109 escalabilidade, 110 horizontal, 110 vertical, 110 facilidade de aprendizado, 109 funcionalidade, 104 instalabilidade, 115 interoperabilidade, 105 manutenibilidade, 113 maturidade, 107 modicabilidade, 113
operabilidade, 109 portabilidade, 114 preciso, 105 recuperabilidade, 108 segurana, 105 testabilidade, 114 tolerncia a faltas, 107 trade-os, 102 usabilidade, 109 deciso arquitetural, 54 design alternativa de, 17 elementos de, 14 objetivos, 14 representao de, 18 restrio, 15 solues do, 20 design de software, 10 ISO/IEC 9126-1:2001, 103 modelos de qualidade, 103 ponto de vista arquitetural, 164 rastreamento de requisitos, 56 requisitos de software
180
ndice conitos entre, 84 denio, 81 exemplos, 85 relao com atributos de qualidade, 82 responsabilidades, 85 viso arquitetural, 65
diferenas, 96 requisitos funcionais, 14, 92 requisitos no-funcionais, 15, 93 de processo, 95 de produto, 94 externos, 95 stakeholders, 77

Arquitetura de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arquitetura de Software

Uploaded by

Copyright:

Available Formats

Guilherme Mauro Germoglio Barbosa

Universidade Federal de Campina Grande

A todos que ajudaram, obrigado.

Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Captulo 2: Introduo a Design de Software

Captulo 3: Estudo de Caso: SASF

Captulo 4: Fundamentos de Arquitetura de Software

Captulo 6: Atributos de Qualidade

Captulo 7: Tcnicas de Design Arquitetural

Captulo 8: Documentao da Arquitetura

2 Introduo ao Design de Software

2 Introduo ao Design de Software

2.1 Design de Software

Apache HBase : http://hbase.org Os dados so inseridos no HBase na forma (chave,valor).

2.1 Design de Software

2 Introduo ao Design de Software

2.1 Design de Software

2 Introduo ao Design de Software

2.2 Elementos do processo de design de software

2.2 Elementos do processo de design de software

Figura 2.1. Ilustrao do processo de design

2 Introduo ao Design de Software

2.2 Elementos do processo de design de software

2 Introduo ao Design de Software

2.2 Elementos do processo de design de software

2 Introduo ao Design de Software

2.2 Elementos do processo de design de software

Figura 2.2. Representao estrutural do programa de ordenao

Unied Modeling Language (UML)

2 Introduo ao Design de Software

2.2 Elementos do processo de design de software

Figura 2.3. Pseudocdigo do Merge sort

2 Introduo ao Design de Software

2.3 Nveis de design de software

2.4 Princpios e tcnicas de design de software

2.4 Princpios e tcnicas de design de software

2 Introduo ao Design de Software

2.4 Princpios e tcnicas de design de software

2 Introduo ao Design de Software

2.4 Princpios e tcnicas de design de software

2 Introduo ao Design de Software

2.4 Princpios e tcnicas de design de software

2 Introduo ao Design de Software

3 Estudo de Caso: SASF

3.1 Apresentao do estudo de caso

Netix : http://www.netflix.com/ iTunes Store : www.apple.com/itunes

3 Estudo de Caso: SASF

3.2 Funcionalidades do SASF

3.2 Funcionalidades do SASF

3 Estudo de Caso: SASF

Tambm chamado de full HD. Sua resoluo de 1920x1080 pixels.

3.2 Funcionalidades do SASF

3 Estudo de Caso: SASF

Figura 3.2. Diagrama de Casos de Uso simplicado do SASF

3.3 Capacidades do SASF

3.3 Capacidades do SASF

3 Estudo de Caso: SASF

Considerando um vdeo de 2 horas de durao 1 GB = 1.073.741.824 bytes

3 Estudo de Caso: SASF

4 Fundamentos de Arquitetura de Software

4.1 Motivao para desenvolver melhores sistemas

4 Fundamentos de Arquitetura de Software

4.3 Denio de Arquitetura de Software por Perry e Wolf

4.2 O que Arquitetura de Software