Ретроспектива програмних архітектур

  1. До 1995 року
  2. 1995-1998 роки
  3. 1999-2005 роки
  4. Вчора
  5. перша книга
  6. трилогія SEI
  7. Боєприпаси для архітекторів
  8. прагматика
  9. Лінійки програмних продуктів
  10. Першоджерела з програмної архітектурі
  11. Предтечі
  12. уявлення архітектури
  13. Процес і прагматика
  14. Ще дві на ціпок
  15. Спільнота програмних архітекторів
  16. ресурси
  17. конференции
  18. Асоціації та робочі групи

27.04.2006 Філіп Крачтен, Хенк Оббінк, Джудіт Стаффорд

2006 Філіп Крачтен, Хенк Оббінк, Джудіт Стаффорд

Під програмної архітектурою мають на увазі структуру і принципи взаємодії компонентів програмної системи, розробку і аналіз її властивостей. Наприклад, загальна продуктивність і сумісність продуктів визначаються переважно на основі оцінки програмної архітектури. Вона відображає задум розробників, пов'язаний зі структурою і поведінкою системи, і захищає її від «ерозії» під впливом робіт із супроводу. Це - ключ до досягнення інтелектуального контролю над дуже складною системою.

Як ні парадоксально, незважаючи на поступове визрівання відповідної дисципліни, ми поки не можемо дати короткий і ясний відповідь на просте запитання: що таке програмна архітектура? Загальноприйнятих дефініцій не існує. На сайті Інституту програмної інженерії ( Software Engineering Institute , SEI), присвяченому практичним аспектам архітектури, Пол Клементс наводить кілька визначень. І хоча відсутність згоди щодо такого визначення Герасимчука суттєвою перешкодою до розвитку самої дисципліни, його досягнення виявилося досить важким завданням при створенні стандарту IEEE [ 1 ].

Область програмної архітектури ділиться на декілька підгалузей. Робоча група IFIP 2.10 (International Federation of Information Processing - Міжнародна федерація з обробки інформації) визначає наступні п'ять.

Архітектурний проект: як ми створюємо архітектуру?

Аналіз: як ми на основі архітектури відповідаємо на питання про властивості кінцевого продукту?

Реалізація: як ми створюємо систему на базі архітектурного опису?

Подання: як ми створюємо надійні артефакти, щоб «донести» архітектуру до людей і машин?

Економіка: які архітектурні проблеми впливають на бізнес-рішення?

Зрозуміло, програмна архітектура тісно пов'язана і з іншими дисциплінами. Це проектування і багаторазове використання програмного забезпечення, розробка систем і системна архітектура, корпоративна архітектура і зворотне проектування, розробка вимог і питання якості.

Погляд у минуле допоможе визначити поточний стан програмної архітектури та напрямки її майбутнього розвитку. Ми також наведемо посилання на книги, статті, конференції і Web-сайти.

До 1995 року

Ян Шарп вимовив ці слова в 1969 році на конференції NATO Conference on Software Engineering Techniques (B. Randell, JN Buxton eds., Software Engineering Techniques: Report of a Conference Sponsored by the NATO Science Committee. Scientific Affairs Division NATO, 1970). Сьогодні, 37 років по тому, вони все ще не втратили актуальності.

Є якесь доповнення до програмування, і його треба витягти на світло. Це програмна архітектура. Архітектура та проектування - не одне й те саме. Як приклад розглянемо ОС / 360. Частини ОС / 360 запрограмовані надзвичайно добре, в них використано безліч вдалих ідей і методів. Причина, по якій операційна система виявилася безформною купою програм, полягає в тому, що у неї не було архітектора. Її проектування було доручено кільком групам інженерів, кожному з яких доводилося винаходити власну архітектуру. І коли всі частини з'єднали, вони не перетворилися на ціле.

Багато що з того, що ми тлумачимо як теорію і практику, на ділі є архітектурою і проектуванням. Теоретиками і практиками можуть бути як інженери, так і архітектори. Наприклад, я не вважаю, що Дейкстра займається в основному теорією: ймовірно, через деякий час ми будемо говорити про архітектурній школі Дейкстри.

Зазвичай специфікації програмного забезпечення розглядаються як функціональні: ми розмірковуємо лише про те, що програма повинна робити. Але будь-який, хто відповідає за реалізацію програмного забезпечення, повинен задуматися про більше. Йому необхідно вибудувати проект - форму; в рамках якої будуть творити програмісти або інженери. Жоден інженер або програміст, жоден інструмент програмування не допоможе ні нам, ні софтверному бізнесу компенсувати недоліки проекту. Контроль, управління, навчання та інші речі, про які ми говоримо, дуже важливі, але фахівці з реалізації повинні розуміти задум архітектора.

Ймовірно, багато хто знайомий з хорошими програмами. Замислившись, чому та чи інша програма хороша, ви зрозумієте: розробник повністю усвідомлював, чого хоче домогтися, і перш за все створював форму. Деякі з тих, хто здатні створити форму, не в силах її реалізувати, і навпаки. Біда в тому, що в галузі, особливо в великих промислових імперіях, майже не приділяється уваги архітектурі. На цій конференції були присутні деякі з першопрохідців у цій галузі, в тому числі Тоні Хоар, Едсгер Дейкстра, Алан Перліс, Пер Брінч Хансен, Фрідріх Бауер і Ніклаус Вірт. З тих пір і до кінця 80-х слово «архітектура» використовувалося переважно для позначення системної архітектури, т. Е. Фізичної структури комп'ютерної системи, а іноді - системи команд сімейства комп'ютерів. Ключові положення, пов'язані з організацією програмних систем, викладені в роботах Фреда Брукса [2], Батлера Лампсона [3], Девіда Парнасу [4-7] і Джона Міллса [8]. Правда, стаття Міллса ставилася швидше до процесів і прагматиці програмної архітектури.

Концепція програмної архітектури як окремої дисципліни зародилася в 1990 році (див. малюнок ). Батько і син Уїнстон і Уолкер Ройс в статті [ 9 ], Що вийшла в 1991 році, вперше позиціонували програмну архітектуру як сполучна ланка між технологіями і процесами. Ебергард Речтін присвятив програмного забезпечення кілька розділів своєї книги [10]. А Філіп Крачтен написав статтю, яка б пов'язала ітеративну розробку з архітектурою, і визначив кілька подань для використання у великій командно-адміністративній системі [ 11 ].

Дюейн Перрі та Олександр Уолф опублікували основну статтю [12]. У ній була запропонована знаменита формула «{елементи, форми, пояснення} = програмна архітектура», до якої Баррі Боем незабаром додав «обмеження». Для багатьох дослідників «елементи» в цій формулі означали «компоненти та з'єднувачі», які і стали основою безлічі мов опису архітектури (architecture description language, ADL), в тому числі C2, Rapide, Darwin, Wright, ACME і Unicon. На жаль, вони не дуже прижилися. У 1994 році вийшла перша книга з програмної архітектурі, написана колишніми співробітниками IBM Бернардом Віттом, Террі Бейкером і Евереттом Меррита [13].

1995-1998 роки

У 1995-му почався справжній бум програмної архітектури. Події прискорилися за рахунок численних «вкладів» галузевої і академічної науки. Помітними явищами стали метод аналізу програмної архітектури SAAM (Software Architecture Analysis Method - перший із серії методів, запропонованих SEI [14]), підходи на базі кількох вистав (такі як модель вистави «4 + 1» компанії Rational [15] і чотири вистави Siemens [16]), а також спеціальні шаблони для розробки програмної архітектури [17]. Корпорації Siemens [18], Nokia [19], Philips [20], Nortel, Lockheed Martin, IBM і інші великі розробники програмного забезпечення (переважно для областей складних систем, авіації, космонавтики та телекомунікацій) почали приділяти увагу програмної архітектурі. Вони кооперировались в рамках досліджень архітектури продуктових лінійок програмних продуктів [21]. Ще одна книга Речтіна і Марка Майера [22] вдало заповнила прогалину між обладнанням і програмним забезпеченням.

1999-2005 роки

У 1999 році відбулася перша конференція з програмної архітектурі [23], були засновані робоча група IFIP Working Group 2.10 і інститут Worldwide Institute of Software Architects. Безліч фахівців енергійно взялися за розробку передових методів [24-27]. У надії підвищити практичну цінність опису архітектури група Open Group на базі XML створила мову Architecture Description Markup Language, який забезпечив спільне використання архітектурних моделей. Об'єднані зусилля спільнот прихильників багаторазового використання коду привели до появи спеціальних продуктових лінійок і методів, які привернули увагу великих промислових компаній. Так, наприклад, з'явилися і сформувалися методи SAAM, BAPO і ATAM [14, 28, 29], а до вже имевшемуся загального стандарту архітектури RM-ODP [30, 31] додався IEEE тисячі чотиреста сімдесят одна [1]. Одночасно в SEI продовжували випускати книгу за книгою [ 29, 32-34 ].

Вчора

У великих компаніях на зразок Microsoft є власні головні архітектори, причому спостерігається деяка перевага програмного архітектора над розробником. Перший вирішує дуже різні питання, незважаючи на заклик Мері Шоу не називати архітектурою все, що попадається на очі. З'явилося чимало виразних мов опису архітектури ADL, але на практиці використовуються лише деякі з них. Винятком, мабуть, є Koala [35] і UML (якщо сприймати його як ADL, але багато пуристи вважають інакше).

Для деяких предметних областей є готові архітектури у вигляді платформ - наприклад, J2EE, .Net, Symbian / Series 60 і Websphere. Стандарти обміну даними на рівні додатків, такі як XML і SOAP, надали на них значний вплив. Мови сценаріїв, скажімо Python і Perl, змінили звичні способи конструювання систем. Архітектори більше не можуть починати «з чистого аркуша»: вони будують системи на основі своїх уявлень про можливості цих платформ. Програмне забезпечення з відкритим кодом також сильно впливає на архітектурну практику.

Сума знань про програмної архітектурі викладена більш ніж в 25 монографіях (див. Врізку « Бібліотека по програмної архітектурі ») І численних наукових статтях (див. Врізку« Першоджерела з програмної архітектурі »). Сформувалося активна спільнота фахівців, десятки університетів по всьому світу викладають програмну архітектуру, безліч організацій пропонують курси підготовки архітекторів. Одним словом, дисципліна народилася. n

література

  1. IEEE тисячу чотиреста сімдесят один: 2000. Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Press, 2000..
  2. F. Brooks, The Mythical Man-Month. Addison-Wesley, 1975.
  3. B. Lampson, Hints for Computer System Design. Operating Systems Rev., 1983, vol. 15, no. 5.
  4. D. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules. Comm. ACM, 1972, vol. 15, no. 12.
  5. D. Parnas, On the Design and Development of Program Families. IEEE Trans. Software Eng., 1976, vol. 2, no. 1.
  6. D. Parnas, P. Clements, A Rational Design Process: How and Why to Fake It. IEEE Trans. Software Eng., 1986, vol. 12, no. 2.
  7. D. Parnas, P. Clements, D. Weiss, The Modular Structure of Complex Systems. IEEE Trans. Software Eng., 1985, vol. 11, no. 3.
  8. J. Mills, A Pragmatic View of the System Architect. Comm. ACM., 1985, vol. 28, no. 7.
  9. WE Royce, W. Royce, Software Architecture: Integrating Process and Technology. TRW Quest., 1991, vol. 14, no. 1.
  10. E. Rechtin, Systems Architecting: Creating and Building Complex Systems. Prentice Hall, 1991.
  11. P. Kruchten, Un Processus de Developpement de Logiciel Iteratif et Centre sur l? Architecture [An Iterative Software Development Process Centered on Architecture]. Proc. 4? Eme Congres de Genie Logiciel, EC2, 1991.
  12. D. Perry, A. Wolf, Foundations for the Study of Software Architecture. ACM Software Eng. Notes., 1992, vol. 17, no. 4.
  13. B. Witt, F. Baker, E. Merritt, Software Architecture and Design: Principles, Models and Methods. Van Nostrand Reinhold, 1994.
  14. R. Kazman et al, SAAM: A Method for Analyzing the Properties of Software Architectures. Proc. 16th Int? L Conf. Software Eng. (ICSE 94), IEEE CS Press, 1994.
  15. P. Kruchten, The 4 + 1 View Model of Architecture. IEEE Software, 1995, vol. 12, no. 6.
  16. D. Soni, R. Nord, С Hofmeister, Software Architecture in Industrial Applications. Proc. 17th Int? L Conf. Software Eng. (ICSE-17), ACM Press, 1995.
  17. E Buschmann et al, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996..
  18. C. Hofmeister, R. Nord, D. Soni, Applied Software Architecture. Addison-Wesley, 1999..
  19. A. Ran, ARES Conceptual Framework for Software Architecture. Software Architecture for Product Families: Principles and Practice, M. Jazayeri, A. Ran and E van der Linden, eds., Addison-Wesley, 2000..
  20. J. Miiller, Integrating Architectural Design into the Development Process. Proc. 1995 Int? L Symp. and Workshop Systems Eng. of Computer-Based Systems, IEEE Press, 1995.
  21. I. Jacobson, K. Palmkvist, S. Dyrhage, Systems of Interconnected Systems. Report on Object-Oriented Analysis and Design (ROAD), May-June 1995 року, vol. 2, no. 1.
  22. E. Rechtin, M. Maier, The Art of Systems Architecting. CRC Books, 1997..
  23. P. Donohue, ed. Software Architecture-1st IFIP Conf. Software Architecture (Wicsa 1) .- Kluwer Academic Publishers.- 1 999.
  24. RC Malveau and TJ Mowbray. Software Architect Bootcamp, 2nd ed., Prentice Hall, 2000..
  25. DM Dikel, D. Kane and JR Wilson. Software Architecture: Organizational Principles and Patterns.- Prentice Hall.- 2001.
  26. H. Obbink et al., Report on Software Architecture Review and Assessment (SARA). V1.0, Feb. 2002.
  27. P. Kruchten, The Rational Unified Process-An Introduction, Addison-Wesley, 1998..
  28. H. Obbink et al, COPA: A Component-Oriented Platform Architecting Method for Families of Software-Intensive Electronic Products (Tutorial). Proc. 1st Software Product Line Conf. (SPLC1), 2000..
  29. P. Clements, R. Kazman, M. Klein, Evaluating Software Architecture. Addison-Wesley, 2002.
  30. ISO / IEC 10746: 1995, Reference Model of Open Distributed Processing (RM-ODP). ITU Rec. X901, 1995.
  31. J. Putman, Architecting with RM-ODP. Prentice Hall, 2000..
  32. L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. Addison-Wesley, 1998..
  33. P. Clements et al., Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2002.
  34. P. Clements, L. Northrop, Software Product Lines: Practice and Patterns. Addison-Wesley, 2002.
  35. R. van Ommering et al., The Koala Component Model for Consumer Electronics. IEEE Trans. Computers, 2000., vol. 33, no. 3.
  36. M. Shaw, The Coming-of-Age of Software Architecture Research. Proc. 23rd Int? L Conf. Software Eng. (ICSE 01), IEEE CS Press, 2001..
  37. B. Selic, The Pragmatics of Model-Driven Development. IEEE Software, 2004, vol. 20, no. 5.
  38. R. Soley, Model-Driven Architecture. Object Management Group, 2000..
  39. J. Bosch, Software Architecture: The Next Step, Proc. 1st European Workshop Software Architecture (EWSA 04), Springer, 2004.

Філіп Крачтен ( [email protected] ) - професор Університету Британської Колумбії, Хенк Оббінк ( [email protected] ) - провідний науковий співробітник лабораторії Philips Research Laboratories в Ейндховені, Джудіт Стаффорд ( [email protected] ) - запрошений дослідник в Інституті програмної інженерії Університету Карнегі-Меллона.

Philippe Kruchten, Henk Obbink, Judith Stafford. The Past, Present, and Future for Software Architecture. IEEE Software, March / April 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.

Бібліотека по програмної архітектурі

Кожному програмному архітекторові ми рекомендуємо наступні 12 книг. Вони охоплюють широке коло питань і складають необхідний фундамент для подальшого вивчення, досліджень і практичної діяльності.

перша книга

M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996. Ця книга поміщає програмну архітектуру на гідне місце в загальній картині світу, розцінюючи її як дисципліну, відмінну від програмування. Автори спробували дати визначення програмної архітектури, що є досить важким завданням. Десять років по тому ми все ще не прийшли до спільної думки. Велика частина книги присвячена концепції архітектурних стилів, в ній також є глава про підготовку програмних архітекторів.

трилогія SEI

L. Bass, P. Clements, R. Kazman, Software Architecture in Practice. 2nd ed. Addison-Wesley, 2003. У цій книзі, вперше опублікованої в 1998 році, детально висвітлено низку аспектів програмної архітектури: процеси та методи, уявлення, технічні прийоми, інструменти та вплив на бізнес. У ній пропонується гарне введення в кілька архітектурних методів SEI.

P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002. Присвячена виключно поданням і документування програмної архітектури, ця книга де-факто стала практичним посібником з досить абстрактному стандарту IEEE Standard 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems.

P. Clements, R. Kazman, M. Klein, Evaluating Software Architecture. How good is this architecture? Addison-Wesley, 2002. Третя книга трилогії SEI (плодовита група її авторів написала значно більше книг) фокусується на розгляді і оцінці різних аспектів якості архітектури, існуючої або створюваної знову. Хороше доповнення до звіту Software Architecture Review and Assessment (SARA) Report (SARA Working Group, 2002).

Боєприпаси для архітекторів

C. Hofmeister, R. Nord, D. Soni, Applied Software Architecture. Addison-Wesley, 1999. Спираючись на досвід роботи в дослідницькому центрі Siemens, автори пропонують систематичний, детальний метод проектування та подання програмної архітектури.

I. Jacobson, M. Griss, P. Jonsson, Software Reuse: Architecture. Process and Organization for Business Success. Addison-Wesley, 1997. Ця книга об'єднує співтовариство фахівців з багаторазового використання програмного забезпечення (яке раніше процвітало, але стало злегка видихатися в середині 90-х) з спільнотою архітекторів, показує шляхи до їх взаємному збагаченню. У ній представлені елементи архітектурного методу, втіленого в процесі RUP (Rational Unified Process).

F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. Спираючись на роботи «Банди чотирьох» (Gang of Four, GoF - це неформальне прізвисько авторського колективу у складі Еріха Гамми, Річарда Хелма, Ральфа Джонсона і Джона Вліссідес. - Прим. Пер.), Присвячені шаблонами проектування архітектури, ця «Банда п'ятьох» зібрала корисний каталог таких шаблонів. На жаль, їхня робота, настільки добре почалася, не отримала продовження.

прагматика

R. Malveau, T. Mowbray, Software Architect Bootcamp, 2nd ed. Prentice Hall, 2000. Початкове керівництво для практиків.

DM Dikel, D. Kane, J. Wilson, Software Architecture: Organizational Principles and Patterns. Prentice Hall, 2001. У своїй моделі VRAPS (vision, rhythm, anticipation, partnering and simplification) автори відобразили динаміку взаємин в групі програмних архітекторів.

E. Rechtin, M. Maier, The Art of Systems Architecting. CRC Books, 1997. Перша книга Речтіна, що вийшла в 1991 році, була присвячена швидше апаратного, ніж програмному забезпеченню. Однак програмні архітектори могли з користю застосувати багато з представлених в ній принципів. Об'єднаними зусиллями Майер і Речтін змогли точніше і глибше висвітлити питання, пов'язані з програмним забезпеченням. Новачкам ця книга може здатися занадто складною, так що їм слід почати з перших двох книг, зазначених в цьому ж розділі нашої «бібліотеки».

Лінійки програмних продуктів

J. Bosch, Design and Use of Software Architecture: Adopting and Evolving a Product-Line Approach. Addison-Wesley, 2000. Ця і наступна книги описують програмну архітектуру в застосуванні до лінійок програмних продуктів.

M. Jazayeri, A. Ran, F. van der Linden, P. van der Linden, Software Architecture for Product Families: Principles and Practice. Addison-Wesley, 2000..

Першоджерела з програмної архітектурі

основи

D. Perry, A. Wolf, Foundations for the Study of Software Architecture. ACM Software Eng. Notes, 1992, vol. 17, no. 4. Цю основну роботу завжди будуть пам'ятати завдяки запропонованій в ній карбованої формулою {елементи, форми, пояснення} = програмна архітектура.

Предтечі

D. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules. Comm. ACM, 1972, vol. 15, no. 12. Програмна архітектура, що зародилася на початку 90-х, виникла не на порожньому місці. Хоча Девід Парнас і не використовував термін «архітектура», більшість основотвірний ідей і концепцій багато чим завдячуємо його робіт. Ця та дві наступні статті є найбільш важливими.

D. Parnas, On the Design and Development of Program Families. IEEE Trans. Software Eng., 1976, vol. 2, no. 1.

D. Parnas, P. Clements, D. Weiss, The Modular Structure of Complex Systems. IEEE Trans. Software Eng., 1985, vol. 11, №. 3.

F. DeRemer, H. Kron, Programming-in-the-Large versus Programming-in-the-Small. Proc. Int? L Conf. Reliable Software, ACM Press, 1975. Запропонований авторами мову MIL 75 (Module Interconnection Language) фактично є попередником всіх мов ADL, а його цілі проектування зберігають силу і сьогодні. Автори мали чітке уявлення про архітектуру. Вони відрізняли її не тільки від проектування і програмування на рівні модулів, але і від більш абстрактного високорівневого проектування.

уявлення архітектури

D. Soni, R. Nord, C. Hofmeister, Software Architecture in Industrial Applications. Proc. 17th Int? L Conf. Software Eng. (ICSE 95), ACM Press, 1995. У статті представлена ​​модель п'яти уявлень Siemens, яку автори деталізували в книзі Applied Software Architecture.

P. Kruchten, The 4 + 1 View Model of Architecture. IEEE Software, 1995, vol. 12, no. 6. Описана частина підходу, сьогодні відомого як Rational Unified Process. Багато консультантів Rational використовували в великих промислових проектах саме цей набір уявлень. Своїм корінням він йде в роботу, виконану Alcatel і Philips в кінці 80-х.

Процес і прагматика

B. Lampson, Hints for Computer System Design. Operating Systems Rev., 1983, vol. 15, no. 5. Ця і наступна статті стали джерелами натхнення для Крачтена, в той час перспективного програмного архітектора. Вони анітрохи не застаріли, і сьогодні, як і раніше залишаються актуальними.

J. Mills, A Pragmatic View of the System Architect. Comm. ACM, 1985, vol. 28, no. 7.

WE Royce, W. Royce, Software Architecture: Integrating Process and Technology. TRW Quest, 1991, vol. 14, no. 1. У цій статті чітко сформульована зв'язок між архітектурою та процесом. Зокрема, йдеться про необхідність ітеративного процесу, в рамках якого на ранніх ітераціях будується і перевіряється архітектура.

Ще дві на ціпок

Нам хотілося б згадати ще безліч статей про таких мовах ADL, як Rapide, Wright і C2, а також про архітектуру, що спирається на моделі. Але пора зупинитися, тому ми додамо тільки дві.

M. Shaw, P. Clements, A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. Proc. 21 st Int? L Computer Software and Applications Conf. (COMPSAC 97), IEEE CS Press, 1997..

M. Shaw, The Coming-of-Age of Software Architecture Research. Proc. 23rd Int? L Conf. Software Eng. (ICSE 01), IEEE CS Press, 2001..

Спільнота програмних архітекторів

Ось кілька місць, де можна отримати додаткову інформацію про програмну архітектуру, взяти участь в конференціях або поспілкуватися з колегами.

ресурси

  • Сайт Software Architecture for Software-Intensive Systems Інституту програмної інженерії ( www.sei.cmu.edu/architecture ) Містить безліч визначень, статей про методи SEI і додаткових посилань. Сайт підтримує група архітектурної практики SEI.
  • Web-сторінка Gaudi System Architecting , Названа на честь відомого іспанського архітектора, присвячена системної архітектурі. Сторінку веде Герріт Міллер, співробітник Philips Research.
  • архітектурний портал Software Architecture, Architects and Architecting ведуть Дана Бредемейер і Рут Малан. Портал містить не тільки їх роботи, але і добре організоване зібрання інших ресурсів і посилань.
  • Web-сторінка Software Product Lines присвячена продуктових лінійок і багаторазового використання коду.
  • SoftwareArchitectures.com - ще один портал, який відкриває шлях до архітектурних ресурсів.
  • Граді Буч з IBM очолює розробку довідника для програмних архітекторів, створює репозитарій архітектурних зразків і практичних прикладів.

конференции

Асоціації та робочі групи

Як ні парадоксально, незважаючи на поступове визрівання відповідної дисципліни, ми поки не можемо дати короткий і ясний відповідь на просте запитання: що таке програмна архітектура?
Kruchten, Un Processus de Developpement de Logiciel Iteratif et Centre sur l?
Th Int?
Th Int?
Int?
How good is this architecture?
Int?