Из ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры

ГОСТ Р 57100–2016 Системная и программная инженерия. Описание архитектуры. Systems and software engineering. Architecture description. УДК 004.4:006.354 ОКС 35.080. Редакция от 12.12.2023.

А.7 Структуры архитектуры и языки описания архитектуры ГОСТ Р 57100-2016

В системной и программной инженерии понятие структуры архитектуры относится к 1970–м годам [6], [44]. Мотивацией для определения этого термина (см. 3.6) и его спецификаций (см. 6.1) в настоящем стандарте является выражение средств определения существующих и будущих структур архитектуры единообразным способом с тем, чтобы продвинуть обмен информацией о системах, архитектурах и методиках описания архитектуры. При этом ожидается взаимодействие, которое позволит улучшить понимание и способность к интероперабельности между сообществами архитектуры, использующими различные концептуальные основы. Единообразное определение точек зрения архитектуры и скоординированные наборы таких точек зрения могут продвинуть повторное использование инструментариев и методик к сообществам, использующим эти структуры.

Спецификация структуры архитектуры предназначена для установления отношения между структурой архитектуры и другими понятиями, определенными в настоящем стандарте (см. рисунки 2 и 4). Структуры архитектуры часто включают дополнительное содержание, предписания и отношения, например такие, как требования процесса, связи жизненного цикла и форматы документации, не определенные в настоящем стандарте, но потенциальные для будущих областей стандартизации.

Термин «язык описания архитектуры» (ЯОА) использовался с 1990–х годов в программных средствах, системах и сообществах архитектуры предприятия. В пределах концептуальной модели согласно настоящему стандарту язык описания архитектуры – это любой язык для использования в описании архитектуры. Поэтому ЯОА может использоваться одной или более точками зрения для структуризации определенных интересов системы в пределах описания архитектуры.

Ранние ЯОА рассматривались в [25] и [43]. ЯОА сосредоточивались на структурных интересах: крупномасштабная организация системы, выраженная в терминах компонентов, соединителей и конфигураций и изменяющая поддержку структуризации поведенческих интересов. Позже широкий спектр ЯОА разработан с поддержкой более широкого диапазона интересов. Они включают языки анализа и описания архитектуры (ЯОА) [37], язык моделирования систем [31] и A3biKArchiMate [40]. Примеры 1 и 2, представленные ниже, описывают два современных ЯОА со ссылкой на их соотношение с концептуальной моделью, определенной в настоящем стандарте.

Примеры

  1. ArchiMate упорядочивает описания архитектур в несколько слоев интересов (бизнес, приложения и технология (или инфраструктура)), несколько аспектов интересов в пределах каждого из тех слоев (структурные, поведенческие и информационные аспекты) и определяет восемнадцать основных точек зрения для них. Каждая точка зрения определяется через ее собственную метамодель, связывая эту точку зрения с другими, и задаются заинтересованные стороны, интересы, цель, слои и аспекты.
  2. Язык моделирования систем (SysML) создал унифицированный язык моделирования (UML). Язык моделирования систем определяет несколько типов диаграмм: деятельность, последовательность, машину состояний, случай использования, определение блока, внутренний блок, пакет, параметрические диаграммы и диаграммы требования. В терминах, приведенных в настоящем стандарте, каждый тип диаграммы – это вид модели. Язык моделирования систем обеспечивает важнейшие конструкции для заинтересованных сторон, интересов, представлений и точек зрения таким образом, чтобы пользователи могли создать новые точки зрения в соответствии с настоящим стандартом.

Подобно структуре архитектуры ЯОА структурирует определенное множество интересов для аудитории заинтересованных сторон, определяя один или более видов модели вместе с любыми связанными методами анализа или инструментариями. Подобно структуре архитектуры или точке зрения на архитектуру ЯОА является ресурсом многократного использования – он не ограничивает использования применительно к индивидуальной системе или описанию архитектуры [из А.7 Структуры архитектуры и языки описания архитектуры ГОСТ Р 57100–2016]

    А.З Интересы ГОСТ Р 57100-2016

    Настоящий стандарт использует термин «интерес» для того, чтобы обозначать любую тему интереса, имеющего отношение к системе. Заинтересованные стороны системы имеют различные интересы. Некоторые интересы влияют на архитектуру, и поэтому настоящий стандарт требует определять их как части описания этой архитектуры.

    Мотивация для применения этого термина произошла от словосочетания «разделение интересов» из программной и системной инженерии (EdsgerW, Dijkstra, 1974):

    «Позвольте мне попытаться объяснить Вам, что по моему представлению характерно для всего интеллектуального мышления. Это то, что каждый желает глубоко изолированно изучить некоторый аспект предмета в интересах его собственной согласованности, все время осознавая, что он занимается лишь одним из аспектов. Мы знаем, что программа должна быть правильной, и можем изучить ее только с конкретной точки зрения; мы также знаем, что ей следует быть эффективной, и в другой раз мы можем изучить ее эффективность. В следующий раз мы можем спросить себя: «Почему программа востребована»? Но, занимаясь этими различными аспектами одновременно, ничего не получается – наоборот! Это именно то, что я иногда называл «разделением интересов», которое, даже если совершенно невозможно, все же является единственной приемлемой методикой для эффективного упорядочения намерений, о которых я знаю. Это то, что я подразумеваю под «сосредоточением внимания на некоторых аспектах», что не означает игнорирования других аспектов, а только оправдывает факт того, что с точки зрения этого аспекта другой является неактуальным. Это – одно– и многократное отслеживание, рассматриваемое одновременно» [7].

    Как определено в настоящем стандарте, каждая точка зрения на архитектуру структурирует один или более интересов (см. 5.4) так, чтобы представление, соответствующее точке зрения, обращалось к определенным известным интересам рассматриваемой системы. Отделение обработки интересов с помощью представлений позволяет заинтересованным сторонам сосредотачиваться на нескольких вопросах одновременно и предлагает средство для управления сложностью (см. 5.5). Литература в области системной и программной инженерии отражает большой набор таких интересов. Примеры приведены в 4.2.3.

    Хотя интересы включают риски и опасности (см. 5.3), этот термин не следует понимать как синоним «рисков» или «беспокойств», он должен пониматься как обращение к «любой» теме интересов [из А.З Интересы ГОСТ Р 57100–2016]

      Архитектура системы (architecture) по ГОСТ Р 57100-2016

      Основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития [из 3.2 ГОСТ Р 57100–2016]

      Архитектурное представление (architecture view) по ГОСТ Р 57100-2016

      Рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов [из 3.5 ГОСТ Р 57100–2016]

      Библиография ГОСТ Р 57100-2016

      [1] ANSI/IEEE Std 1471–2000, IEEE Recommended Practice for Architectural Description of Software–Intensive Systems

      [2] Boucke, N., Composition and relations of architectural models supported by an architectural description language. Doctoral dissertation, Katholieke Universiteit Leuven, October, 2009

      [3] Buschmann F., R. Meunier, H. Rohnert, P. Sommerlad and M. Stal, Pattern–Oriented Software Architecture: ASystem of Patterns, John Wiley & Sons, 1996

      [4] Callo–Arias, Т. B., P. America, and P. Avgeriou, Defining execution viewpoints for a large and complex softwareintensive system, Proceedings of WICSA/ECSA2009

      [5] Clements P., F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting Software Architectures: Views and Beyond, Boston: Addison–Wesley, 2002

      [6] Darnton, G. and S. Giacoletto, Information in the Enterprise, Burlington, MA: Digital Press, 1992

      [7] Dijkstra, E. W., Ontheroleofscientificthought. 1974. es.utexas. edu/users/EWD/transcriptions/EWD04xx/ EWD447.html

      [8] Eeles P. and P. Cripps, The Process of Software Architecting. Addison Wesley, 2010

      [9] Hilliard, R. «Viewpoint modelling», First ICSE Workshop on Describing Software Architecture with UML, May 2001 Hofmeister, C., R. Nord, and D. Soni, Applied Software Architecture, Reading, MA: Addison–Wesley, 1999 ISO/IEC 10746–1, Information technology – Open Distributed Processing – Reference model: Overview ISO/IEC 10746–2, Information technology – Open distributed processing – Reference model: Foundations ISO/IEC 10746–3, Information technology – Open distributed processing – Reference model: Architecture ISO/IEC 12207, Systems and software engineering – Software life cycle processes ISO/IEC 15288, Systems and software engineering – System life cycle processes ISO/IEC 15289, Systems and software engineering – Content of systems and software life cycle process information products (Documentation)

      [17] ISO/IEC 15414:2006, Information technology – Open distributed processing – Reference model – Enterprise language

      [18] ISO/IEC 15504–1:2004, Information technology – Process assessment – Part 1: Concepts and vocabulary

      [19] IS0 15704, Industrial automation systems–Requirements for enterprise–reference architectures and methodologies

      [20] ISO/IEC 19501:2005, Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2

      [21] ISO/IEC 19793:2008, Information technology – Open Distributed Processing – Use of UML for ODP system specifications

      [22] ISO/IEC 25010, Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models

      [23] Kruchten, P.B., «The '4+1' View Model of Architecture», IEEE Software, 12(6), 45–50, 1995

      [24] Kruchten, P.B., «An Ontology of Architectural Design Decisions in Software–Intensive Systems», Proceedings of the 2nd Groningen Workshop on Software Variability, 54–61, 2004

      [25] Luckham, D.C., J.J. Kenney, LM. Augustin, J. Vera, D. Bryan and W. Mann, «Specification and analysis of system architecture using RAPIDE», IEEE Transactions on Software Engineering, 21(4), 336–355, April 1995

      [26] Maier, M.W. and E. Rechtin, The art of systems architecting, CRC Press, 2nd edition, 2000

      [27] Ministry of Defence Architecture Framework (MODAF), modaf.org.uk/

      [28] Muskens, J., R.J. Bril and M.R.V. Chaudron, «Generalizing consistency checking between software views», Proceedings of the 5th Working IEEE/IFIP Conference on SoftwareArchitecture(WICSA'05), 169–180, Washington, DC: IEEE Computer Society, 2005

      [29] Nuseibeh, B., J. Kramer and A. Finkelstein, «Аframework for expressing the relationships between multiple views in requirements specification», IEEE Transactions on Software Engineering, 20(10), 760–773, 1994

      [30] Obbink, Н., Р.В. Kruchten, W. Kozaczynski, R. Hilliard, A. Ran, H. Postema, D. Lutz, R. Kazman, W. Tracz, and E. Kahane. Report on Software Architecture Review and Assessment (SARA), 2002. http://philippe.kruchten.com/ a rch itectu re/SARAv1 .pdf

      [31] OMG formal/2008–11–01, Systems Modeling Language, version 1.1, November 2008

      [32] Perry, D.E. and A.L Wolf, «Foundations forthe Study of Software Architecture», ACM SIGSOFT Software Engineering Notes, 17(4), 1992

      [33] Proakis, J.G., Digital Communications. New York: McGraw–Hill, 1995

      [34] Ran, A. «ARES Conceptual Framework for Software Architecture», M. Jazayeri, A. Ran, and F. van der Linden (eds.), Software Architecture for Product Families Principles and Practice. Boston: Addison–Wesley, 1–29, 2000

      [35] Ross, D.T., «Structured Analysis (SA): a language for communicating ideas», IEEE Transactions on Software Engineering, SE–3(1), 16–34, 1977

      [36] Rozansky, N. and E. Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison–Wesley, 2005

      [37] Society of Automotive Engineers, Architecture Analysis & Design Language, http://www^OA.info/

      [38] Shaw, M. «Prospects for an engineering discipline of software», IEEE Software, November 1990

      [39] Smolander, K., «Four Metaphors of Architecture in Software Organizations: Finding out The Meaning of Architecture in Practice», Proceedings of the 2002 International Symposium on Empirical Software Engineering (ISESE'02)

      [40] The Open Group, ArchiMate 1.0 Specification, February 2009, archimate.org/

      [41] The Open Group Architecture Framework (TOGAF), opengroup.org/togaf/

      [42] Viewpoints Repository for ISO/IEC 42010 iso–architecture.org/viewpoints/

      [43] Wright ЯОА website, cs.cmu.edu/~able/wright/

      [44] Zachman, J.A., «А Framework for Information Systems Architecture», IBM Systems Journal, 26(3), 1987

      [45] Zimmermann O., Koehler J., Leymann F., Polley R., Schuster N., «Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules», The Journal of Systems and Software and Services, Special Issue on Design Decisions and Rationale in Software Architecture Special Edition on Architectural Decisions, Elsevier, 2009

      [из Библиография ГОСТ Р 57100-2016]

        В.1 Введение ГОСТ Р 57100-2016

        В настоящем приложении приведены шаблон документирования точек зрения на архитектуру и аннотируемое руководство к образцу настоящих доступных точек зрения [из В.1 Введение ГОСТ Р 57100–2016]

          В.2.1 Обзор шаблона ГОСТ Р 57100-2016

          Представлен шаблон для точек зрения на архитектуру. Точка зрения на архитектуру, которая документируется в эту форму, удовлетворяет требованиям, указанным в разделе 7.

          Шаблон состоит из ряда разделов или информационных объектов (см. В.2.2–В.2.11). Каждый раздел определен наименованием (см. В.2. X – Наименование раздела), сопровождаемым кратким описанием его намеченного содержания, руководства для разработки содержания и в некоторых случаях подраздела. Не каждый раздел необходим для документирования каждой точки зрения. Этот шаблон основан на образце, предложенном в [9] [из В.2.1 Обзор шаблона ГОСТ Р 57100–2016]

            В.2.10 Примечания ГОСТ Р 57100-2016

            Любая дополнительная информация, в которой пользователи этой точки зрения могут нуждаться или находят ее полезной [из В.2.10 Примечания ГОСТ Р 57100–2016]

              В.2.11 Источники ГОСТ Р 57100-2016

              Определяются источники конкретной точки зрения, если таковые имеются, включая автора, историю, литературные ссылки, предшествующие наработки [см. перечисление е) раздела 7] [из В.2.11 Источники ГОСТ Р 57100–2016]

                Страницы

                Подписка на Из ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры