APS II Dissertacao - GuilhermeMauroGerrmoglioBarbosa

Universidade Federal de Campina Grande Centro de Engenharia Eltrica e Informtica Curso de Ps-Graduao em Cincia da Computao
Um Livro-texto para o Ensino de Projeto de Arquitetura de Software
Guilherme Mauro Germoglio Barbosa

Dissertao submetida Coordenao do Curso de Ps-Graduao em Cincia da Computao da Universidade Federal de Campina Grande Campus I como parte dos requisitos necessrios para obteno do grau de Mestre em Cincia da Computao.
rea de Concentrao: Cincia da Computao Linha de Pesquisa: Engenharia de Software
Jacques P. Sauv (Orientador)
Campina Grande, Paraba, Brasil c Guilherme Mauro Germoglio Barbosa, 04/09/2009
FICHA CATALOGRFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG
B238l 2009
Barbosa, Guilherme Mauro Germoglio Um livro-texto para o ensino de projeto de arquitetura de software / Guilherme Mauro Germoglio Barbosa. ! Campina Grande, 2009. 209 f. : il. Dissertao (Mestrado em Cincia da Computao) Universidade Federal de Campina Grande, Centro de Engenharia Eltrica e Informtica. Referncias. Orientadores: Prof. Dr. Jacques P. Sauv. 1. Arquitetura de Software 2. Engenharia de Software 3. Projeto 4. Ensino I. Ttulo. CDU 004.415.2(043)
Resumo
A arquitetura de software a organizao fundamental de um sistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios que conduzem seu design e evoluo. O projeto da arquitetura importante no processo de desenvolvimento, pois ele orienta a implementao dos requisitos de qualidade do software e ajuda no controle intelectual sobre complexidade da soluo. Alm disso, serve como uma ferramenta de comunicao que promove a integridade conceitual entre os stakeholders. No entanto, os diversos livros adotados em disciplinas de Projeto de Arquitetura de Software assumem que o leitor tenha experincia prvia em desenvolvimento de software. Por outro lado, se os leitores so inexperientes, como os alunos de graduao, os exemplos, exerccios, ou ausncia destes, e a abordagem utilizados nesses livros dicultam o aprendizado. O objetivo deste trabalho escrever um livro-texto introdutrio disciplina de Projeto de Arquitetura de Software que tenha como pblico-alvo o aluno inexperiente. Esse livro servir de apoio ao ensino da disciplina em nvel de graduao e abrange tpicos recomendados pelo Guide to the Software Engineering Body of Knowledge, produzido pela IEEE Computer Society. O contedo do livro deve capacitar o aluno a entender os benefcios de considerar a arquitetura no ciclo de vida do software, a documentar a arquitetura de um sistema de software, e a aprofundar seu conhecimento por meio de materiais at ento inadequados para seu nvel de experincia.
Abstract
The software architecture is the organization of a software system manifested in its modules, their relationships to the environment, and the principles that guide its design and evolution. The design of the software architecture is important to the development process because it guides the softwares quality attributes implementation and helps the intellectual control over the problem complexity. Besides that, the software architecture also supports conceptual integrity by being a tool for stakeholderss communication. Most of the books available on Software Architecture are intended for experienced students. However, the inexperienced ones, such as undergraduate students, are not able to fully benets from these books because they lack some previous knowledge required by many authors. The objective of this work is to write an introductory textbook on Software Architecture Design, which will be focused on such students. This book will then be able to support undergraduate courses on the subject and will cover topics recommended by the Guide to the Software Engineering Body of Knowledge, edited by the IEEE Computer Society. This book intends both to enable students to understand and apply the benets of architectural design and documentation processes on the software lifecycle, and to enable the students to easier comprehend more advanced books and articles, which were previously inadequate for their experience.
ii
Agradecimentos
A todos que ajudaram, muito obrigado.
iii
Contedo
1 Introduo 1.1 Evidncias da necessidade de estudar arquitetura de software . . . . . . . . 1.1.1 1.2 1.3 Consideraes sobre livros da rea . . . . . . . . . . . . . . . . . . 1 3 5 6 6 8 8 9 9 10 11 13 14 15 15 21 22 22 22 22 23 23
Objetivo do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relevncia do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Requisitos para um Livro-Texto 2.1 2.2 2.3 2.4 2.5 Discurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contedo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos pedaggicos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Avaliao criteriosa de livros sobre Arquitetura de Software 3.1 3.2 3.3 Critrios de Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avaliao dos livros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Metodologia 4.1 4.2 4.3 4.4 4.5 4.6 Encontrar os requisitos para um livro-texto . . . . . . . . . . . . . . . . . . Encontrar as mensagens para o livro-texto . . . . . . . . . . . . . . . . . . Organizar as mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . Escolher a abordagem do texto . . . . . . . . . . . . . . . . . . . . . . . . Construir a estrutura de acordo com as mensagens . . . . . . . . . . . . . . Evoluir o texto a partir da estrutura . . . . . . . . . . . . . . . . . . . . . . iv
CONTEDO 4.7 4.8
Avaliar o contedo atravs de cursos voltados para graduao e ps-graduao 23 Renar o texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 25 26 27 39 45 46 47 48 51 52 53 55 56 59 60 61 61 63 63 63 64 64 65 65 66 67
5 Concluses e Trabalhos Futuros 5.1 5.2 Consideraes sobre a avaliao . . . . . . . . . . . . . . . . . . . . . . . Consideraes sobre os trabalhos futuros . . . . . . . . . . . . . . . . . . .
A Mensagens do Livro B Introduo ao Design de Software B.1 Design de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1.1 B.1.2 O que Design de Software . . . . . . . . . . . . . . . . . . . . . Caractersticas de Design de Software . . . . . . . . . . . . . . . .
B.2 Elementos do processo de design de software . . . . . . . . . . . . . . . . B.2.1 B.2.2 B.2.3 B.2.4 B.2.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Representaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Nveis de design de software . . . . . . . . . . . . . . . . . . . . . . . . . B.4 Princpios e tcnicas de design de software . . . . . . . . . . . . . . . . . . B.4.1 B.4.2 B.4.3 B.4.4 B.4.5 B.4.6 B.4.7 B.4.8 Diviso e Conquista . . . . . . . . . . . . . . . . . . . . . . . . . Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulamento . . . . . . . . . . . . . . . . . . . . . . . . . . . Modularizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . Separao de preocupaes . . . . . . . . . . . . . . . . . . . . . . Acoplamento e coeso . . . . . . . . . . . . . . . . . . . . . . . . Separao de Decises de Execuo de Algoritmos . . . . . . . . . Separao de Interfaces de suas Implementaes . . . . . . . . . .
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTEDO C Estudo de Caso: SASF C.1 Apresentao do estudo de caso . . . . . . . . . . . . . . . . . . . . . . . C.2 Funcionalidades do SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2.1 C.2.2 C.2.3 Locao e Streaming de vdeo . . . . . . . . . . . . . . . . . . . . Busca, feedback e sugestes ao usurio . . . . . . . . . . . . . . . Disponibilizao de lmes e administrao do sistema . . . . . . .
vi 69 69 70 70 72 73 75 75 75 75 76 77 77 79 79 81 81 83 85 87 89 90 92 98 102 103 103 105 107 112
C.3 Capacidades do SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.3.1 C.3.2 C.3.3 C.3.4 C.3.5 Nmeros de usurios e aspectos de segurana . . . . . . . . . . . . Tamanho do inventrio e nmero de operaes por dia . . . . . . . Transmisses simultneas . . . . . . . . . . . . . . . . . . . . . . Adio de informaes sobre os vdeos . . . . . . . . . . . . . . . Tempos de resposta . . . . . . . . . . . . . . . . . . . . . . . . . .
C.4 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D Fundamentos de Arquitetura de Software D.1 Motivao para desenvolver melhores sistemas . . . . . . . . . . . . . . . D.2 O que Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . D.3 Denio de Arquitetura de Software por Perry e Wolf . . . . . . . . . . . D.4 Arquitetura de Software por Garlan e Shaw . . . . . . . . . . . . . . . . . D.5 Arquitetura de Software por Bass et al . . . . . . . . . . . . . . . . . . . . D.6 Arquitetura de Software pelo Padro ISO/IEEE 1471-2000 . . . . . . . . . D.7 Decompondo a denio de Arquitetura de Software . . . . . . . . . . . . D.7.1 Elementos arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . D.7.2 Decises arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . D.7.3 Atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . D.8 Vises da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.9 O Documento de Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . D.9.1 Benefcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.9.2 Diculdades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10 Por que documentar a arquitetura de software? . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTEDO E Stakeholders E.1 Quem so os interessados em um sistema de software? . . . . . . . . . . . E.1.1 Importncia dos interessados . . . . . . . . . . . . . . . . . . . . .
vii 113 114 116 118 119 120 121 124 126 127 128 135 138 138 139 139 139 151 152 152 152 153 153 153 154 155 157 158 158 160
E.2 Tipos de stakeholders e sua relao com os atributos de qualidade . . . . . E.2.1 E.2.2 E.2.3 Atendimento aos requisitos como medida de sucesso . . . . . . . . Conitos entre requisitos e atributos de qualidade . . . . . . . . . . Responsabilidades dos stakeholders . . . . . . . . . . . . . . . . .
E.3 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F Atributos de Qualidade F.1 F.2 Requisitos Funcionais e No-Funcionais . . . . . . . . . . . . . . . . . . . Atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.1 F.2.2 F.2.3 F.3 Limites s funcionalidades . . . . . . . . . . . . . . . . . . . . . . Relaes entre atributos de qualidade . . . . . . . . . . . . . . . . A quem interessa os atributos de qualidade . . . . . . . . . . . . .
Modelo de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.3.1 F.3.2 Padro ISO/IEC 9126-1:2001 . . . . . . . . . . . . . . . . . . . . Conitos entre atributos de qualidade . . . . . . . . . . . . . . . .
F.4
Atributos de Negcio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.1 F.4.2 F.4.3 F.4.4 F.4.5 Mercado-alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time-to-market . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custo e benefcio . . . . . . . . . . . . . . . . . . . . . . . . . . . Vida til . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agenda de lanamento . . . . . . . . . . . . . . . . . . . . . . . .
F.5
Design Arquitetural para Qualidade de Software . . . . . . . . . . . . . . .
Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G Tcnicas de Design Arquitetural G.1 Princpios e Tcnicas de Design Arquitetural . . . . . . . . . . . . . . . . G.1.1 Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G.1.2 Separao de preocupaes . . . . . . . . . . . . . . . . . . . . . .
CONTEDO G.1.3 Padres e estilos arquiteturais . . . . . . . . . . . . . . . . . . . . G.2 Tticas de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G.2.1 Desempenho e escalabilidade . . . . . . . . . . . . . . . . . . . . G.2.2 Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G.2.3 Tolerncia a Faltas . . . . . . . . . . . . . . . . . . . . . . . . . . G.2.4 Compreensibilidade e Modicabilidade . . . . . . . . . . . . . . . G.2.5 Operabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H Documentao da Arquitetura H.1 Arquitetura e Documento da Arquitetura . . . . . . . . . . . . . . . . . . . H.1.1 Auxlio ao Processo de Design . . . . . . . . . . . . . . . . . . . . H.1.2 Ferramenta de Comunicao . . . . . . . . . . . . . . . . . . . . . H.1.3 Integridade Conceitual . . . . . . . . . . . . . . . . . . . . . . . . H.1.4 Modelo para Anlise . . . . . . . . . . . . . . . . . . . . . . . . . H.1.5 Ferramenta de Rastreabilidade . . . . . . . . . . . . . . . . . . . . H.2 Decises Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . H.2.1 Decises existenciais . . . . . . . . . . . . . . . . . . . . . . . . . H.2.2 Decises descritivas . . . . . . . . . . . . . . . . . . . . . . . . . H.2.3 Decises executivas . . . . . . . . . . . . . . . . . . . . . . . . . H.2.4 Atributos das decises arquiteturais . . . . . . . . . . . . . . . . . H.3 Vises arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H.3.1 4+1 de Kruchten . . . . . . . . . . . . . . . . . . . . . . . . . . . H.3.2 Viewpoints de Rozanski e Woods . . . . . . . . . . . . . . . . . . . H.3.3 Viewtypes do Software Engineering Institute (SEI) . . . . . . . . . H.4 Documentando a Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . H.4.1 Diculdades da Documentao . . . . . . . . . . . . . . . . . . . . Exerccios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii 160 163 164 168 170 171 172 175 177 178 178 181 182 185 187 188 189 190 192 193 199 200 201 202 203 203 208
Lista de Figuras
B.1 Ilustrao do processo de design . . . . . . . . . . . . . . . . . . . . . . . B.2 Representao estrutural do programa de ordenao . . . . . . . . . . . . . B.3 Pseudocdigo do Merge sort . . . . . . . . . . . . . . . . . . . . . . . . . C.1 Principais funcionalidades do SASF . . . . . . . . . . . . . . . . . . . . . C.2 Diagrama de Casos de Uso simplicado do SASF . . . . . . . . . . . . . . D.1 Alguns elementos de processamento, de dados e de conexo do SASF . . . D.2 Mdulos funcionais do SASF . . . . . . . . . . . . . . . . . . . . . . . . . D.3 Processos presentes no SASF . . . . . . . . . . . . . . . . . . . . . . . . . D.4 Ilustrao da diviso de uma arquitetura em trs camadas. . . . . . . . . . . D.5 Uma viso esttica da arquitetura do SASF . . . . . . . . . . . . . . . . . D.6 Uma viso dinmica da arquitetura do SASF . . . . . . . . . . . . . . . . . E.1 Stakeholders de um mesmo grupo, mas divergindo nos requisitos. . . . . . F.1 F.2 Escalando verticalmente um sistema. . . . . . . . . . . . . . . . . . . . . . Escalando horizontalmente um sistema. . . . . . . . . . . . . . . . . . . . 51 57 58 71 74 84 87 88 92 106 107 117 147 148 180
H.1 Mdulos funcionais do SASF . . . . . . . . . . . . . . . . . . . . . . . . .
ix
Lista de Tabelas
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 Avaliao de Beyond Software Architecture . . . . . . . . . . . . . . . . . Avaliao de Essential Software Architecture . . . . . . . . . . . . . . . . Avaliao de Documenting Software Architectures: Views and Beyond . . . Avaliao de The Art of Systems Architecting, segunda edio . . . . . . . . Avaliao de Evaluating Software Architectures: Methods and Case Studies Avaliao de Pattern-Oriented Software Architecture, Volume 1 . . . . . . . Avaliao de Software Architecture in Practice, segunda edio . . . . . . . Avaliao de Software Systems Architecture . . . . . . . . . . . . . . . . . Avaliao de Software Architecture . . . . . . . . . . . . . . . . . . . . . . Resumo da metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16 17 17 18 18 19 19 20 21 76
C.1 Tamanhos e amostragens disponveis . . . . . . . . . . . . . . . . . . . . .
Captulo 1 Introduo
Apesar das primeiras referncias sobre Arquitetura de Software (AS) e seus benefcios datarem das dcadas de 1960 e 1970 [30; 22; 78], sua nfase como disciplina s surgiu tempos depois, durante a dcada de 90 [80; 96; 39]. Por ter se destacado como um ramo da Engenharia de Software apenas recentemente, no h ao menos uma denio de facto do termo Arquitetura de Software. No entanto, a ttulo de introduo, vale destacar a denio de jure do termo [45]: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Ao compar-la com as denies consideradas clssicas de Perry & Wolf [80]: Software Architecture = { Elements, Form, Rationale } de Bass, Clements & Kazman [7]: The software architecture of a program or computing systems is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. e de Garlan & Shaw [39]:
2 As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. This is the software architecture level of design. percebe-se que so compatveis, pois podem ser resumidas a elementos, suas relaes, e o resultado dessas relaes, mas no so pragmticas. Assim, apesar das diversas semelhanas entre as denies acima, no claramente percebida a real utilidade da arquitetura, principalmente por aqueles que no possuem grande experincia em desenvolvimento de sistemas de grande e mdio porte - justamente onde aora sua utilidade. Em poucas palavras, a arquitetura a pea-chave para se obter o controle intelectual sobre a complexidade de um sistema [55]. Esse controle provido pela abstrao do sistema em questo que ela prov. No entanto, sua utilidade transcende a abstrao do sistema. Por ser o conjunto das principais decises que regero o desenvolvimento do sistema [102] , a arquitetura tambm pea fundamental em sua evoluo, ditando assim o que pode e o que no pode ser feito durante todo o ciclo de vida do software. Alm disso, essas decises acabam sendo rastreveis, permitindo assim a avaliao de uma implementao do sistema a partir de sua arquitetura, ou ainda a avaliao da arquitetura a partir de uma implementao do sistema. Por m, a arquitetura tambm serve de facilitadora da comunicao entre vrios stakeholders do sistema, pois ela, naturalmente, possui diversas vises para suas diversas preocupaes [56]. Por exemplo, a adio de um requisito funcional ao sistema pode signicar: A adio de um novo mdulo e suas conexes na viso estrutural da arquitetura, que condiz com preocupaes de desenvolvedores; ou A alocao de um novo time e suas implicaes, na viso organizacional da arquitetura, que condiz com preocupaes do gerente de projeto.
1.1 Evidncias da necessidade de estudar arquitetura de software
E isto a faz til como abstrao comum em negociaes, busca de consenso ou comunicao em geral [7].
1.1 Evidncias da necessidade de estudar arquitetura de software

Mesmo com a grande nfase das metodologias geis de desenvolvimento de software, que clamam bons resultados sem investir na arquitetura do sistema (ou mesmo ignorando-a), cada vez mais grupos investem em seu estudo e atestam sua necessidade em sistemas cada vez maiores. Para se ter uma ideia, o Guide to the Software Engineering Body of Knowledge (SWEBOK) dedica toda uma seo sobre arquitetura de software no captulo sobre design [1]. Do mesmo jeito, o Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering [62], editado em conjunto pela IEEE Computer Society e pela ACM, cita sua necessidade e sugere o estudo de arquitetura de software em cursos de graduao em Engenharia de Software. Alm disso, os guias para programas de graduao em Cincia da Computao [99], Engenharia da Computao [100] e Tecnologia da Informao [101] dos mesmos editores tambm sugerem o estudo de arquitetura de software para a formao de alunos nessas reas. Obviamente, estes dedicam uma menor carga para o assunto do que o guia para Engenharia de Software. Finalmente, uma recomendao para prtica de descries arquiteturais foi publicada como um padro ISO/IEC [45]. O foco dessa recomendao consiste na criao, anlise e manuteno de arquiteturas, alm de prover um arcabouo conceitual de denies ligadas rea. A reao natural a essa movimentao em torno de Arquitetura de Software foi a criao de diversos cursos, tanto acadmicos quanto prossionais, para formar a massa de praticantes de Engenharia de Software [13; 93; 73; 96; 61; 74; 50; 40; 66; 104]. No entanto, observando os cursos em questo, possvel citar alguns problemas que podem levar a uma formao incompleta na disciplina de Arquitetura de Software. So eles:
1.1 Evidncias da necessidade de estudar arquitetura de software Apenas padres arquiteturais
Alguns cursos apenas enfatizam a faceta estrutural da disciplina de Arquitetura de Software. Assim, seu ensino acaba se resumindo ao ensino de padres arquiteturais, que bastante til, mas insuciente como pode ser observado tanto nas denies de arquitetura de software, quanto nas sugestes de currculo da IEEE Computer Society e ACM. Carncia de livro-texto Outros cursos, mesmo englobando maior parte do sugerido para uma disciplina de Arquitetura de Software, tm sua base formada no por um livro-texto, mas pela leitura de artigos essenciais sobre o contedo. Essa abordagem de leitura de artigos possui uma grande vantagem que obter o contedo pela viso de seu autor. No entanto, diferenas de discurso, de terminologia, e de notaes de artigo para artigo podem dicultar o processo de aprendizado. Alm disso, os artigos no necessariamente colocam numa perspectiva arquitetural o problema e a soluo nos quais se fundamentam [96], o que prejudica ainda mais se os estudantes no possurem maturidade o suciente para uma abordagem desse tipo, bem mais comum em cursos de ps-graduao, mas pouco utilizada em cursos de graduao. Sobre a relao mestre-aprendiz H ainda uma abordagem observada em algumas propostas de ensino de Arquitetura de Software que enfatiza ao mximo a relao mestre-aprendiz para a realizao do ensino. Nessa relao, alm das aulas tericas de menor carga, o estudante ter o papel de aprendiz e seguir os passos de um prossional da rea, seu mestre. Assim, o mestre guiar os passos do estudante, mostrando na prtica o que este deve aprender. Inicialmente, a responsabilidade do aprendiz se resume a apenas observar seu mestre, observando a teoria em prtica. Mas, ao longo do tempo, sua responsabilidade aumenta enquanto seu mestre vai cedendo espao para ele. Essa abordagem, apesar de ser bastante promissora, tem duas desvantagens que podem inviabiliz-la. A primeira no se adequar ao modelo de disciplina com poucos encontros rpidos, i.e., aulas, com um nico professor, sendo ento difcil de aplicar num ambiente acadmico. J a segunda desvantagem seu alto custo, que faz com que se restrinja a poucos
1.1 Evidncias da necessidade de estudar arquitetura de software grupos, como a NASA [104].
1.1.1 Consideraes sobre livros da rea

No a falta de livros na rea que faz com que o ensino de Arquitetura de Software, normalmente, no adote livros-texto. Muito menos isso ocorre pela qualidade dos livros existentes. Apesar de ser difcil atestar objetivamente a qualidade de um livro, os responsveis por eles guram entre as peas-chave na pesquisa cientca em arquitetura: Mary Shaw e David Garlan [89], Ian Gorton [41] e o Software Engineering Institute, da Carnegie Mellon [7; 24; 25], s para citar alguns nomes. O que faz com que eles no sejam adotados como livro-texto so suas abordagens. Essas abordagens, normalmente, se encaixam em uma das seguintes: O livro se foca apenas na teoria. Exemplos so fundamentais para a xao do conhecimento. Alm disso, numa disciplina de design (em qualquer nvel), necessrio um ponto de partida para o estudo (ou para a realizao de uma tarefa), que normalmente se d por meio de exemplos representativos. O livro tem como pblico-alvo apenas praticantes de Engenharia de Software. Na academia, so pouqussimos os alunos realmente j praticantes. Portanto, um livro com esse pblico-alvo no trar exemplos e estudos de caso signicativos para outros leitores, como alunos de graduao em Cincia da Computao ou mesmo Engenharia de Software. Essa abordagem possui ainda, basicamente, dois tipos de discurso, que so diretamente relacionados experincia dos autores. No primeiro tipo, os livros so permeados de exemplos de sistemas militares, que no so naturais grande maioria dos praticantes de Engenharia de Software [7; 24; 25; 66]. J no segundo tipo, os exemplos so voltados aos j praticantes de Engenharia de Software e/ou Tecnologia da Informao, os quais, fatalmente, ainda no so naturais a alunos da academia [41]. Percebe-se ento uma lacuna na rea: faltam livros-texto que auxiliem o estudo de Arquitetura de Software e que se adquem a programas de graduao tanto em Cincia da Computao quanto em Engenharia de Software [96; 50; 17]. Ao avaliar os livros disponveis sobre o assunto, foi encontrado apenas um livro que pode servir para este propsito. Vale observar
1.2 Objetivo do Trabalho
que esse livro foi publicado apenas depois do problema da carncia de livros-texto ter sido identicado, servindo ento como mais uma evidncia de que o problema identicado real.
1.2 Objetivo do Trabalho

O objetivo deste trabalho preencher a lacuna citada anteriormente com a escrita de um livro-texto que se adque a um curso acadmico em Arquitetura de Software. Este livro tem como foco o aluno de graduao tanto em Cincia da Computao quanto em Engenharia de Software. No entanto, ele tambm poder ser til para os j praticantes da rea que busquem uma base terica para solidicar seu conhecimento. O contedo deste livro est de acordo com os currculos propostos pela IEEE Computer Society e ACM [62; 99], de modo que no apenas expe a teoria necessria, mas que tambm possui exerccios para avaliar o aprendizado do estudante. Alm disso, o conhecimento exposto construdo a partir de exemplos reais e signicativos para seus leitores a m de proporcionar um aprendizado slido.
1.3 Relevncia do Trabalho

Em poucas palavras, a arquitetura de um sistema: contm decises antecipadas, tanto de design, quanto de business, que inuenciaro em todo seu ciclo de vida [7]; e facilita a integridade conceitual e a comunicao entre stakeholders atravs de suas abstraes e mltiplas vises, que so o ponto-chave para seu desenvolvimento e evoluo [54; 14]. Assim, so expostos o valor e a inuncia da arquitetura [45]. Por outro lado, seu ensino tambm importante, anal a maneira de se formar prossionais que usaro os conhecimentos de AS nos sistemas em que trabalham. No entanto, percebe-se que o ensino de Arquitetura de Software para os ainda no-praticantes (e.g., alunos de graduao em Cincia da Computao ou Engenharia de Software) defasado, pois no h um livro-texto que seja
1.3 Relevncia do Trabalho
escrito para esse pblico-alvo. Tipicamente, este pblico-alvo acaba adotando livros voltados para os praticantes da rea, fato que acaba provendo uma experincia pedaggica com discurso, exemplos e estudos de caso que no lhe so naturais e/ou representativos [50; 105; 96]. Assim, pretende-se satisfazer essa carncia de um livro-texto para no-praticantes. A ideia do livro que facilite a confeco de cursos em Arquitetura de Software, provendo justamente contedo, discurso, exerccios, exemplos e estudos de caso que enriqueam o processo de ensino. Esse enriquecimento do ensino na disciplina, por m, fortalecer a base terica dos praticantes da rea, que impactar diretamente na qualidade do software produzido por eles, dado o j citado valor e inuncia da arquitetura no ciclo de vida dos sistemas. O restante da dissertao est organizado da seguinte forma. O prximo captulo descreve os requisitos de um livro-texto que sirva para uma disciplina de graduao sobre Arquitetura de Software. O Captulo 3 mostra uma avaliao criteriosa dos livros atuais em relao ao requisitos descritos no captulo anterior. No Captulo 4, apresentada a metodologia seguida para a escrita do livro. As concluses e trabalhos futuros so apresentados no Captulo 5. Por m, o livro apresentado nos apndices de A a H.
Captulo 2 Requisitos para um Livro-Texto

Pode-se identicar os seguintes requisitos para um livro-texto que sirva de suporte a uma disciplina de Projeto em Arquitetura de Software: Ter um discurso que se adque ao pblico-alvo; Possuir exemplos signicativos ao pblico-alvo; Possuir exerccios; Cobrir o contedo suciente. Esses requisitos sero mais bem detalhados a seguir.
2.1 Discurso
Como j observado em [50; 96], livros no endereados a alunos sem experincia em Engenharia de Software no apresentam um discurso adequado para estes, de maneira que seu processo de aprendizado prejudicado. Do mesmo jeito, uma simples coleo de artigos sobre o contedo no suciente. Artigos de diferentes autores, fatalmente, apresentam notaes e terminologias variadas e que podem atrapalhar a transmisso de conhecimento. Alm disso, vrios artigos podem no enfatizar o chamado aspecto arquitetural de seu contedo, dicultando ainda mais o aprendizado.
2.2 Exemplos
Como o pblico-alvo no possui grande experincia em Engenharia de Software, uma vez que ainda no so praticantes, necessrio considerar essa pouca experincia e melhorla. Uma forma de fazer isso permear o discurso com exemplos reais.
2.2 Exemplos
O uso de exemplos uma forma de instanciar a teoria e sedimentar o aprendizado. Por isso eles so essenciais num livro-texto para qualquer disciplina. No entanto, em Arquitetura de Software, eles tm ainda outra utilidade: como AS uma disciplina de design, bons exemplos tambm serviro de ponto de partida para a prpria atividade de design. Basicamente, o livro deve ter dois tipos de exemplos: Exemplos simples: serviro para realar algum ponto especco do contedo. Devem ter pequena complexidade, mas devem minimamente reetir a realidade; Estudos de caso: serviro para realar como os diversos aspectos do contedo se relacionam. Sua complexidade deve ser bem maior, mas deve condizer com a realidade do pblico-alvo (e.g., no descrever um sistema militar de tempo real para alunos que ainda no tm a vaga noo do que seja isso).
2.3 Exerccios
Assim como exemplos, exerccios tambm servem para pr em prtica o aprendido, s que de forma ativa por parte do estudante. Dessa maneira, exerccios acabam servindo para avaliao do progresso do aprendizado, alm de realar aspectos importantes do contedo. Os exerccios podem ainda ser divididos de uma maneira anloga aos exemplos: Exerccios simples: exercitam aspectos especcos do contedo. Eles devem ter diversos nveis de diculdade, de modo que motivem e avaliem gradualmente o progresso. Projetos: exercitam diversos aspectos do contedo e suas relaes. Fatalmente, o tempo necessrio para complet-los deve ser maior.
2.4 Contedo
10
2.4 Contedo
Por j haver recomendaes de contedo por parte da IEEE Computer Society e ACM para o ensino de Arquitetura de Software [62], o contedo de um livro-texto com o objetivo de dar apoio a esse ensino deve cobrir, pelo menos, essas recomendaes para ser amplamente adotado. As recomendaes sugerem os seguintes tpicos: 1. Estilos arquiteturais e suas caractersticas (e.g., pipes-and-lters, camadas, clienteservidor, peer-to-peer, etc.), que auxiliam em tcnicas para suprir requisitos nofuncionais. 2. Trade-offs arquiteturais entre atributos de qualidade, englobando mtodos de avaliao de solues. Vale notar que h dois momentos para a avaliao: Avaliao de alternativas para se construir uma arquitetura que supra os requisitos buscados. Avaliao de uma arquitetura j existente, que est mais ligada ao tpico de rastreabilidade. 3. Arquitetura de sistemas, onde h tambm consideraes do software se comunicando com outros produtos de software, consideraes de hardware, e interaes com o usurio. 4. Rastreabilidade de requisitos na arquitetura, que est relacionada tanto em como as decises arquiteturais afetaro a implementao, quanto em como a implementao pode afetar a arquitetura. 5. Arquiteturas especcas de domnio e linhas de produto, tpico onde a arquitetura visa permitir o mximo reuso. 6. Notaes arquiteturais, tpico que se preocupa em como documentar uma arquitetura, tornando-a um artefato no processo de desenvolvimento do software. As mltiplas vises e representaes de uma arquitetura para os diversos stakeholders so enfatizadas.
2.5 Objetivos pedaggicos
11
No entanto, pode-se ainda sugerir a cobertura de alguns outros tpicos que se mostram importantes: Conceitos bsicos de design e arquitetura. Como se espera que o pblico-alvo no tenha grande experincia prvia no contedo do livro-texto, isso pode se reetir na qualidade de seu vocabulrio sobre o contedo. Assim, necessrio criar um arcabouo conceitual mnimo sobre design e arquitetura que sirva para a construo desse vocabulrio e, consequentemente, do conhecimento. Termos fundamentais como stakeholders, vises, alternativas, atributos, etc., devem ser denidos e exemplicados. tambm requisito que essas denies estejam de acordo com as prticas vigentes [45]. Denio de arquitetura e exposio de seu propsito. Mesmo no sendo um tpico recomendado pelo Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering [62], parece bvia a necessidade de denir o objeto de estudo, alm de motivar ser estudo. Tcnicas de projeto de arquitetura. Apesar de se referirem a caractersticas, vises e/ou componentes de uma arquitetura, nenhum dos tpicos anteriores se refere a como projetar uma arquitetura. Portanto, esse seria o objetivo desse tpico. Por m, alm da devida cobertura em cada tpico citado, o livro deve servir de fonte de referncias para quem quiser se aprofundar sobre o assunto.

O livro, satisfazendo aos requisitos citados anteriormente, deve proporcionar ao leitor, ao m de sua leitura, a capacidade de: Entender os principais conceitos relacionados arquitetura de software. Descrever uma arquitetura, sabendo desenvolver diferentes vises de uma arquitetura, endereando as preocupaes especcas de cada stakeholder.
12
Gerar e escolher alternativas arquiteturais sucientes para resolver um problema e entender que uma arquitetura nunca est certa ou errada - no mximo se encaixa melhor a uma determinada situao. Explicar o que so padres arquiteturais e reconhecer os principais padres arquiteturais existentes em sistemas de software. Avaliar uma arquitetura. Dando assim oportunidade de apreciar/avaliar o conjunto de decises arquiteturais e seus trade-offs, alm de suas propriedades.
Captulo 3 Avaliao criteriosa de livros sobre Arquitetura de Software

So diversos os livros que focam total ou parcialmente Arquitetura de Software (AS). Alguns deles so at adotados como livro-texto em cursos que visam ensinar essa disciplina ao redor do mundo. No entanto, mesmo com essa quantidade de livros, observa-se que h apenas um que satisfaa plenamente os requisitos para ser um livro-texto que se adque a um curso sobre Projeto de Arquitetura de Software em nvel de graduao. Neste captulo, exposta a avaliao de dois livros usados constantemente em cursos sobre AS [50; 105; 61; 74]: Software Architecture in Practice, segunda edio [7]; The Art of Systems Architecting, segunda edio [66]. Alm destes, outros livros so tambm avaliados por sua grande adoo entre prossionais: Documenting Software Architectures: Views and Beyond [24], Evaluating Software Architectures: Methods and Case Studies [25], Essential Software Architecture [41], PatternOriented Software Architecture, Volume 1: A System of Patterns [21], Beyond Software Architecture: Creating and Sustaining Winning Solutions [44], Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [85] e Software Architecture: Foundations, Theory, and Practice [97]. Os critrios de avaliao so apresentados na Seo 3.1, a avaliao dos livros feita na Seo 3.2, e so expostas algumas concluses na Seo 3.3. 13
3.1 Critrios de Avaliao
14
3.1 Critrios de Avaliao

Foi observado que para que um livro sirva como livro-texto num curso de Arquitetura de Software em nvel de graduao, ele precisa suprir alguns requisitos. O objetivo desta seo mapear estes requisitos a critrios de avaliao que sero aplicados a livros que j so adotados como livro-texto atualmente. Os requisitos para um livro-texto so (para mais informaes sobre os requisitos, vide Seo 2): Ter um discurso que se adque ao pblico-alvo; Possuir exemplos signicativos ao pblico-alvo; Possuir exerccios; Cobrir o contedo suciente. A avaliao consistir numa tabela para cada livro. Cada tabela conter quatro linhas: uma para cada requisito, que sero representados respectivamente por discurso, exemplos, exerccios, e contedo; e duas colunas: a primeira, adequao, apresentar a adequao do livro avaliado para cada requisito, usando os valores nula, parcial, ou completa, e a segunda coluna, observaes, representar um espao para observaes do porqu da adequao avaliada. Considerando o critrio Discurso, ser completa sua adequao se o livro for endereado a estudantes de graduao, parcial se endereado a praticantes de Engenharia de Software na rea de TI, e nula se endereado a praticantes de Engenharia de Software com experincia em sistemas mais complexos (e.g., de tempo-real ou militares). Um livro ser completo em relao ao critrio Exemplos se possuir estudos de caso e uma quantidade considervel de exemplos mais simples para instanciar aspectos da teoria, parcial se possuir apenas uma das categorias de exemplos, e nulo se no possuir qualquer exemplo real. A avaliao do critrio Exerccios se dar da seguinte forma: adequao completa se possuir listas de exerccios ao nal de cada captulo, parcial se apenas possuir alguns questionamentos (mas que no se classiquem estritamente como exerccios) para avaliar o processo de aprendizado, e nula se o livro no possuir qualquer forma de exerccios.
3.2 Avaliao dos livros
15
Por m, em relao ao critrio Contedo, um livro ser completo se abordar todos os tpicos recomendados como requisitos (vide Seo 2.4), e parcial se lhe faltar alguns tpicos. Como todos os livros avaliados so sobre Arquitetura de Software, nenhum livro ser nulo neste critrio.
3.2 Avaliao dos livros

Considerando os critrios de avaliao citados na Seo 3.1, a avaliao dos livros pode ser encontrada nas tabelas de 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8 a 3.9.
3.3 Concluses
Vale notar que, por estarem indisponveis, dois livros considerados importantes por sua relevncia, tanto em quantidade de citaes, quanto em adoo, no foram avaliados. So eles: Applied Software Architecture [43] e Software Architecture: Perspectives on an Emerging Discipline [89]. Ainda sim, por estudos citados anteriormente, reforados pela presente avaliao, podese armar que a rea de Arquitetura de Software, mesmo que prolca em publicaes, carece de livros que sirvam como texto de apoio a um curso em nvel de graduao. Isto pode ser observado tanto pela presena de apenas um livro que satisfaa aos requisitos de um livrotexto, quanto pelo fato do nico livro ter sido publicado apenas recentemente, o que tambm o torna uma evidncia da demanda por livros-texto sobre Arquitetura de Software. Esta insucincia pode resultar num processo de aprendizado defasado, que acabar formando um prossional que necessitar de mais tempo para adquirir o conhecimento necessrio para uma prtica plena da Engenharia de Software. Conhecimento este que poderia ter sido obtido durante sua graduao e no postergado, quando o custo de obteno, fatalmente, ser maior.
3.3 Concluses
16
Adequao Discurso parcial
Observaes Considera leitores que j so praticantes de Engenharia de Software.
Exemplos
parcial
Possui exemplos de diferentes nveis de complexidade, mas no apresenta nenhum estudo de caso.
Exerccios
parcial
Assim como os livros do SEI, possui apenas questes para se discutir na empresa em que o leitor trabalha.
Contedo
parcial
Especicamente, o livro foca em aspectos que afetam uma AS. Fatalmente, ele no cobre padres, avaliao, arquitetura de sistemas, conceitos de design, nem metodologias para desenvolver uma arquitetura.
Tabela 3.1: Avaliao de Beyond Software Architecture: Creating and Sustaining Winning Solutions [44]
Adequao Discurso Exemplos parcial completa
Observaes Focado em prossionais de TI - j praticantes. Tem um estudo de caso que atravessa todo o livro, instanciando os diversos tpicos cobertos. Diversos exemplos ao longo do texto.
Exerccios Contedo
nula parcial
No possui qualquer exerccio. No cobre padres, cobre supercialmente avaliao de arquiteturas, e no introduz conceitos de design.
Tabela 3.2: Avaliao de Essential Software Architecture [41]
3.3 Concluses
17
Observaes dirigido a praticantes e assume conhecimento prvio em AS.
Exemplos
parcial
Exemplos e casos de estudo esto presentes. No entanto, pela experincia dos autores, so normalmente ligados a sistemas bastante complexos (e.g., militares e aviao).
Exerccios
parcial
Apenas questes para discusso, para relacionar algum aspecto do texto empresa em que o leitor, supostamente, trabalha.
Contedo
parcial
Seu foco a documentao. Falta abordar tpicos de avaliao, arquiteturas de sistemas, linhas de produtos, e conceitos bsicos de design e arquitetura.
Tabela 3.3: Avaliao de Documenting Software Architectures: Views and Beyond [24]
Observaes Espera-se que os leitores sejam estudantes de psgraduao ou prossionais. Pela experincia dos autores, os exemplos, em sua grande maioria, so de sistemas de aviao e/ou militares.
Exemplos Exerccios Contedo
parcial completa parcial
H exemplos, mas carece em estudos de caso. H listas de exerccios ao nal da maioria dos captulos. O livro tem seu foco em Arquitetura de Sistemas mas, por ser bastante abstrato, muitos conceitos acabam tambm se aplicando Arquitetura de Software. Falta cobertura em padres, em avaliao, em rastreabilidade, em linhas de produto e em como desenvolver, especicamente, uma arquitetura de software.
Tabela 3.4: Avaliao de The Art of Systems Architecting, segunda edio [66]
3.3 Concluses
18
Adequao Discurso nula
Observaes Assume que o leitor j praticante da rea, alm de adotar o ponto-de-vista do avaliador da arquitetura. A experincia dos autores com sistemas militares inuencia na complexidade de seu discurso.
Exemplos
completa
Possui 4 estudos de caso, alm de diversos exemplos ao longo do texto. Tipicamente, so de cunho militar.
Exerccios
parcial
Contedo
parcial
O foco avaliao de arquiteturas e, portanto, carece nos tpicos: padres, linhas de produtos, documentao, conceitos bsicos, metodologia para desenvolver uma AS.
Tabela 3.5: Avaliao de Evaluating Software Architectures: Methods and Case Studies [25]
Adequao Discurso completa
Observaes Considera o leitor um iniciante no assunto (apesar de tambm servir de referncia para prossionais). Essa considerao se reete em seus exemplos.
parcial nula parcial
Apesar de possuir exemplos, carece em estudos de caso. No possui qualquer exerccio. Por focar apenas em padres, carece nos seguintes tpicos: avaliao, arquitetura de sistemas, rastreabilidade, linhas de produto, documentao, conceitos bsicos de design e metodologia para desenvolver uma arquitetura.
Tabela 3.6: Avaliao de Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [21]
3.3 Concluses
19
Adequao Discurso nula
Observaes Tem o foco em prossionais de grandes sistemas, ou ainda seus gerentes. Pelo background militar dos autores, seu discurso se torna ainda mais denso.
Exemplos
completa
So 9 casos de estudo (alguns so sistemas militares e de controle areo), e o texto permeado de exemplos, alm de sidebars com pontos-de-vista de fora do texto.
Exerccios
parcial
Contedo
parcial
Conceitos bsicos de design e padres arquiteturais no so cobertos.
Tabela 3.7: Avaliao de Software Architecture in Practice, segunda edio [7]
Adequao Discurso Exemplos parcial parcial
Observaes Tem o foco em arquitetos j praticantes. O texto permeado de muitos exemplos, mas carece de estudos de caso.
Exerccios
parcial
Contedo
completa
Possui ampla cobertura de conceitos sobre Arquitetura de Software.
Tabela 3.8: Avaliao de Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [85]
3.3 Concluses
20
Adequao Discurso completa
Observaes Tem o foco em leitores tanto experientes quanto inexperientes.
completa completa completa
O texto permeado de muitos exemplos e estudos de caso. O livro possui exerccios ao nal de cada captulo. Possui ampla cobertura de conceitos sobre Arquitetura de Software.
Tabela 3.9: Avaliao de Software Architecture: Foundations, Theory, and Practice [97]
Captulo 4 Metodologia
Alguns passos foram seguidos para se alcanar os objetivos propostos. Esses passos sero apresentados a seguir, respeitando a ordem em que foram executados. Um resumo desses passos pode ser encontrado na Tabela 4.1. Atividade Descrio 1 2 3 4 5 6 6.1 6.2 6.3 6.4 7 8 Encontrar os requisitos para o livro Encontrar as mensagens para o livro Organizar as mensagens Escolher a abordagem do texto Construir a estrutura de acordo com as mensagens Evoluir o texto a partir da estrutura Denir estudos de caso Denir exemplos Denir exerccios Encontrar revisores Avaliar o contedo atravs de cursos Renar o texto Tabela 4.1: Resumo da metodologia
21
4.1 Encontrar os requisitos para um livro-texto
22
4.1 Encontrar os requisitos para um livro-texto

O primeiro passo para a escrita de um livro foi a denio dos requisitos que se pretendem suprir com ele. Esta denio foi realizada com a denio do pblico-alvo do livro e baseada na leitura de artigos sobre ensino de Arquitetura de Software e recomendaes de currculo para cursos em Engenharia de Software e Cincia da Computao, alm da leitura de livros que se propem a ensinar Arquitetura de Software. Um ponto importante neste passo foi a denio do contedo que ser transmitido no livro. O contedo levou em considerao as necessidades do pblico-alvo, assim como as recomendaes de currculo feitas por organizaes inuentes na rea.
4.2 Encontrar as mensagens para o livro-texto

Denido o contedo, o prximo passo foi a denio das mensagens que formaram o corpo do texto do livro e que, consequentemente, so transmitidas ao leitor. a transmisso dessas mensagens que possibilita o alcance dos objetivos pedaggicos visados pelo livro. As mensagens foram identicadas atravs da reviso bibliogrca realizada sobre o contedo proposto.
4.3 Organizar as mensagens

A apresentao das mensagens, identicadas no passo anterior, deve seguir uma ordem que facilite seu entendimento e respeite eventuais dependncias (certas mensagens so mais bem entendidas se transmitidas aps outras). Portanto, foi neste passo que foi realizada sua organizao de acordo com suas dependncias.
4.4 Escolher a abordagem do texto

Considerando a ordem das mensagens, surge a necessidade de denir uma abordagem para realizar sua apresentao. Como foi identicado que a presena de exemplos um requisito essencial para um livro-texto, restou apenas denir se a abordagem seria permear a apresentao de cada mensagem com diversos exemplos pequenos ou enfatizar estudos de caso. No
4.5 Construir a estrutura de acordo com as mensagens
23
livro, adotamos um misto das abordagens. Ao longo do texto apresentamos um estudo de caso e diversos exemplos menores, que enfatizam diferentes aspectos que no so inicialmente cobertos pelo estudo de caso.
4.5 Construir a estrutura de acordo com as mensagens

Aps a denio da abordagem, foi possvel montar a estrutura de captulos. Essa estrutura consiste nos captulos (seu ttulo e seu objetivo), que mensagens compem cada captulo e qual sua ordem de apario. A estrutura do texto descrita no Apndice A.
4.6 Evoluir o texto a partir da estrutura

Com a estrutura do texto montada, sua escrita foi a consequncia natural. Vale notar que a escrita de cada captulo no precisou ser na ordem na qual eles sero apresentados no livro-texto. A evoluo da estrutura para texto tambm englobou fases de denio de exemplos e do estudo de caso, e elaborao de exerccios. O resultado dessas fases serviram de apoio justamente para a introduo e apresentao de cada mensagem transmitida pelo livro. Por m, considerando a existncia de texto passvel de reviso, procurou-se revisores em mbito nacional que, alm de ajudarem a melhorar a qualidade do texto, fatalmente serviro de endosso para a publicao. Vale notar que essa atividade no foi s a procura de revisores, mas o envio de partes do texto e a considerao ou no de suas sugestes. O resultado desta fase descrito nos captulos de B a H.
4.7 Avaliar o contedo atravs de cursos voltados para graduao e ps-graduao

A fase de avaliao do trabalho no ocorreu aps o trmino do livro, mas em paralelo escrita, ao passo que existia material para ser usado como apoio em disciplinas. Verses preliminares do livro foram usadas num curso sobre Arquitetura de Software, que foi montado
4.8 Renar o texto
24
e oferecido como disciplina opcional para a graduao em Cincia da Computao da Universidade Federal de Campina Grande no perodo 2008.2 e a duas turmas de ps-graduao da mesma universidade. Podemos encontrar as pginas relacionadas aos cursos ministrados nos endereos: http://bit.ly/oTrpk e http://bit.ly/KQoVf.
4.8 Renar o texto

Esse passo consistiu na nalizao da primeira verso do livro-texto, que basicamente foi a aplicao das sugestes feitas pelos revisores, alm das sugestes feitas pelos alunos dos cursos. No entanto, esta verso no a denitiva. Como veremos no captulo em que descreve os trabalhos futuros, o livro estar em constante evoluo, uma vez que est disponvel sob uma licena Creative Commons [26] que permite cpia, distribuio e, o mais importante, adaptao e expanso do contedo por parte de outros autores.
Captulo 5 Concluses e Trabalhos Futuros

Este trabalho um esforo para suprir a carncia de material que sirva de apoio para um curso sobre Projeto de Arquitetura de Software direcionado a alunos de graduao em Engenharia de Software ou Cincia da Computao. O uso de um livro-texto numa disciplina pode proporcionar algumas vantagens [4], que so citadas a seguir: Um livro-texto pode servir de arcabouo para a organizao de um curso, servindo de ementa; Um livro-texto j prov motivao, exemplos e exerccios sobre o assunto, facilitando o trabalho do professor; Um aluno sem dispor de um livro-texto se torna muito dependente das aulas do professor; Por m, professores menos experientes podem se apoiar no livro-texto para terem mais segurana sobre o assunto. O assunto do livro em questo o torna ainda mais relevante, uma vez que a disciplina de Projeto de Arquitetura de Software indispensvel pelos benefcios que proporciona ao processo de desenvolvimento de software. Isso evidenciado pela sua presena tanto no SWEBOK [1], quanto nas diretrizes curriculares para programas de graduao em Engenharia de Software [62]. Na prtica, a arquitetura de software recomendada por proporcionar um modelo do software que serve tanto para a anlise e comunicao entre os stakeholders, quanto para guiar a implementao dos atributos de qualidade. 25
5.1 Consideraes sobre a avaliao
26
No entanto, escrever um livro-texto no uma tarefa trivial e, por isso, foi denida uma metodologia que ajudasse a conduzir este trabalho. A metodologia consistiu em levantar os requisitos de um livro que suprisse a carncia identicada, escrever as mensagens que devem compor o livro para satisfazer esses requisitos e, a partir das mensagens, escrever o livro propriamente dito, sempre tendo por base os requisitos a serem alcanados.
5.1 Consideraes sobre a avaliao

Durante o processo de escrita, vale lembrar que foram ministrados alguns cursos sobre Arquitetura de Software a alunos de graduao e ps-graduao. Estes cursos serviram para avaliar a evoluo do texto. Ao longo dos cursos, tentou-se observar: (1) se os exemplos utilizados em sala de aula (e que esto presentes no livro) eram signicativos aos alunos, (2) se a ordem em que so transmitidas as mensagens no apresentava nenhuma dependncia faltosa, e (3) se existia a evoluo dos alunos ao longo do semestre no sentido do aprendizado da teoria e prtica em Arquitetura de Software. No entanto, mesmo que seja percebida uma grande evoluo por parte dos alunos durante uma disciplina ministrada usando o livro, no se pode garantir que apenas o livro o responsvel pelo sucesso. Anal, o professor desempenha papel fundamental no processo de aprendizado. Por outro lado, a relevncia do livro no pode ser totalmente ignorada. Pode-se ainda avaliar o resultado deste trabalho de acordo com os mesmos critrios que foram utilizados para se chegar concluso de que faltam livros-texto sobre Arquitetura de Software. Considerando (1) a presena de exemplos e estudos de caso, (2) a presena de exerccios, (3) que o livro foi escrito com o objetivo de ser usado por estudantes de graduao e (4) que o livro cobre o assunto mencionado nos requisitos, ele se torna hbil para suprir a demanda de livros-texto sobre Arquitetura de Software. Alm da avaliao criteriosa realizada neste trabalho, deve ser observado que h outra forma de avaliao de livros-texto que pode proporcionar uma melhor ordenao dos livros quanto sua utilidade em sala de aula. No entanto, ela cou fora do escopo deste trabalho porque requer muito tempo para execuo, alm da contribuio de muitos professores da disciplina. Mesmo assim, um esboo de como a avaliao seria realizada descrito a seguir. A avaliao de livros-texto, de acordo com a American Association for Advancement of
5.2 Consideraes sobre os trabalhos futuros
27
Science (AAAS), pode ser realizada atravs de trs passos [60]. O primeiro passo consiste na identicao dos objetivos pedaggicos que um livro-texto deve ter, considerando a disciplina em questo. Como pode ser observado na Seo 2.5, este passo foi realizado neste trabalho, uma vez que os objetivos pedaggicos so essenciais para a escrita de um livrotexto. O segundo passo, consiste em cada professor voluntrio atribuir notas de 0 a 3 para cada objetivo pedaggico implementado por cada livro sobre os seguintes critrios: Se o livro identica o contexto do assunto; Se o livro faz as consideraes corretas sobre o conhecimento prvio do aluno; Se o livro motiva o aluno, por meio de exemplos com os quais ele se identique; Se o livro desenvolve as mensagens presentes no assunto usando um encadeamento lgico signicativo para o aprendizado; Se o livro promove a reexo por parte do aluno; Se o livro prov meios de avaliao do progresso do aluno; Se o livro enriquece o ambiente de aprendizado. Coletando e analisando esses dados, seria possvel inferir uma melhor ordenao quanto adequao dos livros-texto aos alunos de graduao e onde seria inserido este trabalho em meio aos livros existentes. No entanto, dois fatores impediram a viabilidade da aplicao desta tcnica de avaliao. O primeiro fator que, para que os dados sejam signicativos, uma quantidade considervel de professores deveria participar. J o segundo fator consiste em que, alm de serem em quantidade considervel, os professores deveriam ter conhecimento prvio dos livros avaliados ou deveriam dispor de tempo para conhecer todos os livros e assim realizarem a avaliao.

Apesar de ser um livro-texto, a publicao deste trabalho no ser realizada da forma tradicional. Na verdade, para alcanar o maior nmero de leitores, todo o contedo gerado neste
28
trabalho est disponibilizado sob uma licena Creative Commons [26]. A licena permite cpia, distribuio e, o mais importante, adaptao e expanso do contedo por parte de outros autores. O contedo est disponvel por meio do sistema chamado Connexions [84] e pode ser encontrado no endereo http://cnx.org/content/col10722/. Usando este sistema, alm de tornar o contedo acessvel a qualquer pessoa interessada, tambm possvel receber feedback dos leitores para eventuais melhorias. Alm disso, possvel convidar e conceder privilgios de escrita a novos autores, de forma a tornar o processo de contribuio menos custoso. Esta disponibilidade se torna uma vantagem, uma vez que se deve observar que ainda h partes do livro que necessitam de ajustes. Portanto, a realizao desses ajustes e a busca por contribuies externas compem os objetivos das prximas atividades em relao ao livro. Entre as partes que necessitam de ajustes, dois captulos devem ser mencionados. O captulo sobre tcnicas de design arquitetural pode ser melhorado se forem adicionados estudos de caso reais sobre o assunto. A adio de novos casos simples, porm trabalhosa: cita-se um ou mais requisitos de qualidade de um sistema real e, em seguida, descreve-se como a arquitetura desse sistema foi projetada de forma a atender esses requisitos. O outro captulo que merece mais contribuies o de documentao arquitetural. Neste captulo so citados trs exemplos de conjuntos de pontos de vista arquiteturais, mas faltam casos de documentao que seguem esses conjuntos. Novamente, a adio de casos reais pode melhorar o captulo, s que dessa vez focando nos documentos dos projetos ao invs de apenas no design. Dado que o contedo dos captulos est disponvel para leitura, adaptao e expanso por terceiros e que o custo das eventuais contribuies relativamente baixo, de se esperar que contribuies externas aconteam visando a melhoria do texto, tanto nos captulos indicados, quanto com captulos adicionais. Inclusive, j existem alguns estudantes, professores e prossionais experientes em Engenharia de Software que se mostraram dispostos a contribuir e que j esto trabalhando em suas propostas para melhoria do texto.
Bibliograa
[1] A. Abran, J. W. Moore, P. Bourque, R. Dupuis, e L. L. Tripp. Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE, 2004. [2] R. Allen e D. Garlan. A Formal Basis for Architectural Connection. ACM Trans. Softw. Eng. Methodol., 6(3):213249, Julho 1997. [3] A. J. A. Wang e K. Qian Component-Oriented Programming. Wiley-Interscience, March 2005. [4] H. Ansary e E. Babaii. Universal Characteristics of EFL/ESL Textbooks: A Step Towards Systematic Textbook Evaluation. The Internet TESL Journal, 8(2), 2002. [5] M. A. Babar e I. Gorton. Architecture Knowledge Management: Challenges, Approaches, and Tools. Em Software Engineering - Companion, 2007. ICSE 2007 Companion. 29th International Conference on, pginas 170171, 2007. [6] L. Bass, P. Clements, e R. Kazman. Software Architecture in Practice. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, Primeira Edio, 1998. [7] L. Bass, P. Clements, e R. Kazman. Software Architecture in Practice. AddisonWesley Professional, Segunda Edio, Abril 2003. [8] L. Belady. Prefcio. Em Software Design: Methods and Techniques (L.J. Peters, author). Yourdon Press, 1981. [9] B. W. Boehm, J. R. Brown, e M. Lipow. Quantitative Evaluation of Software Quality. Em International Conference on Software Engineering, pginas 592605, San Francisco, 1976. IEEE Computer Society Press.
29
BIBLIOGRAFIA [10] G. Booch. Goodness of Fit. Software, IEEE, 23(6):1415, 2006. [11] G. Booch. The Irrelevance of Architecture. Software, IEEE, 24(3):1011, 2007.
30
[12] G. Booch, R. A. Maksimchuk, M. W. Engel, B. J. Young, J. Conallen, e K. A. Houston. Object-Oriented Analysis and Design with Applications. Addison-Wesley Professional, Terceira Edio, Abril 2007. [13] Bredemeyer Consulting. Software Architecture Training and Consulting. Online em: http://www.bredemeyer.com/training.htm, 2009. [14] F. P. Brooks. No Silver Bullet - Essence and Accident in Software Engineering. Em Proceedings of the IFIP Tenth World Computing Conference, pginas 10691076, 1986. [15] F. P. Brooks. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Addison-Wesley Professional, Agosto 1995. [16] J. Brunet, D. Guerrero, e J. Figueiredo. Design Tests: An Approach to Programmatically Check Your Code Against Design Rules. Em Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, pginas 255258, 2009. [17] O. Bubak. Composing a Course Book for System and Enterprise Architecture Education. Em System of Systems Engineering, 2006 IEEE/SMC International Conference on, pginas 6 pp.+, 2006. [18] D. Budgen. Software Design. Addison Wesley, Segunda Edio, Maio 2003. [19] F. Buschmann, K. Henney, e D. C. Schmidt. Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. Wiley, Maio 2007. [20] F. Buschmann, K. Henney, e D. C. Schmidt. Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages. Wiley, Junho 2007. [21] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad e M. Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons, Agosto 1996.
BIBLIOGRAFIA
31
[22] J.N. Buxton e B. Randell. Software Engineering Techniques. Relatrio Tcnico, NATO Science Committee, Roma, Itlia, Abril 1970. [23] P. Clements. A Survey of Architecture Description Languages. Em Software Specication and Design, 1996., Proceedings of the 8th International Workshop on, pginas 1625, 1996. [24] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, e J. Stafford. Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional, Setembro 2002. [25] P. Clements, R. Kazman, e M. Klein. Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley Professional, Janeiro 2002. [26] Creative Commons. Creative Commons Attribution 3.0 Unported.
http://creativecommons.org/licenses/by/3.0/. [27] J. Dean e S. Ghemawat. MapReduce: Simplied Data Processing on Large Clusters. 6th Symposium on Operating Systems Design & Implementation (OSDI 04), 2004. [28] Defense Information Systems Agency. Department of Defense Joint Technical Architecture, Version 6.0. Volume 2. U.S. Department of Defense, Outubro 2003. [29] C. Dibona, M. Stone, e D. Cooper. Open Sources 2.0 : The Continuing Evolution. OReilly Media, Inc., Outubro 2005. [30] E. W. Dijkstra. The Structure of The THE-multiprogramming System. Commun. ACM, 11(5):341346, 1968. [31] J. C. Dueas e Rafael Capilla. The Decision View of Software Architecture. Software Architecture, pginas 222230. Springer Berlin / Heidelberg. June 2005. [32] G. Edwards, S. Malek, e N. Medvidovic. Scenario-Driven Dynamic Analysis of Distributed Architectures. Fundamental Approaches to Software Engineering, pginas 125139. Springer Berlin / Heidelberg 2007.
BIBLIOGRAFIA
32
[33] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, e A. Mockus. Does Code Decay? Assessing The Evidence from Change Management Data. Software Engineering, IEEE Transactions on, 27(1):112, 2001. [34] Facebook Team. Engineering @ Facebook.
http://www.facebook.com/notes.php?id=9445547199. [35] R. T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Tese de PhD, University of California, Irvine, 2000. [36] B. Foote e J. W. Yoder. Big Ball of Mud. Em N. Harrison, B. Foote, e H. Rohnert, editores, Pattern Languages of Program Design, volume 4, pginas 654692. Addison Wesley, 2000. [37] M. Fowler. Design - Who Needs an Architect? Software, IEEE, 20(5):1113, 2003. [38] M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, Novembro 2002. [39] D. Garlan e M. Shaw. An Introduction to Software Architecture. Relatrio Tcnico CMU-CS-94-166, Carnegie Mellon University, Pittsburgh, PA 15213-3890, Janeiro 1994. [40] E. Golden e L. Bass. Creating Meaningful Assessments for Professional Development Education in Software Architecture. Em Software Engineering Education & Training, 2007. CSEET 07. 20th Conference on, pginas 283290, 2007. [41] I. Gorton. Essential Software Architecture. Springer, Junho 2006. [42] T. Hoff. High Scalability: Building bigger, faster, more reliable websites.
http://highscalability.com/. [43] C. Hofmeister, R. Nord, e D. Soni. Applied Software Architecture. Addison-Wesley Professional, Novembro 1999. [44] L. Hohmann. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional, Janeiro 2003.
BIBLIOGRAFIA
33
[45] IEEE e ISO/IEC. Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems. ISO/IEC 42010 IEEE Std 1471-2000 Primeira Edio 2007-07-15, pginas c124, Julho 2007. [46] IEEE Std 754-2008. IEEE Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers, 2008. [47] ISO 9126-1:2001. Software engineering Product quality Part 1: Quality model. International Organization for Standardization, Geneva, Switzerland. [48] A. Jansen e J. Bosch. Software Architecture as A Set of Architectural Design Decisions. Em Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, pginas 109120, Washington, DC, USA, 2005. IEEE Computer Society. [49] D. Kalinsky e J. Ready. Distinctions Between Requirements Specication and Design of Real-Time Systems. Em Software Engineering for Real Time Systems, 1989., Second International Conference on, pginas 2630, 1989. [50] O. Karam, K. Qian, e J. Diaz-Herrera. A Model for SWE Course Software Architecture and Design. Em Frontiers in Education, 2004. FIE 2004. 34th Annual, pginas F2C48 Vol. 2, 2004. [51] F. Katki, L. Mcmonegal, B. Meyer, J. Lane, P. Wilson, J. Radatz, M. Yee, H. Porteous, e F. Springsteel, editores. IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., The, 1991. [52] H. Kopetz. Real-Time Systems: Design Principles for Distributed Embedded Applications. Springer, Abril 1997. [53] G. Kotonya e I. Sommerville. Requirements Engineering: Processes and Techniques. John Wiley & Sons, Setembro 1998. [54] P. Kruchten. The Software Architect and The Software Architecture Team.
Software Architecture; TC2 First Working IFIP Conference on Software Architecture (WICSA1), 2:565583.
BIBLIOGRAFIA
34
[55] P. Kruchten, H. Obbink, e J. Stafford. The Past, Present, and Future for Software Architecture. Software, IEEE, 23(2):2230, 2006. [56] P. Kruchten. The 4+1 View Model of Architecture. Software, IEEE, 12(6):4250, 1995. [57] P. Kruchten, R. Capilla, e Juan C. Dueas. The Decision Views Role in Software Architecture Practice. IEEE Software, 26(2):3642, 2009. [58] P. Kruchten, P. Lago, H. van Vliet, e T. Wolf. Building Up and Exploiting Architectural Knowledge. Em WICSA 05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA05), pginas 291292, Washington, DC, USA, 2005. IEEE Computer Society. [59] P. Krutchen. An Ontology of Architectural Design Decisions in Software Intensive Systems. Em 2nd Groningen Workshop Software Variability, pginas 5461, Outubro 2004. [60] G. Kulm, J. Roseman, e M. Treistman. A Benchmarks-based Approach to Textbook Evaluation. Science Books & Films, 35 (4), Julho 1999. [61] P. Lago e H. van Vliet. Teaching a Course on Software Architecture. Em CSEET 05: Proceedings of the 18th Conference on Software Engineering Education & Training, pginas 3542, Washington, DC, USA, 2005. IEEE Computer Society. [62] R. J. Leblanc, A. Sobel, J. L. Diaz-Herrera, e T. B. Hilburn. Software Engineering 2004 - Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. IEEE CS e ACM, Agosto 2004. [63] H. Lin. The Development of Software for Ballistic-Missile Defense. Sci. Am., 253(6):4653, 1985. [64] M. Lindvall e D. Muthig. Bridging the Software Architecture Gap. Computer, 41(6):98101, Junho 2008. [65] J. D. C. Little. A Proof for the Queuing Formula: L= W. Operations Research, 9(3):383387, 1961.
BIBLIOGRAFIA
35
[66] M. W. Maier e E. Rechtin. The Art of Systems Architecting. CRC, Segunda Edio, Junho 2000. [67] R. Malan e D. Bredemeyer. Dening Non-Functional Requirements. Online em: http://www.bredemeyer.com/pdf_les/NonFunctReq.PDF, Agosto 2001. [68] M. R. McBride. The Software Architect: Essence, Intuition, and Guiding Principles. Em OOPSLA 04: Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pginas 230 235. ACM Press, 2004. [69] J. McCall. Factors in Software Quality: Preliminary Handbook on Software Quality for an Acquisiton Manager, volume 1-3. General Electric, Novembro 1977. [70] S. McConnell. Code Complete. Microsoft Press, Segunda Edio, Junho 2004. [71] N. Medvidovic e R. N. Taylor. A Classication and Comparison Framework for Software Architecture Description Languages. Software Engineering, IEEE Transactions on, 26(1):7093, 2000. [72] T. Mens e S. Demeyer, editores. Software Evolution. Springer, Maro 2008. [73] B. Meyer. Software Architecture Course at EHT, Swiss Fede-
ral Institute of Technology Zurich.
Pgina do curso disponvel em:
http://se.ethz.ch/teaching/2009-S/0050/index.html, 2009. [74] G. Muller. Experiences of Teaching Systems Architecting. Em INCOSE International Symposium, 2004. [75] G. C. Murphy, D. Notkin, e K. J. Sullivan. Software Reexion Models: Bridging The Gap Between Design and Implementation. Software Engineering, IEEE Transactions on, 27(4):364380, Abril 2001. [76] G. C. Murphy, D. Notkin, e K. Sullivan. Software Reexion Models: Bridging The Gap Between Source and High-Level Models. Em SIGSOFT 95: Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software engineering, pginas 1828, New York, NY, USA, 1995. ACM.
BIBLIOGRAFIA [77] Object Management Group, Inc. Unied modeling
36 language.
http://www.uml.org, Agosto 2009. [78] D. L. Parnas. On the Criteria to Be Used In Decomposing Systems Into Modules. Classics in Software Engineering, pages 139150. Yourdon Press, 1979. [79] D. L. Parnas. Software Aging. Em ICSE 94: Proceedings of the 16th international conference on Software engineering, pginas 279287, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press. [80] D. E. Perry e A. L. Wolf. Foundations for The Study of Software Architecture. SIGSOFT Software Engineering Notes, 17(4):4052, Outubro 1992. [81] A. Powell, M. Nilsson, A. Naeve, P. Johnston, e T. Baker. DCMI Abstract Model. DCMI Recommendation, Junho 2007. [82] R. Pressman. Software Engineering: A Practitioners Approach. McGraw-Hill Science/Engineering/Math, Sexta Edio, Abril 2004. [83] J. W. Reeves. What is Software Design? C++ Journal, 1992. [84] Rice University. Connexions. http://cnx.org. [85] N. Rozanski e E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, Abril 2005. [86] J. Ryoo, P. Laplante, e R. Kazman. In Search of Architectural Patterns for Software Security. Computer, 42(6):98100, 2009. [87] Y. Saito e M. Shapiro. Optimistic Replication. ACM Comput. Surv., 37(1):4281, Maro 2005. [88] D. Schmidt, M. Stal, H. Rohnert, e F. Buschmann. Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects. John Wiley & Sons, Setembro 2000. [89] M. Shaw e D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, Abril 1996.
BIBLIOGRAFIA [90] B. Smaalders. Performance Anti-Patterns. Queue, 4(1):4450, 2006.
37
[91] G. F. Smith e G. J. Browne. Conceptual Foundations of Design Problem Solving. Systems, Man and Cybernetics, IEEE Transactions on, 23(5):12091219, 1993. [92] K. Smolander. Four Metaphors of Architecture in Software Organizations: Finding Out The Meaning of Architecture in Practice. Em ISESE 02: Proceedings of the 2002 International Symposium on Empirical Software Engineering, Washington, DC, USA, 2002. IEEE Computer Society. [93] Software chitecture Engineering Curriculum Institute and Carnegie Mellon. Software Online Arem:
Certicate
Programs.
http://www.sei.cmu.edu/architecture/arch_curriculum.html, 2009. [94] I. Sommerville. Software Engineering. Addison Wesley, Oitava Edio, Junho 2006. [95] D. Spinellis e G. Gousios, editores. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. OReilly Media, Inc., Janeiro 2009. [96] R. F. Swonger, C. M. Scott, C. Okasaki, M. Shaw, e D. Garlan. Experience with a Course on Architectures for Software Systems. Em Proceedings of the SEI Conference on Software Engineering Education, pginas 2343, London, UK, 1992. SpringerVerlag. [97] R. N. Taylor, N. Medvidovic, e I. E. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, Janeiro 2009. [98] R. N. Taylor e A. Van der Hoek. Software Design and Architecture The Once and Future Focus of Software Engineering. Em FOSE 07: 2007 Future of Software Engineering, pginas 226243, Washington, DC, USA, 2007. IEEE Computer Society. [99] The Joint Task Force on Computing Curricula. Computing Curricula 2001 - Computer Science. IEEE Computer Society e ACM, Dezembro 2001.
BIBLIOGRAFIA
38
[100] The Joint Task Force on Computing Curricula. Computer Engineering 2004 - Curriculum Guidelines for Undergraduate Degree Programs in Computer Engineering. IEEE Computer Society e ACM, Dezembro 2004. [101] The Joint Task Force on Computing Curricula. Information Technology 2005 - Curriculum Guidelines for Undergraduate Degree Programs in Information Technology (Draft). IEEE Computer Society e ACM, Outubro 2005. [102] J. Tyree e A. Akerman. Architecture Decisions: Demystifying Architecture. Software, IEEE, 22(2):1927, 2005. [103] J. van Gurp e J. Bosch. Design Erosion: Problems and Causes. Journal of Systems and Software, 61(2):105119, Maro 2002. [104] B. Vickers. Architecting a Software Architect. Em Aerospace Conference, 2004. Proceedings. 2004 IEEE, volume 6, pginas 41554161 Vol.6, 2004. [105] A. I. Wang, E. Arisholm, e L. Jaccheri. Educational Approach to An Experiment in A Software Architecture Course. Em Software Engineering Education & Training, 2007. CSEET 07. 20th Conference on, pginas 291300, 2007. [106] R. J. Wirfs-Brock. Connecting Design with Code. Software, IEEE, 25(2):2021, 2008.
Apndice A 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-offs presentes na prtica de Arquitetura de Software. A seguir, apresentamos os captulos e suas mensagens:
Apndice B: 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; 39
40 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.
Apndice C: 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.
Apndice D: 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;
41 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.
Apndice E: 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
42 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-offs 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-offs que surgiro entre os stakeholders; O arquiteto deve entender a relao entre os stakeholders e os atributos de qualidade do software.
Apndice F: 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 nofuncionais quanto dos atributos de qualidade, enfatizando suas relaes e ferramentas de
43 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
Apndice G: 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:
44 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.
Apndice H: 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.
Apndice B 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
45
B.1 Design de Software
46

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 B.1 mostra parte da primeira verso do design de um sistema distribudo de armazenamento, o HBase1 e, atravs de uma breve avaliao desse design, observamos uma grave limitao do software. Exemplo B.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 ,
1 2
Apache HBase: http://hbase.org Os dados so inseridos no HBase na forma (chave,valor).
47
o endereo do data node em que ele pode realizar 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
B.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. A partir da viso de design como artefato, podemos observar que ele deve descrever di-
48
versos 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 B.1. (design de software). tanto o processo de denio da arquitetura, m-
dulos, interfaces e outras caractersticas de um sistema quanto o resultado desse processo.3
B.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
Freny Katki et al, editores. IEEE Standard Computer Dictionary: Compilation of IEEE Standard Com-
puter Glossaries. Institute of Electrical and Electronics Engineers Inc., 1991.
49
sistema quando construdo, ele permite esse tipo de avaliao. Alm disso, fazer o design de um sistema , geralmente, mais barato que constru-lo. Exemplo B.2. Considerando o sistema do Exemplo B.1 e que um de seus objetivos fosse a alta disponibilidade, podemos avaliar que o design apresentado 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. 2
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 situ-los no cdigo
50
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. 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 B.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 2
Por mais ecaz que um design seja, sua implementao pode no ser. O fato de haver
4
Uma descrio mais completa deste caso pode ser encontrada no artigo The Development of Software for
Ballistic-Missile Defense [63], de Lin.
B.2 Elementos do processo de design de software
51
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, 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 B.1, pode ser dividido em duas fases: diversicao e convergncia.
Figura B.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
52
ideias de soluo. Essas alternativas so solues 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.
B.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 B.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 B.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 de nmeros pode ser descrita como sua capacidade de ordenar inteiros; ou, se estamos falando de um sistema de
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.
53
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 B.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.
B.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 B.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 que no so apenas os objetivos que guiam o processo de design, necessrio diferenciar objetivos de restries. Em
54
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 B.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. 2
J no segundo exemplo, o sistema tambm tem um objetivo claro. No entanto, uma restrio torna uma possibilidade de design invivel. Exemplo B.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 o ambiente operacional suportado. Essa camada de abstrao, ento, seria implementada pelo sistema nativo ou por um emulado, caso
55
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
B.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 B.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 B.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 (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 de-
56
sign. 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. 2
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.
B.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 B.7. (representao de design). A linguagem do processo de design que repre-
senta 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. 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 des-
57
critas 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 B.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 B.2: Representao estrutural do programa de ordenao
J a segunda representao, Figura B.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 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
6
Unied Modeling Language (UML)
58
Figura B.3: Pseudocdigo do Merge sort
59
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 B.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.
B.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 B.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 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
B.3 Nveis de design de software
60
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.
B.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 B.9. (design arquitetural). Descreve a arquitetura do software ou, em poucas
palavras, como o software decomposto e organizado em mdulos e suas relaes.

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 B.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
B.4 Princpios e tcnicas de design de software
61
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
B.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.
62
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 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.
63
B.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.
B.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.
B.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; Diminui o tempo de desenvolvimento, uma vez que mdulos podem ser implementados em paralelo, ou ainda reusados; e
64
Promove a exibilidade no produto, uma vez que um mdulo pode ser substitudo por outro, desde que implemente as mesmas interfaces.
B.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.
B.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. Coeso comunicativa: as tarefas esto agrupadas porque usam os mesmos dados, mas no esto relacionadas de nenhuma outra maneira.
65
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.
B.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.
B.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.
66
Usando essa tcnica, o acoplamento entre mdulos e seus clientes diminudo, uma vez que os clientes estaro ligados apenas a interfaces e no 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 introduzilos. 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 [18], 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 [98], de Taylor e Van der Hoek, e Conceptual Foundations of Design Problem Solving [91], de Smith e Browne. Inclusive, este ltimo a nossa referncia sobre o arcabouo conceitual de design usado neste captulo.
67
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 [15], de Brooks, que discute as causas da complexidade que assola o processo de design de software; Software Design: Methods and Techniques [8], 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) [77]. J sobre tcnicas de design, citamos o livro de Booch et al, Object-Oriented Analysis and Design with Applications [12], o de McConnell, Code Complete [70] e o de Buschmann et al, Pattern-Oriented Software Architecture, Volume 1: A System of Patterns [21]. Este ltimo mais especco ao design arquitetural.
Exerccios
B.1. Quais os benefcios de se projetar sistemas? B.2. Duas fases importantes do projeto de software so as fases de Divergncia e Convergncia. Descreva o que feito em cada fase. B.3. Jack Reeves, em What is Software Design? [83], arma que o cdigo fonte design. Qual a sua opinio a respeito da armativa? B.4. Qual padro de projeto viabiliza a separao de poltica e implementao? B.5. Dena coeso e acoplamento e sugira mtricas para medi-las em software.
68
B.6. Cite diculdades que podem ser encontradas durante a aplicao de cada tcnica de design apresentada no captulo. B.7. Represente um design de software de duas maneiras diferentes. Para isso, antes ser necessrio descrever o problema que o software deve resolver. B.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 anteriomente.
Apndice C 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.
C.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 Netix1 e na iTunes Store2 .
1 2
Netix: http://www.netflix.com/ iTunes Store: www.apple.com/itunes
69
C.2 Funcionalidades do SASF
70
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.

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.
C.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. C.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.
71
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 C.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 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.
72
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 1080p4. 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.
C.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
4
Tambm chamado de full HD. Sua resoluo de 1920x1080 pixels.
73
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.
C.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 C.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 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
74
Figura C.2: Diagrama de Casos de Uso simplicado do SASF 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 servidores, 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.
C.3 Capacidades do SASF
75

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.
C.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.
C.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.
C.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 distribu-
76
Tabela C.1: Tamanhos e amostragens disponveis Nveis de denio Amostragem (em kbps) Tamanho*(em GB**)
* **
SD 375 500 1000
HD 2600 3800
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
das 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 C.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.
C.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 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.
C.4 Resumo
77
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.
C.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.
C.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 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
C.4 Resumo aplicam ao estudo de caso em questo.
78
Apndice D 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
D.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 79
D.1 Motivao para desenvolver melhores sistemas
80
maus resultados, encontramos os que custaram muito acima do oramento, os incompletos e os que no solucionam os problemas como deveriam resolver. 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 D.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. 2
Podemos observar no Exemplo D.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 D.2. Considere agora o SASF, j apresentado no Captulo C. 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. 2
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
D.2 O que Arquitetura de Software de software.
81
D.2 O que Arquitetura de Software

Desde sua primeira meno em um relatrio tcnico da dcada de 1970 intitulado Software Engineering Tecnhiques [22], 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 [45] e teve sua criao motivada justamente para fazer com que estudantes, professores e praticantes de arquitetura de software concordem sobre o termo.
D.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 [80]. A denio que eles propem consiste na Frmula D.1 e na explicao de seus termos:
Arquitetura = {Elementos, Organizao, Decises}
(D.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.
D.3 Denio de Arquitetura de Software por Perry e Wolf
82
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 D.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
D.4 Arquitetura de Software por Garlan e Shaw
83
esse elemento de processamento em elementos mais especializados: o elemento de processamento responsvel por criar, editar, recuperar 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 D.1 ilustra alguns elementos que formam a arquitetura do SASF. 2

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
Trataremos melhor desse assunto no Captulo F. Java Database Connectivity. http://java.sun.com/javase/technologies/database/ 3 REpresentational State Transfer [35]
2 1
84
Figura D.1: Alguns elementos de processamento, de dados e de conexo do SASF
D.5 Arquitetura de Software por Bass et al
85
no comportamento do sistema em termos de escala e desempenho, entre outros atributos de qualidade [39]. 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 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 D.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. 2
D.5 Arquitetura de Software por Bass et al

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:
D.5 Arquitetura de Software por Bass et al 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. [ 7]
86
Como j observado por Gorton [41], essa denio explcita quanto ao papel da abstrao na arquitetura (quando fala de propriedades externamente 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 [6], 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 D.5. Podemos observar a arquitetura do SASF atravs de uma viso de partes
funcionais (Fig. D.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. Mas essa no a nica maneira de observarmos o sistema. Podemos tambm ver o sistema como um conjunto de processos executando e se comunicando em mquinas diferentes, como observado na Figura D.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
D.6 Arquitetura de Software pelo Padro ISO/IEEE 1471-2000
87
Figura D.2: Mdulos funcionais do SASF 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. 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. 2
D.6 Arquitetura de Software pelo Padro ISO/IEEE 14712000

O propsito da criao do padro ISO/IEEE 1471-2000 [45] foi o de ajudar no consenso entre autores, estudantes e prossionais sobre o que e para que serve arquitetura de software.
D.6 Arquitetura de Software pelo Padro ISO/IEEE 1471-2000
88
Figura D.3: Processos presentes no SASF 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 D.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,
D.7 Decompondo a denio de Arquitetura de Software
89
os 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 [51], 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 D.8 e ento detalhado no Captulo H.

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.
90
D.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 D.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. 2
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 D.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
91
servidores de aplicao, aos servios de armazenamento, ou mesmo aos navegadores dos usurios. 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 D.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 D.9. 2 2
A separao do sistema em trs camadas (Figura D.4) pode tambm faci-
litar 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
D.7 Decompondo a denio de Arquitetura de Software vez que no existe acoplamento entre a apresentao e a persistncia.
92 2
Figura D.4: Ilustrao da diviso de uma arquitetura em trs camadas.
D.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 D.2. (deciso arquitetural). Uma escolha entre as alternativas de design arqui-
tetural, 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, ou servio que existir da
93
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 D.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. 2
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 D.10. (continuao) Objetivo: Esta diviso diminui o acoplamento entre os elementos internos da arquitetura, facilitando o desenvolvimento e a manuteno. 2
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 D.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 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. 2
D.7 Decompondo a denio de Arquitetura de Software Rastreabilidade
94
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 D.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 D.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 D.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. 2
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 en-
95
tendimento. 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 D.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 D.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. Exemplo D.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. 2 2
Exemplo D.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
96
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. 2
Exemplo D.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. 2
Regras para remoo ou desativao de funcionalidades, seja durante o desenvolvimento, implantao, ou execuo do sistema. Exemplo D.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 D.17. 2
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 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 conver-
97
tida 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. 2 Regras para modicao ou manuteno de funcionalidades. Exemplo D.18. No haver modicao do Web Service que realiza busca e alu-
guel 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 D.19. No Exemplo D.17, a disponibilidade de parte das funcionalida2
des, 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. 2
Exemplo D.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. 2
Exemplo D.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. 2
98
No Captulo H, Documentao da Arquitetura, voltaremos s decises arquiteturais, onde aprenderemos a categoriz-las e document-las.
D.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 D.22 e requisitos de portabilidade no Exemplo D.23. Exemplo D.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. 2
Exemplo D.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 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. 2
J atributos de qualidade organizacionais, por outro lado, so consequncia de polticas ou procedimentos organizacionais. Em outras palavras, o sistema deve respeitar padres ou
D.7 Decompondo a denio de Arquitetura de Software regras impostas por uma ou mais organizaes envolvidas para atender a esses requisitos. Exemplo D.24.
99
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. 2
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 D.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: 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. 2
D.7 Decompondo a denio de Arquitetura de Software Relacionando atributos de qualidade
100
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 D.26, notamos que o atributo de qualidade desempenho est afetando os nveis de testabilidade e entendimento do sistema. Exemplo D.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. 2
J no exemplo a seguir, o atributo de segurana afeta dois atributos distintos: o desempenho e a usabilidade do sistema. Exemplo D.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 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. 2
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-offs envolvidos para se alcanar os objetivos do software. O exemplo seguinte
D.7 Decompondo a denio de Arquitetura de Software mostra atributos de desempenho e portabilidade conitando. Exemplo D.28.
101
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. 2
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 D.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 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. 2
Veremos mais sobre atributos de qualidade de software, suas relaes, como alcan-los, e seus interessados no CaptuloF.
D.8 Vises da Arquitetura
102
D.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 D.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. 2
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 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 D.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
D.9 O Documento de Arquitetura
103
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 document-la, nem fomos especcos quanto aos benefcios proporcionados por sua documentao.
D.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:
104
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 D.31. Um novo desenvolvedor acabou de ser contratado e passou a inte-
grar 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. 2
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 D.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 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. 2
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 D.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
105
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. 2
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 D.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. 2
D.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, 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 D.35. Na documentao da arquitetura do SASF podemos observar, entre ou-
tras, duas vises diferentes: uma viso que mostra aspectos dinmicos e outra que mostra o sistema estaticamente.
106
A viso esttica mostra os principais mdulos funcionais do software e, na Figura D.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 D.5: Uma viso esttica da arquitetura do SASF 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 D.6). Obviamente, os mdulos usados nessa viso devem ter correspondentes na viso esttica. 2
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.
D.10 Por que documentar a arquitetura de software?
107
Figura D.6: Uma viso dinmica da arquitetura do SASF, mostrando o comportamento de alguns mdulos durante o processo de transmisso de um lme. 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. Exemplo D.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. 2

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 sis-
108
temas, 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 D.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!): 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. 2
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 D.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
109
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. 2
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 D.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 D.39. A organizao interna do SASF mudar ainda mais em relao aos Exemplos D.37 e D.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
110
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 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. 2
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-offs 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.
111
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 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 [80] e Garlan e Shaw [39], podemos encontrar trabalhos das dcadas de 1960 e 1970 que j citam algumas tcnicas e benefcios da rea. Entre eles, encontramos Dijkstra [30], Parnas [78] 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 Stafford [55].
Evoluo de software
A evoluo de Software bem estudada no livro editado por Mens e Demeyer, Software Evolution [72] e nos trabalhos de Parnas [79], van Gurp e Bosch [103] e Eick et al [33].
112
Mais informaes sobre a Big Ball of Mud podem ser encontradas em Foote e Yoder [36].
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 [85]. J a discusso sobre classicao dos atributos de qualidade pode ser encontrada no livro Software Engineering, de Sommerville [94]. Por m, podemos citar algumas referncias importantes sobre vises arquiteturais: The 4+1 View Model of Architecture de Kruchten [56], Documenting Software Architectures: Views and Beyond Clements de Clements et al [24] e o padro ISO/IEEE 1471-2000 [45].
Exerccios
D.1. Quais as diferenas entre design arquitetural e design de baixo nvel? D.2. Quais os benefcios de se projetar a arquitetura de um software? D.3. Quais os elementos que compem a arquitetura, qual o objetivo deles? D.4. O que so atributos de qualidade do software? Cite exemplos. D.5. Cite algumas qualidades de software que a arquitetura ajuda a alcanar. Descreva
tambm como a arquitetura ajuda no alcance dessas qualidades. D.6. O que so decises arquiteturais e qual o seu papel na arquitetura? D.7. Como a arquitetura permite o rastreamento de requisitos ao longo do processo de
desenvolvimento? D.8. O que evoluo de software e qual a inuncia da arquitetura nesse processo? D.9. O que so vises arquiteturais e qual a sua importncia no processo de desenvolvi-
mento? Descreva exemplos de vises arquiteturais. D.10. Quais os benefcios e desvantagens proporcionados pela documentao da arquitetura. Cite exemplos.
Apndice E 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
113
E.1 Quem so os interessados em um sistema de software?
114

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 E.1. Exemplo E.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. Para o cadastro, o usurio deve prover informaes para contato qualquer que seja seu papel. Porm, enquanto a conta para um consumidor
115
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 e-mail, 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 usurios mais rpido, como tambm servir a mais usurios.2 Essa
1 2
Digital Rights Management (DRM) 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.
116
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. 2
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 E.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 E.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.
E.1.1 Importncia dos interessados

Observe que no Exemplo E.1 a presena ou ausncia de um interessado tem grande inuncia na arquitetura. Alm disso, comum que sua ausncia d 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
3
Note que uma arquitetura mais simples no necessariamente signica um produto com desenvolvimento
mais barato ou execuo mais rpida.
117
Figura E.1: Stakeholders de um mesmo grupo, mas divergindo nos requisitos. 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 E.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 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
4
N. Rozanski and E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints
and Perspectives, Addison-Wesley Professional 2005.
E.2 Tipos de stakeholders e sua relao com os atributos de qualidade
118
seus atributos de qualidade e atender aos requisitos, como, por exemplo: custo, reusabilidade, testabilidade, manutenibilidade, legibilidade, desempenho, escalabilidade, segurana, conabilidade, entre outros.

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 E.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 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
119
tem impacto negativo na usabilidade. Portanto, podemos observar aqui um conito entre segurana e usabilidade. Exemplo E.3. 2
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. 2
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.
E.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 E.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, 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
120
diversos nveis de abstrao, quando esses nveis impactam negativamente no desempenho. 2 Pode parecer ingenuidade tomar decises em favor da extensibilidade quando se espera desempenho, como ilustrado no Exemplo E.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, frameworks5 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.
E.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 E.2 e E.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. Exemplo E.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 cons-
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.
6
Mas claro que as boas prticas sero ferramentas para resolver os problemas propostos pelos stakehol-
ders.
E.2 Tipos de stakeholders e sua relao com os atributos de qualidade truo.
121 2
Exemplo E.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. 2
Exemplo E.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. 2
E.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; Desenvolvimento, descrio e documentao da arquitetura do sistema, que so responsabilidades do arquiteto do sistema;
122
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 arquitetura ligadas ao seu negcio: se o sistema faz o que deveria fazer, seus custos, sejam de desenvolvimento ou de
7
Chief Information Ofcer ou CIO o nome dado ao diretor do departamento de Tecnologia da Informao
de uma empresa.
123
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 escritas de forma clara e objetiva. Ele tambm espera que o documento de arquitetura possibilite a associao dos
E.3 Resumo
124
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.
E.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; relacione os stakeholders aos atributos de qualidade esperados pelo software; e
E.3 Resumo
125
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 [45], 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 [85], 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 [7] e Documenting Software Architecture: Views and Beyond de Clements et al [24]. 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 [97], 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 Team de Kruchten [54], o Who Needs an Architect? de Fowler [37] e o The Software Architect: Essence, Intuition, and Guiding Principles de McBride [68].
E.3 Resumo
126
Responsabilidades dos stakeholders

Booch discute sobre a despreocupao dos usurios em relao arquitetura em The Irrelevance of Architecture [11]. J em Goodness of Fit [10], ele escreve sobre o que seria uma arquitetura de sucesso. Por m, Hohmann, no livro Beyond Software Architecture [44] 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
E.1. Qual a importncia da identicao dos stakeholders na arquitetura de um sistema de software? E.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. E.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?
Apndice F Atributos de Qualidade

Um software tem como objetivo atender aos seus requisitos funcionais e no-funcionais. Os requisitos funcionais descrevem as funes que o software deve ser capaz de realizar, ou seja, o que o sistema faz. J os requisitos no-funcionais 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; Entender que os atributos de qualidade se relacionam e como eles se relacionam. 127
F.1 Requisitos Funcionais e No-Funcionais
128
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.

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 F.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 F.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. 2 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 grande
1
Large Hadron Collider (LHC): http://public.web.cern.ch/public/en/LHC/LHC-en.html
129
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 F.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 F.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. 2 As restries feitas pelos requisitos no-funcionais so vrias e podem incluir restries ao processo de desenvolvimento, restries para atingir ou manter compatibilidade, e
130
restries legais, econmicas ou de interoperabilidade. As restries ao processo de desenvolvimento podem ser feitas pela 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 F.3. (requisito no-funcional de produto). Requisito que especica as caracte-
rsticas que um sistema ou subsistema deve possuir.

Os requisitos no-funcionais de produto, como j dito anteriormente, so relacionados
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 [29].
131
qualidade do software e so alcanados pelo que chamamos de atributos de qualidade. Portanto, quando existem requisitos em que o software 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 F.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 F.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 Architecture3 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 F.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 F.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 : (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 [81].
3
A Department of Defense Joint Technical Architecture (DoD JTA) [28] 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.
132
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 F.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. 2 2
J quando mencionamos que o tipo do sistema pode inuenciar em como classicamos um requisito, basta apenas lembrarmos dos sistemas de tempo-real. Neles, a corretude do comportamento do sistema no depende s do 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 F.5. Em um sistema de informao, consideramos o requisito no-funcional:
133
(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. 2 Apesar disso, vale notar que ambos os requisitos presentes no Exemplo F.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 ilustrlo com requisitos que afetam a segurana do software, mais precisamente autenticidade e condencialidade: Exemplo F.6. Se temos um sistema de mensagens instantneas com os seguintes requisitos: (RNF-01) O sistema deve prover meios de autenticar os seus usurios. (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 RNF-02 e vice-versa. A soluo no caso
134
a utilizao criptograa de chave pblica: tanto ela pode ser usada para autenticao de usurios quanto pode ser usada para encriptao de mensagens. 2
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-offs 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 F.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: 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.
F.2 Atributos de qualidade
135
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 F.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.
Alguns autores preferem o termo requisitos de qualidade.
136
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 F.7. Vamos considerar um projeto para construo de sistemas de buscas de sites web chamado Hounder5 . 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 Search7 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 (RF01), 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 o sistema utilize diversos data centers ao redor do mundo,
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 7 Google Web Search: http://www.google.com
137
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 [65], 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. 2
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 diversas caractersticas. Tanto que alguns autores usam ambas as expresses com o mesmo sentido. As principais caractersticas dos atributos de qualidade so as seguintes:
F.2 Atributos de qualidade Atributos de qualidade impem limites s funcionalidades; Atributos de qualidade se relacionam entre si; e
138
Atributos de qualidade podem tanto ser de interesse dos usurios quanto dos desenvolvedores.
F.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.
F.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-offs 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-offs 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.
F.3 Modelo de Qualidade
139
F.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 [9], o de McCall [69] e o contido no padro ISO/IEC 9126-1:2001 [47]. Vamos descrever melhor este ltimo, para assim termos uma melhor noo de quais atributos de qualidade procuramos que a arquitetura permita ao software. Denio F.7. (modelo de qualidade).
Modelo que dene e organiza os atributos do
software importantes para a avaliao de sua qualidade.
F.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 internas e externas do
8
Em Ingls, alguns autores se referem aos atributos de qualidade usando o suxo -ilities, que co-
mum 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.
140
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 F.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,
141
ele est adequado s necessidades de seus usurios comuns. Por outro lado, para se adequar s necessidades dos usurios que distribuem os lmes, uma das funes que ele deve prover a funo de upload de lmes. 2
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 F.9. Podemos observar diferentes necessidades de preciso quando com-
paramos 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 . 2
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 F.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. 2
Possivelmente, a calculadora implementar o padro para aritmtica de ponto-utuante IEEE 754-2008 A comunidade interessada em web services especicou uma srie de padres que facilitam a inPodemos encontrar uma grande lista deles no seguinte endereo:
[46]
10
teroperabilidade entre os servios. http://bit.ly/kIEXs.
142
segurana, ou capacidade de funcionar segundo os princpios de autenticao, autorizao, integridade e no-repudiao. Autenticao a capacidade 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 F.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. 2
estar de acordo com padres, ou a capacidade de aderir a normas, convenes ou leis relacionadas funcionalidade. Exemplo F.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 2
143
torno 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 F.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 DoS11 2
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
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.
144
de servidores ou ainda vericar como o sistema se comporta se dados invlidos so inseridos no sistema. Exemplo F.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. 2
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 F.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. 2
F.3 Modelo de Qualidade Usabilidade
145
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.
F.3 Modelo de Qualidade Ecincia
146
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 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 F.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 F.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. 2
No Exemplo F.16, uma forma de melhorar as condies de uso, ou mais especicamente, aumentar a quantidade de usurios simultneos, seria seria substituir um dos
147
recursos do sistema por outro com maior capacidade. Ou seja, escalar verticalmente. Exemplo F.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, conseguiramos no mais servir 5 usurios a 10 MB/seg, mas sim 10 usurios simultneos a 10 MB/seg, como ilustrado na Figura F.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. 2
Figura F.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 F.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 F.2. 2
148
Figura F.2: Escalando horizontalmente um sistema.
149
Note que a soluo do Exemplo F.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. 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 F.17. No SASF, por termos o mdulo de transmisso de vdeos separado do gestor de usurios, qualquer mudana ou adio nos formatos suportados para trans-
150
misso 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. 2 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:
12
Falamos mais do padro arquitetural MVC quando apresentamos as ferramentas de design de software no
Captulo G.
151
adaptabilidade: a capacidade de o software ser portado para outro ambiente sem precisar de modicaes alm das previstas. Exemplo F.18. O Vuze13 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 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. 2
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.
F.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 G, observaremos melhor as relaes entre os atributos de qualidade ao apresentarmos algumas tcnicas de design arquitetural para alcan-los. Isso
13
Vuze: http://www.vuze.com
F.4 Atributos de Negcio
152
acontece porque comum que essas tcnicas no afetem cada atributo de software isoladamente.

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: mercado-alvo time-to-market custo e benefcio vida til do sistema agenda de lanamento
F.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.
F.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
153
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.
F.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.
F.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.
F.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.
F.5 Design Arquitetural para Qualidade de Software
154

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: 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 G, apresentaremos tcnicas e prticas de design que o arquiteto deve conhecer para projetar sistemas com determinados atributos de qualidade. Por m, no Captulo H, apresentaremos como documentar o design arquitetural.
Referncias
Requisitos funcionais e no-funcionais
Os livros Software Engineering [94], de Sommerville, Requirements Engineering: Processes and Techniques [53], de Sommerville e Kotonya, Software Engineering: A Practitioners Approach [82], 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 [67], de Malan e Bredemeyer, mais voltado inuncia dos requisitos na arquitetura.
155
Diferenas entre requisitos funcionais e no-funcionais

A discusso sobre a inexistncia de diferenas prticas entre requisitos funcionais e nofuncionais pode ser encontrada tanto no livro Requirements Engineering: Processes and Techniques [53], de Sommerville e Kotonya, quanto no artigo Distinctions Between Requirements Specication and Design of Real-Time Systems [49], de Kalinsky e Ready, e no livro Real-Time Systems: Design Principles for Distributed Embedded Applications [52], 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.
Atributos de Qualidade
Bass et al, no livro Software Architecture in Practice [7], 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 [41]. Os livros Software Systems Architecture [85], de Rozanski e Woods, e Code Complete [70], 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 [7], de Bass et al, e Beyond Software Architecture [44], de Hohmann.
Exerccios
F.1. O que so requisitos funcionais e no-funcionais? Qual sua inuncia no projeto
arquitetural?
156
F.2. Descreva brevemente como mudanas nos requisitos no-funcionais podem acarretar mudanas no projeto arquitetural. Exemplique. F.3. Cite mais exemplos em que a diferena entre requisitos funcionais e no-funcionais
no muito evidente. F.4. Descreva casos em que os requisitos relacionados a diferentes stakeholders entram em conito. F.5. Quais so as diculdades encontradas no processo de identicao de requisitos nofuncionais? F.6. Como os atributos de qualidade se manifestam no software? Cite exemplos. F.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. F.8. Descreva casos em que requisitos de qualidade limitam os requisitos funcionais durante o ciclo de vida do software. F.9. Descreva casos em que requisitos de qualidade limitam outros requisitos de qualidade durante o ciclo de vida do software. F.10. Em que diferem os modelos de qualidade descritos por Boehm [9] e por McCall [69] em relao ao apresentado no captulo? F.11. Escolha alguns atributos de qualidade e descreva brevemente uma arquitetura que
implementa esses atributos. F.12. Cite quais stakeholders so mais afetados pelos atributos de negcio e descreva como eles so afetados.
Apndice G 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; 157
G.1 Princpios e Tcnicas de Design Arquitetural compreensibilidade e modicabilidade; e operabilidade.
158
G.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 B, 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.
G.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
159
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. 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.
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.
160
G.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 no-funcionais do sistema. Os aspectos funcionais, como de se esperar, so o que 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.
G.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 pri2
Tambm chamado de estilo arquitetural.
161
meiro 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. 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 al4 : 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
3 4
No livro Code Complete. segunda edio [70]. No livro Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. [21]
162
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. 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
G.2 Tticas de Design
163
sistemas web por meio de frameworks, a exemplo de JSF 5 , Struts6 e Spring MVC7 . 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 infraestrutura 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 Eclipse9 e diversos sistemas de manipulao de imagens que so extensveis por meio de plugins, como o GIMP10 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-offs existentes: por um lado, uma ttica pode aumentar o
JavaServer Faces Technology (JSF): http://java.sun.com/javaee/javaserverfaces/ Apache Struts: http://struts.apache.org/ 7 Spring Framework: http://www.springsource.org/ 8 MINIX : http://www.minix3.org/ 9 Eclipse: http://www.eclipse.org/ 10 The GNU Image Manipulation Program (GIMP): http://www.gimp.org 11 ImageJ - Image Processing and Analysis in Java: http://rsbweb.nih.gov/ij/
6 5
164
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-offs 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: desempenho e escalabilidade; segurana; tolerncia a faltas; compreensibilidade e modicabilidade; e operabilidade.
G.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).
165
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 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.
G.2 Tticas de Design Caching
166
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 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 conjun-
167
tos de dados chamado MapReduce12 (ou de sua implementao open source, o Hadoop13), 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 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
12
A arquitetura do MapReduce brevemente apresentada por Dean e Ghemawat no artigo MapReduce:
Simplied Data Processing on Large Clusters [27]. 13 Apache Hadoop: http://hadoop.apache.org/
168
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 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.
G.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.
G.2 Tticas de Design Princpio da falha com segurana
169
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. 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.
170
G.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. 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
171
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 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.
G.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;
G.2 Tticas de Design alta coeso e baixo acoplamento.
172
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.
G.2.5 Operabilidade
Por m, para proporcionar operabilidade ao sistema de software, o arquiteto deve aplicar as seguintes tcnicas durante o design da arquitetura. 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, per-
173
mitir 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 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
G.2 Tticas de Design uso de padres e estilos arquiteturais.
174
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 [70], de McConnell. Alm dele, podemos citar os seguintes artigos sobre o assunto: The Structure of The THEmultiprogramming System [30], de Dijkstra, e o On The Criteria to Be Used in Decomposing Systems Into Modules [78], 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 [21; 88; 19; 20]. Recomendamos tambm sobre o assunto os livros Patterns of Enterprise Application Architecture [38], escrito por Fowler, e o Software Architecture in Practice [7], escrito por Bass et al.
175
Tcnicas arquiteturais
Sobre tcnicas arquiteturais, podemos citar o livro Beautiful Architecture [95], 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 [97], de Taylor et al, quanto o livro Software Systems Architecture [85], de Rozanski e Woods. O livro The Art of Systems Architecting [66], 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 [90], de Smaalders; sobre replicao de dados: Optimistic Replication [87], de Saito e Shapiro; e sobre segurana: In Search of Architectural Patterns for Software Security [86], 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 [42] e o Engineering @ Facebook [34].
Exerccios
G.1. Descreva exemplos de uso de nveis de abstrao em projetos de arquitetura. G.2. Quais os benefcios proporcionados pela separao de preocupaes durante o design arquitetural? Quais as desvantagens? G.3. Quais os benefcios proporcionados pelo uso de padres? Quais as desvantagens? G.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. G.5. Descreva um projeto que, ao usar uma ttica de desempenho ou escalabilidade, teve sua compreensibilidade afetada negativamente.
176
G.6. Descreva um projeto que, ao usar uma ttica de desempenho ou escalabilidade, teve sua operabilidade afetada negativamente. G.7. O que um ponto nico de falhas? Cite exemplos em design arquitetural. G.8. Descreva um exemplo de ponto nico de falhas que pode surgir ao se aplicar a tcnica de partio dos dados. G.9. Descreva um projeto que, ao usar uma ttica de segurana, teve sua operabilidade
afetada negativamente. G.10. Descreva como tcnicas de tolerncia a faltas afetam a operabilidade do software.
Apndice H 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;
177
H.1 Arquitetura e Documento da Arquitetura
178

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 documentlo 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.
H.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 H.1, podemos observar como o SASF est dividido em grandes mdulos funcionais e, assim, podemos inferir quais
179
so suas principais funcionalidades 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 H.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 H.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. 2 No Exemplo H.2, mostramos o SASF sob um ponto de vista de implantao. Neste exemplo, podemos observar informaes de congurao para implantao de servios para
180
Figura H.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. executar o SASF informaes que estavam ausentes no exemplo anterior. Exemplo H.2. (Deciso Arquitetural 002) A implantao do mdulo que implementa as funcionalidades do servio de transmisso de lmes deve depender apenas de um parmetro: 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
181
faz requisies ao servio de congurao pelos endereos dos servios de cadastro e dos servios de armazenamento de lmes, por exemplo. 2
H.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.
182
H.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 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 H.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 H.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 H.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. 2
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 manuten-
183
o 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. Exemplo H.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. 2
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 H.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 armazena1
ImageJ - Image Processing and Analysis in Java: http://rsbweb.nih.gov/ij/
184
mento 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 armazenamento, (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 H.5. Na [Deciso Arquitetural 001], descrita no Exemplo H.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.
185
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. 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. 2
H.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
2
Esta diviso foi feita originalmente por Taylor et al em Software Architecture: Foundations, Theory, and
Practice [97].
186
menos formais do software, a exemplo de escalabilidade, manutenibilidade ou operabilidade. Outra vantagem deste tipo de anlise a de permitir o uso de representaes 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-Off 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 deadlocks4 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 Cle-
ments et al [25]. 4 Tcnica apresentada por Allen e Garlan no artigo A Formal Basis for Architectural Connection [2] 5 Mais informaes sobre a linguagem MetaH podem ser encontradas no http://www.htc.honeywell.com/metah/index.html
site:
H.1 Arquitetura e Documento da Arquitetura Anlise baseada em simulaes
187
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.
H.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. O exemplo a seguir mostra aspectos de rastreabilidade na
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 [32].
H.2 Decises Arquiteturais documentao da arquitetura do SASF.
188
Exemplo H.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. 2
H.2 Decises Arquiteturais

Em captulos anteriores, denimos arquitetura de software usando o padro ISO/IEEE 14712000, 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: Decises arquiteturais existenciais (e no-existenciais);
H.2 Decises Arquiteturais Decises arquiteturais descritivas (ou de propriedades); e Decises arquiteturais executivas.
189
H.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 H.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 H.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 H.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 H.7. (Deciso Arquitetural 005) Os dados do Cadastro de Usurios e do Cadastro de Filmes devem ser particionados horizontalmente.
190
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. 2
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.
H.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 deciso nos exemplos H.8 e H.9. Note que, em ambos os exemplos, as decises no descrevem a existncia de elementos que devem estar na
191
arquitetura, mas descrevem as propriedades de elementos arquiteturais que foram descritos em outras decises. Exemplo H.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. 2
Exemplo H.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. 2
192
H.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 H.10. Neste exemplo, apresentamos uma deciso hipottica do software Vuze7 . (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. 2
Exemplo H.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. 2
Vuze: http://www.vuze.com/
193
H.2.4 Atributos das decises arquiteturais

No Captulo D, 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 D, 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, desde que a ambiguidade seja evitada por meio de legendas ou
H.2 Decises Arquiteturais explicaes mais detalhadas.
194
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 D.10 usando diferentes linguagens diferentes. O primeiro exemplo mostra a deciso escrita em Portugus. Exemplo H.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. 2
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 H.13. (Deciso Arquitetural 001) A arquitetura do SASF dividida em trs camadas lgicas: apresentao, lgica de negcio e persistncia de dados, que sero mape8
O artigo Design tests: An approach to programmatically check your code against design rules [16], de
Brunet et al contm mais informaes sobre o DesignWizard.
195
adas respectivamente para os pacotes: com.sasf.webui, com.sasf.service, com.sasf.storage. Os testes presentes na Listagem H.1, que podem ser executados usando o DesignWizard, descrevem as regras de comunicao entre as camadas. 2 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 H.14, percebemos duas formas de meno aos requisitos implementados pela deciso. A primeira forma presena o identicador do requisito de qualidade, RNF01. J a outra forma uma breve descrio do requisito alcanado. Exemplo H.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. 2
H.2 Decises Arquiteturais Listagem H.1 Testes para comunicao entre tiers. public class ThreeTierDesignTest extends TestCase {
196
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)); } } }
197
A fundamentao normalmente feita por meio de uma descrio textual, mas deve possuir referncias a outros documentos e a outras decises arquiteturais relacionadas. O exemplo a seguir ilustra a fundamentao de uma deciso arquitetural. Exemplo H.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. 2
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. O Exemplo H.16, a seguir, descreve o escopo da Deciso Arquitetural 001, que bem
198
abrangente. J no Exemplo H.17, podemos observar que o escopo da deciso de usar JMX9 como tecnologia de monitorao mais limitado. Exemplo H.16. (continuao da Deciso Arquitetural 001) Escopo: Esta deciso vlida para todos os servios que implementam lgica e que tm interface com o usurio. 2
Exemplo H.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 H.18 ilustra o registro histrico da Deciso Arquitetural 001. Exemplo H.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: Sugerida: deciso que ainda no foi avaliada;
9
Java Management Extensions (JMX): http://java.sun.com/products/JavaManagement/
H.3 Vises arquiteturais Revisada: deciso sugerida e revisada pelo arquiteto ou time arquitetural; Aprovada: deciso sugerida, revisada e aprovada;
199
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.
H.3 Vises arquiteturais

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 executadas ao longo
200
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 H.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;
H.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 [56] e um dos primeiros a serem descritos na literatura. Inicialmente, os pontos de vista so chamados pelo autor de vises. No entanto, se analisarmos
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.
201
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 H.3.2, apresentaremos melhor os pontos de vista de Kruchten.
H.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 [85]. 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.
202
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.
H.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 [24]. 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 dife-
H.4 Documentando a Arquitetura
203
rentes: aspectos de implantao, que descreve as relaes entre as partes do software e os recursos fsicos utilizados (como servidores 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.
H.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;
204
custoso manter o documento consistente com o design atual ao longo do ciclo de vida do software. 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
205
entre si. Isso pode at ser facilitado se usarmos algumas linguagens especcas e ferramentas para 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, tornandoo 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 and Evaluation (SAVE): http://fc-md.umd.edu/save/default.asp
206
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 [66] 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 [106], 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 [97], de Taylor et al, que mostra este assunto de forma bem abrangente; e o livro Code Complete [70],
207
de McConnell, que arma a arquitetura uma ferramenta para o controle da complexidade do software.
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 [58], An Ontology of Architectural Design Decisions in Software Intensive Systems [59] e The Decision Views Role in Software Architecture Practice [57], 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 [5], de Babar e Gorton, que mostram ferramentas para organizar e documentar as decises arquiteturais; e The Decision View of Software Architecture [31], de Dueas e Capilla, e Software Architecture as a Set of Architectural Design Decisions [48], 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 H.3, podemos citar o livro Software Design [18], 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 [92], 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 [43], 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 [25], de Clements et al, que descreve os mtodos SAAM, ATAM e
H.4 Documentando a Arquitetura ARID, inclusive com estudos de casos.
208
J sobre ADLs, citamos dois surveys sobre o assunto: um conduzido por Clements, A Survey of Architecture Description Languages [23], e outro por Taylor e Medvidovic, A Classication and Comparison Framework for Software Architecture Description Languages [71]. E, nalmente, apresentamos alguns trabalhos sobre vericao de conformidade: Software Reexion Models: Bridging The Gap Between Design and Implementation [75] e Software Reexion Models: Bridging The Gap Between Source and High-Level Models [76], por Murphy et al; Bridging the Software Architecture Gap [64], de Lindvall e Muthig; e Design tests: An approach to programmatically check your code against design rules [16], de Brunet et al.
Exerccios
H.1. Quais os benefcios proporcionados pela documentao da arquitetura? H.2. Descreva um caso em que a documentao serve de ferramenta de comunicao
durante o processo de desenvolvimento. H.3. Pesquise exemplos para cada tipo de anlise da arquitetura, descreva-os brevemente e cite suas vantagens e desvantagens de uso. H.4. O que so decises arquiteturais? Cite exemplos. H.5. Que tipos de decises arquiteturais podem ser encontradas em um documento de
arquitetura? Cite exemplos. H.6. Descreva agora as decises arquiteturais citadas como resposta dos Exerccios H.4 e H.5 usando os atributos de decises apresentados neste captulo. H.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?
209
H.8. O que so vises e pontos de vista arquiteturais? Qual o seu papel na arquitetura e no processo de desenvolvimento? H.9. Descreva decises arquiteturais utilizando os pontos de vista do conjunto de Kruchten [56]. H.10. Descreva decises arquiteturais utilizando os pontos de vista do conjunto de Rozanski e Woods [85]. H.11. [24]. Descreva decises arquiteturais utilizando os pontos de vista do conjunto do SEI

APS II Dissertacao - GuilhermeMauroGerrmoglioBarbosa

Uploaded by

Document Information

Original Title

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

APS II Dissertacao - GuilhermeMauroGerrmoglioBarbosa

Uploaded by

Copyright:

Available Formats

Universidade Federal de Campina Grande Centro de Engenharia Eltrica e Informtica Curso de Ps-Graduao em Cincia da Computao

Um Livro-texto para o Ensino de Projeto de Arquitetura de Software

Guilherme Mauro Germoglio Barbosa

rea de Concentrao: Cincia da Computao Linha de Pesquisa: Engenharia de Software

Jacques P. Sauv (Orientador)

Campina Grande, Paraba, Brasil c Guilherme Mauro Germoglio Barbosa, 04/09/2009

FICHA CATALOGRFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG

Objetivo do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relevncia do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CONTEDO 4.7 4.8

vi 69 69 70 70 72 73 75 75 75 75 76 77 77 79 79 81 81 83 85 87 89 90 92 98 102 103 103 105 107 112

Design Arquitetural para Qualidade de Software . . . . . . . . . . . . . . .

H.1 Mdulos funcionais do SASF . . . . . . . . . . . . . . . . . . . . . . . . .

C.1 Tamanhos e amostragens disponveis . . . . . . . . . . . . . . . . . . . . .

1.1 Evidncias da necessidade de estudar arquitetura de software

1.1 Evidncias da necessidade de estudar arquitetura de software

1.1 Evidncias da necessidade de estudar arquitetura de software Apenas padres arquiteturais

1.1.1 Consideraes sobre livros da rea

1.2 Objetivo do Trabalho

1.2 Objetivo do Trabalho

1.3 Relevncia do Trabalho

1.3 Relevncia do Trabalho

Captulo 2 Requisitos para um Livro-Texto

2.5 Objetivos pedaggicos

2.5 Objetivos pedaggicos

2.5 Objetivos pedaggicos

Captulo 3 Avaliao criteriosa de livros sobre Arquitetura de Software

3.1 Critrios de Avaliao

3.1 Critrios de Avaliao

3.2 Avaliao dos livros

3.2 Avaliao dos livros

Adequao Discurso parcial

Observaes Considera leitores que j so praticantes de Engenharia de Software.

Adequao Discurso Exemplos parcial completa

Tabela 3.2: Avaliao de Essential Software Architecture [41]

Adequao Discurso parcial

Observaes dirigido a praticantes e assume conhecimento prvio em AS.

Adequao Discurso parcial

Exemplos Exerccios Contedo

parcial completa parcial

Adequao Discurso nula

Adequao Discurso completa

Exemplos Exerccios Contedo

parcial nula parcial

Adequao Discurso nula

Conceitos bsicos de design e padres arquiteturais no so cobertos.

Tabela 3.7: Avaliao de Software Architecture in Practice, segunda edio [7]

Adequao Discurso Exemplos parcial parcial

Possui ampla cobertura de conceitos sobre Arquitetura de Software.

Adequao Discurso completa

Observaes Tem o foco em leitores tanto experientes quanto inexperientes.

Exemplos Exerccios Contedo

completa completa completa

4.1 Encontrar os requisitos para um livro-texto

4.1 Encontrar os requisitos para um livro-texto

4.2 Encontrar as mensagens para o livro-texto

4.3 Organizar as mensagens

4.4 Escolher a abordagem do texto

4.5 Construir a estrutura de acordo com as mensagens

4.5 Construir a estrutura de acordo com as mensagens

4.6 Evoluir o texto a partir da estrutura

4.7 Avaliar o contedo atravs de cursos voltados para graduao e ps-graduao

4.8 Renar o texto

4.8 Renar o texto