Science (AAAS), pode ser realizada através de três passos [60]. O primeiro passo consiste
na identificação dos objetivos pedagógicos que um livro-texto deve ter, considerando a dis- ciplina em questão. Como pode ser observado na Seção 2.5, este passo foi realizado neste trabalho, uma vez que os objetivos pedagógicos são essenciais para a escrita de um livro- texto. O segundo passo, consiste em cada professor voluntário atribuir notas de 0 a 3 para cada objetivo pedagógico implementado por cada livro sobre os seguintes critérios:
• Se o livro identifica o contexto do assunto;
• Se o livro faz as considerações corretas sobre o conhecimento prévio do aluno;
• Se o livro motiva o aluno, por meio de exemplos com os quais ele se identifique;
• Se o livro desenvolve as mensagens presentes no assunto usando um encadeamento lógico significativo para o aprendizado;
• Se o livro promove a reflexão por parte do aluno;
• Se o livro provê meios de avaliação do progresso do aluno;
• Se o livro enriquece o ambiente de aprendizado.
Coletando e analisando esses dados, seria possível inferir uma melhor ordenação quanto à adequação dos livros-texto aos alunos de graduação e onde seria inserido este trabalho em meio aos livros existentes. No entanto, dois fatores impediram a viabilidade da aplicação desta técnica de avaliação. O primeiro fator é que, para que os dados sejam significativos, uma quantidade considerável de professores deveria participar. Já o segundo fator consiste em que, além de serem em quantidade considerável, os professores deveriam ter conhe- cimento prévio dos livros avaliados ou deveriam dispor de tempo para conhecer todos os livros e assim realizarem a avaliação.
5.2 Considerações sobre os trabalhos futuros
Apesar de ser um livro-texto, a publicação deste trabalho não será realizada da forma tradi- cional. Na verdade, para alcançar o maior número de leitores, todo o conteúdo gerado neste
5.2 Considerações sobre os trabalhos futuros 28 trabalho está disponibilizado sob uma licença Creative Commons [26]. A licença permite cópia, distribuição e, o mais importante, adaptação e expansão do conteúdo por parte de outros autores.
O conteúdo está disponível por meio do sistema chamado Connexions [84] e pode ser encontrado no endereço http://cnx.org/content/col10722/. Usando este sis- tema, além de tornar o conteúdo acessível a qualquer pessoa interessada, é também possível receber feedback dos leitores para eventuais melhorias. Além disso, é possível convidar e conceder privilégios de escrita a novos autores, de forma a tornar o processo de contribuição 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 realização desses ajustes e a busca por contribuições externas compõem os objetivos das próximas atividades em relação ao livro. Entre as partes que necessitam de ajustes, dois capítulos devem ser mencionados.
O capítulo sobre técnicas de design arquitetural pode ser melhorado se forem adicionados estudos de caso reais sobre o assunto. A adição de novos casos é simples, porém 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 capítulo que merece mais contribuições é o de documentação arquitetural. Neste capítulo são citados três exemplos de conjuntos de pontos de vista arquiteturais, mas faltam casos de documentação que seguem esses conjuntos. Novamente, a adição de casos reais pode melhorar o capítulo, só que dessa vez focando nos documentos dos projetos ao invés de apenas no design.
Dado que o conteúdo dos capítulos está disponível para leitura, adaptação e expansão por terceiros e que o custo das eventuais contribuições é relativamente baixo, é de se esperar que contribuições externas aconteçam visando a melhoria do texto, tanto nos capítulos indicados, quanto com capítulos adicionais. Inclusive, já existem alguns estudantes, professores e pro- fissionais experientes em Engenharia de Software que se mostraram dispostos a contribuir e que já estão trabalhando em suas propostas para melhoria do texto.
Bibliografia
[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):213–249, 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, Appro- aches, and Tools. Em Software Engineering - Companion, 2007. ICSE 2007 Compa-
nion. 29th International Conference on, páginas 170–171, 2007.
[6] L. Bass, P. Clements, e R. Kazman. Software Architecture in Practice. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA, Primeira Edição, 1998.
[7] L. Bass, P. Clements, e R. Kazman. Software Architecture in Practice. Addison- Wesley Professional, Segunda Edição, Abril 2003.
[8] L. Belady. Prefácio. 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 Qua- lity. Em International Conference on Software Engineering, páginas 592–605, San Francisco, 1976. IEEE Computer Society Press.
BIBLIOGRAFIA 30 [10] G. Booch. Goodness of Fit. Software, IEEE, 23(6):14–15, 2006.
[11] G. Booch. The Irrelevance of Architecture. Software, IEEE, 24(3):10–11, 2007.
[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 Professio-
nal, Terceira Edição, 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, páginas 1069–1076,
1986.
[15] F. P. Brooks. The Mythical Man-Month: Essays on Software Engineering, 20th Anni-
versary Edition. Addison-Wesley Professional, Agosto 1995.
[16] J. Brunet, D. Guerrero, e J. Figueiredo. Design Tests: An Approach to Programma- tically Check Your Code Against Design Rules. Em Software Engineering - Compa-
nion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, pági-
nas 255–258, 2009.
[17] O. Bubak. Composing a Course Book for System and Enterprise Architecture Educa- tion. Em System of Systems Engineering, 2006 IEEE/SMC International Conference
on, páginas 6 pp.+, 2006.
[18] D. Budgen. Software Design. Addison Wesley, Segunda Edição, 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
BIBLIOGRAFIA 31 [22] J.N. Buxton e B. Randell. Software Engineering Techniques. Relatório Técnico,
NATO Science Committee, Roma, Itália, Abril 1970.
[23] P. Clements. A Survey of Architecture Description Languages. Em Software Specifi-
cation and Design, 1996., Proceedings of the 8th International Workshop on, páginas
16–25, 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 Professio-
nal, 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: Simplified 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 Archi-
tecture, 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. O’Reilly Media, Inc., Outubro 2005.
[30] E. W. Dijkstra. The Structure of The THE-multiprogramming System. Commun.
ACM, 11(5):341–346, 1968.
[31] J. C. Dueñas e Rafael Capilla. The Decision View of Software Architecture. Software
Architecture, páginas 222–230. Springer Berlin / Heidelberg. June 2005.
[32] G. Edwards, S. Malek, e N. Medvidovic. Scenario-Driven Dynamic Analysis of Dis- tributed Architectures. Fundamental Approaches to Software Engineering, páginas 125–139. 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? As- sessing The Evidence from Change Management Data. Software Engineering, IEEE
Transactions on, 27(1):1–12, 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 Archi-
tectures. 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, páginas 654–692. Addison Wesley, 2000.
[37] M. Fowler. Design - Who Needs an Architect? Software, IEEE, 20(5):11–13, 2003.
[38] M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Profes- sional, Novembro 2002.
[39] D. Garlan e M. Shaw. An Introduction to Software Architecture. Relatório Técnico 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, páginas 283–290, 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 Solu-
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 Edição 2007-07-15, páginas c1–24, Julho 2007.
[46] IEEE Std 754-2008. IEEE Standard for Floating-Point Arithmetic. Institute of Elec- trical 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 Deci- sions. Em Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Confe-
rence on, páginas 109–120, Washington, DC, USA, 2005. IEEE Computer Society.
[49] D. Kalinsky e J. Ready. Distinctions Between Requirements Specification and De- sign of Real-Time Systems. Em Software Engineering for Real Time Systems, 1989.,
Second International Conference on, páginas 26–30, 1989.
[50] O. Karam, K. Qian, e J. Diaz-Herrera. A Model for SWE Course ’Software Architec- ture and Design’. Em Frontiers in Education, 2004. FIE 2004. 34th Annual, páginas F2C–4–8 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 Appli-
cations. 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:565–583.
BIBLIOGRAFIA 34 [55] P. Kruchten, H. Obbink, e J. Stafford. The Past, Present, and Future for Software
Architecture. Software, IEEE, 23(2):22–30, 2006.
[56] P. Kruchten. The 4+1 View Model of Architecture. Software, IEEE, 12(6):42–50, 1995.
[57] P. Kruchten, R. Capilla, e Juan C. Dueñas. The Decision View’s Role in Software Architecture Practice. IEEE Software, 26(2):36–42, 2009.
[58] P. Kruchten, P. Lago, H. van Vliet, e T. Wolf. Building Up and Exploiting Architec- tural Knowledge. Em WICSA ’05: Proceedings of the 5th Working IEEE/IFIP Con-
ference on Software Architecture (WICSA’05), páginas 291–292, 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, páginas 54–61, 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,
páginas 35–42, 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 En- gineering. IEEE CS e ACM, Agosto 2004.
[63] H. Lin. The Development of Software for Ballistic-Missile Defense. Sci. Am., 253(6):46–53, 1985.
[64] M. Lindvall e D. Muthig. Bridging the Software Architecture Gap. Computer, 41(6):98–101, Junho 2008.
[65] J. D. C. Little. A Proof for the Queuing Formula: L= λ W. Operations Research, 9(3):383–387, 1961.
BIBLIOGRAFIA 35 [66] M. W. Maier e E. Rechtin. The Art of Systems Architecting. CRC, Segunda Edição,
Junho 2000.
[67] R. Malan e D. Bredemeyer. Defining Non-Functional Requirements. Online em: http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF, Agosto 2001.
[68] M. R. McBride. The Software Architect: Essence, Intuition, and Guiding Princi- ples. Em OOPSLA ’04: Companion to the 19th annual ACM SIGPLAN conference
on Object-oriented programming systems, languages, and applications, páginas 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 Edição, Junho 2004.
[71] N. Medvidovic e R. N. Taylor. A Classification and Comparison Framework for Software Architecture Description Languages. Software Engineering, IEEE Tran-
sactions on, 26(1):70–93, 2000.
[72] T. Mens e S. Demeyer, editores. Software Evolution. Springer, Março 2008.
[73] B. Meyer. Software Architecture Course at EHT, Swiss Fede- ral Institute of Technology Zurich. Página do curso disponível 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 Reflexion Models: Bridging The Gap Between Design and Implementation. Software Engineering, IEEE Transactions
on, 27(4):364–380, Abril 2001.
[76] G. C. Murphy, D. Notkin, e K. Sullivan. Software Reflexion 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, páginas
BIBLIOGRAFIA 36 [77] Object Management Group, Inc. Unified modeling 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 139–150. Yourdon Press, 1979.
[79] D. L. Parnas. Software Aging. Em ICSE ’94: Proceedings of the 16th internatio-
nal conference on Software engineering, páginas 279–287, Los Alamitos, CA, USA,
1994. IEEE Computer Society Press.
[80] D. E. Perry e A. L. Wolf. Foundations for The Study of Software Architecture. SIG-
SOFT Software Engineering Notes, 17(4):40–52, 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 Practitioner’s Approach. McGraw-Hill Sci- ence/Engineering/Math, Sexta Edição, 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):98–100, 2009.
[87] Y. Saito e M. Shapiro. Optimistic Replication. ACM Comput. Surv., 37(1):42–81, Março 2005.
[88] D. Schmidt, M. Stal, H. Rohnert, e F. Buschmann. Pattern-Oriented Software Archi-
tecture, 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 37 [90] B. Smaalders. Performance Anti-Patterns. Queue, 4(1):44–50, 2006.
[91] G. F. Smith e G. J. Browne. Conceptual Foundations of Design Problem Solving.
Systems, Man and Cybernetics, IEEE Transactions on, 23(5):1209–1219, 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 Engineering Institute - Carnegie Mellon. Software Ar- chitecture Curriculum and Certificate Programs. Online em: http://www.sei.cmu.edu/architecture/arch_curriculum.html, 2009.
[94] I. Sommerville. Software Engineering. Addison Wesley, Oitava Edição, Junho 2006.
[95] D. Spinellis e G. Gousios, editores. Beautiful Architecture: Leading Thinkers Reveal
the Hidden Beauty in Software Design. O’Reilly 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, páginas 23–43, London, UK, 1992. Springer-
Verlag.
[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 En-
gineering, páginas 226–243, Washington, DC, USA, 2007. IEEE Computer Society.
[99] The Joint Task Force on Computing Curricula. Computing Curricula 2001 - Computer
BIBLIOGRAFIA 38 [100] The Joint Task Force on Computing Curricula. Computer Engineering 2004 - Cur-
riculum 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 - Cur-
riculum 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):19–27, 2005.
[103] J. van Gurp e J. Bosch. Design Erosion: Problems and Causes. Journal of Systems
and Software, 61(2):105–119, Março 2002.
[104] B. Vickers. Architecting a Software Architect. Em Aerospace Conference, 2004.
Proceedings. 2004 IEEE, volume 6, páginas 4155–4161 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, páginas 291–300, 2007.
Apêndice A
Mensagens do Livro
O conteúdo deste livro está dividido em seis capítulos (além do estudo de caso) e cada capí- tulo serve para transmitir um conjunto específico de mensagens sobre a disciplina de Arquite- tura de Software. Além de mensagens, há outros dois tipos de elementos que são essenciais para a composição de livro: definições, que descrevem os conceitos fundamentais, e boas práticas, que são recomendações a serem seguidas pelo leitor ao aplicar o conhecimento pre- sente no livro. As recomendações têm um papel importante, principalmente, nos estudos de caso, quando o lidamos com os diversos trade-offs presentes na prática de Arquitetura de Software.
A seguir, apresentamos os capítulos e suas mensagens:
Apêndice B: Introdução a Design de Software
Neste capítulo apresentamos design de software e mostramos que ele é essencial no processo de desenvolvimento de software independentemente do nível de detalhe em que ele é apli- cado. No entanto, o design de alto nível é enfatizado, uma vez que projetar arquitetura é fazer design em alto nível. Mostramos também os elementos que compõem os problemas de design. As mensagens do capítulo são:
• O design é a estrutura ou o comportamento de um sistema que resolve ou contribui para a resolução das forças que atuam sobre esse sistema;
• Um design representa apenas um ponto no espaço de decisão;
40 • Um design pode ser singular, representando apenas uma folha na árvore de decisões,
ou coletivo, representando um conjunto de decisões;
• São cinco os elementos que compõem os problemas de design: objetivos, restrições, alternativas, representações e soluções;
• Design é necessário em todos os níveis de detalhe durante o processo de desenvolvi- mento do software.
Apêndice C: Estudo de Caso: SASF
Neste capítulo, ilustramos a necessidade de aplicar os conhecimentos de Arquitetura de Software por meio de um problema de design complexo. Nele, apresentamos tanto os re- quisitos de um sistema web de locação e transmissão de vídeos quanto seus stakeholders. Uma vez que este capítulo apenas descreve um caso, não há mensagens explícitas a serem transmitidas.
Apêndice D: Fundamentos de Arquitetura de Software
Este capítulo apresenta a definição de Arquitetura de Software usando um padrão ISO/I- EEE. Como a definição apenas não é o bastante para entendermos o porquê de se aplicar os conhecimentos de arquitetura durante o ciclo de desenvolvimento, mostramos seus benefí- cios explicitamente através de exemplos e o estudo de caso. Além da definição ISO/IEEE, mostraremos outras definições que diversos autores fizeram ao longo da história, uma vez que elas expõem características importantes para o entendimento do assunto. As mensagens deste capítulo são:
• Arquitetura é design, mas nem todo design é arquitetural. É o arquiteto quem define a fronteira entre o design arquitetural e o não-arquitetural, definindo quais decisões serão necessárias para atender aos objetivos de desenvolvimento, de comportamento e de qualidade do sistema;
41 • A arquitetura contém as decisões antecipadas de design, que têm o impacto mais caro
(caso seja necessário mudá-las ou caso elas estejam erradas);
• A arquitetura é uma abstração transferível do sistema;
• A arquitetura facilita a construção 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 evolução do sistema;
• A arquitetura facilita a análise do sistema;
• A arquitetura facilita a gerência 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 vocabulário de alternativas de design;
• Documentar a arquitetura permite a ligação entre os requisitos e as decisões de design do software;
• Documentar a arquitetura tem impacto negativo na imprecisão da especificação, que é fonte de complexidade do sistema;
• Documentar a arquitetura ajuda na divisão de tarefas entre os times de desenvolvi- mento.
Apêndice E: Stakeholders
Os stakeholders têm grande influência no design da arquitetura porque são eles que impõem os requisitos que o sistema deve atender. Por isso, para entendermos essa influência, de- vemos estudá-los. Os stakeholders demonstram essa influência porque possuem diversas responsabilidades durante o ciclo de vida do software. Neste capítulo apresentamos quem
42 são os stakeholders do software mais comuns e suas características. As mensagens deste capítulo são:
• Stakeholders influenciam a arquitetura de diversas maneiras e não necessariamente estão 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 próprio arquiteto ou outros futuros arquitetos; – os engenheiros de requisitos;
– os designers;
– os desenvolvedores; – os testadores;
– os responsáveis pela integração do software com outros sistemas; – os mantenedores do software;
– os designers de outros sistemas;