АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем

• Название: Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
• Дата: 03.06.2022
• Размер: 4.65 Mb.
• Имя файла: АРИС Текст 2.docx
• Тип: Документы; #568218
• страница: 15 из 30

ГЛАВА 7. АРХИТЕКТУРНОЕ ОПИСАНИЕ. ЯЗЫКИ ОПИСАНИЯ АРХИТЕКТУРЫ

7.1. Понятие и содержание архитектурного описания

Стандарты. Первый стандарт, относящийся к программной архитектуре – IEEE 1471—2000 [5] относится к 2000 года, а второй стандарт ISO/IEC/IEEE 42010:2011 [6] появился в 2011 году. Последний стандарт достаточно четко различает 3 основных понятия, относящиеся к архитектуре ИС: архитектура, архитектурное описание и архитектурный процесс. Эти понятия предлагается рассматривать как независимые друг от друга. Предметом стандарта ISO/IEC/IEEE 42010:2011 является архитектурное описание. В основу стандарта положены 4 основные идеи.

1. Каждая система имеет собственную архитектуру, но все архитектуры различны.

Программная архитектура рассматривается как абстракция, некоторый взгляд на систему, который содержит самую важную информацию о системе. Из архитектуры, а точнее из архитектурного описания, заинтересованные стороны могут получить интересующую их информацию о системе. Однако из архитектурного описания невозможно получить информацию о деталях реализации. Сама система является конкретным продуктом, а архитектура – это высокоуровневая абстракция.

2. Программная архитектура и архитектурное описание – это разные сущности.

Программная архитектура существует, если существует система. Архитектурное описание – это артифакт, который появляется на определенном этапе проектирования системы, основной целью которого является определение того, из каких элементов состоит система и как эти элементы связаны между собой. Таким образом, архитектурное описание появляется раньше самой системы и ее архитектуры. Фактически – это пожелание того, какой должна быть система.

Стандарт определяет архитектуру как принципы организации системы, в терминах основных компонентов, их взаимосвязей, окружения и принципов проектирования и эволюции, а архитектурное описание как набор артифактов, составляющих описание архитектуры.

Из приведенного определения видно, что архитектура – это нечто неосязаемое, с чем нельзя работать, т.е. работать можно только с архитектурным описанием. Для составления архитектурного описания могу использоваться различные языковые средства, блок-схемы, различные языки архитектурного описания (architecture definition language, ADL), такие как UML, ADL и др.

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

3. Программная архитектура, архитектурное описание и процесс разработки ПО – это разные сущности, как с точки зрения теории, так и с точки зрения практики

Программная архитектура – это то, что представляет собой система на концептуальном уровне. Архитектурное описание, относящееся к конкретной архитектуре, может быть выполнено с использованием различных изобразительных средств и нотаций. В этом плане за архитектором оставляется свобода выбора. Конкретный способ описание выбирается исходя из специфики архитектуры и используемого процесса проектирования. Стандарт ISO/IEC/IEEE 42010:2011 только в самом общем виде определяет модель жизненного цикла системы, она определяет точки зрения и виды, но не предписывает использование конкретных видов и точек зрения для описания архитектуры. Следует заметить, выбор той или иной нотации определяется используемым подходом к проектированию. Использование конкретного инструментария проектирования часто предопределяет выбор нотации для архитектурного описания. Например, при использовании Ratinonal Unified Process (RUP) естественным представляется использование UML.

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

В стандарте определяются только базовые принципы и относящиеся к ним активности. Архитектор может комбинировать эти принципы исходя из контекста. В стандарте, в основном используются формулировки типа «по меньшей мере, должно быть», но практически отсутствуют формулировки типы «необходимо иметь» или «должно быть». Например, при определении списка заинтересованных лиц используется формулировка. К основным категориям заинтересованных сторон, как минимум, следует отнести пользователей системы, покупателей, разработчиков и специалистов по эксплуатации. В стандарте отсутствуют какие-либо ограничения по выбору процесса разработки на архитектурном уровне. Можно выбирать типовой процесс или создавать собственный.

Очевидно, что появление данного стандарта не может решить всех проблем архитектурного проектирования. Его следует рассматривать как эталонную метамодель, которую следует использовать для построения моделей более низкого уровня, например, относящихся к конкретным классам ИС [97, 98].

Основные понятия и определения. Основные термины и понятия, связанные с архитектурой информационных и программных систем определены в международном стандарте ISO/IEC/IEEE 42010:2011 [6]. В этом стандарте определены ключевые понятия, связанные с архитектурой, архитектурным описанием, архитектурными фреймворками и архитектурным процессом. В [6] они определяются следующим образом.

Архитектура (architecture) – система фундаментальных концепций или свойств системы, воплощенная в элементах системы, их взаимосвязях, а также в принципах проектирования и развития.

Архитектурный процесс (architecting) определяется как процесс, включающий порождение, определения, документированию, сертификацию, реализацию, сопровождение и модификацию, т.е. архитектурной поддержки системы на всех этапах жизненного цикла. Этот процесс реализуется в рамках конкретной организации и регламентируется такими международными стандартами как ISO/IEC 12207, ISO/IEC 15288.

Архитектурное описание (architecturedescription, AD) – совокупность описаний архитектуры.

Архитектурный фреймворк (architectureframework) – совокупность договоренностей принципов и практик применительно к определенному предметному домену и (или) в сообществе заинтересованных лиц.

Архитектурные виды (architectureview) – описание архитектуры системы с точки зрения отдельных интересов.

Архитектурные точки зрения (architecture viewpoint) – набор соглашений, который определяет способы построения, интерпретации и использования архитектурных видов с целью формирования требуемых концернов.

Интересы (concern) – предмет интереса одной или нескольких заинтересованных сторон. Это относится также к влиянию на систему различных внешних факторов, таких как технологии, экономика, политики, экология и др.

Окружение (environment) – определяют факторы и условия, при которых эти факторы могут оказать влияние на состояние системы.

Вид моделей (modelkind) – соглашения о способе моделирования. В качестве моделей могут выступать, например, сети Петри, UML диаграммы и т.п.

Заинтересованная сторона (stakeholder) – человек, группа людей, организация, которые заинтересованы в системе.

Архитектурное описание системы или класса систем разрабатывается и существует в некотором контексте, структуры которого показана на рис.7.1 [6].


exibits

expresses

1

..*

1

..*

has interests in

situated in

Заинтересованные

стороны (Stakeholder)

Система

(System)

Цель

(Purpose)

Окружение

(Envoronment)

Архитектура

(Architecture)

Описание архитектуры

(Architecture Description)

0

..*

1

0

..*

1

0

..*

0

..*

Система

(System)


Рис. 7.1. Контекст архитектурного описания

Термин Система используется в смысле [12], где этот термин определяется следующим образом «система, которые созданы человеком и которые могут конфигурироваться на уровне аппаратных средств, программного обеспечения, данных, людей, процессов, предоставляющих сервисы людям, процедур, в частности, инструкций для операторов, а также программные системы и сервисы (software-intensive systems)», которые определяются как любая система, в которой программная составляющая является существенной для ее разработки, производства, эксплуатации и модернизации.

На рис.7.2 показано как соотносятся между собой введенные выше понятия. Следует заметить, что стандарт [6] четко различает понятия архитектура и архитектурное описание, при этом в качестве предмета стандартизации выступает архитектурное описание. Если архитектурное описание – это некоторый артифакт или совокупность артифактов, то сама архитектура – это абстракция, включающая в себя концепции и свойства. Стандарт [6] никак не определяет то, какой процесс используется для проектирования архитектуры и не регламентирует состав используемых моделей и нотаций.

Рис. 7.2. Соотношения между основными понятиями

Заинтересованные стороны имеют интересы относительно некоторой системы, несколько заинтересованных сторон могут иметь общий интерес. Интересы появляются на протяжении всего жизненного цикла системы. Интересы могут быть обозначены в разных формах: в форме целей, ожиданий, требований, ограничений, показателей качества, рисков и т.д. Способ описания интересов во многом зависит от системы. Например, свойства программных систем определены в [6].

Отношения между элементами архитектурного описания определяются в терминах соответствия (correspondence), которые, в свою очередь, определяются посредством правил соответствия (correspondence rules) (рис. 7.3).



Рис. 7.3. Правила соответствия

Для объяснения того, почему приняты те или иные архитектурные решения, используются обоснования (rationale). Решения могут касаться, в частности, интересов, изменения характеристик элементов, исключения или включения новых видов и точек зрения и т. п. (рис. 7.4).

Рис. 7.4. Архитектурные обоснования

Архитектурное описаниесопровождает систему на протяжении всего жизненного цикла и может использоваться для решения следующих основных задач: 1) как инструмент проектирования системы; 2) для оценки альтернативных вариантов реализации; 3) при составлении документации; 4) в качестве исходных данных для систем моделирования; 5) для составления спецификаций семейств продуктов; 6) при проведении работ, связанных с переходом на новые архитектуры, и т. д.

Архитектурное описание системы или класса систем разрабатывается и существует в контексте, структура которого представлены на рис. 7.5. Контекст описания системы определяют заинтересованные стороны и окружение системы.
Рис. 7.5. Структура контекста

Архитектурное описание включает один или более архитектурных видов (далее видов). Каждый вид относится к одной или более области интересов заинтересованных сторон. Архитектурный вид описывает архитектуру в соответствии с архитектурными точками зрения. Архитектурная точка зрения включает один или более интересов, при этом каждый из интересов может входить в несколько точек зрения, а также соглашение о видах. Точка зрения определяет вид в соответствии с интересом. Соглашение о видах может включать языки, нотации, виды используемых моделей, правила проектирования, методы моделирования и др. В стандарте [6] предлагается использовать соответствующие виды: «business view», «physical view» и «technical view». Архитектурный вид включает одну или несколько архитектурных моделей, каждая из которых использует соглашения о способе моделирования. Соглашения, в свою очередь, определяются типом модели.

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

В стандарте определяются следующие типовые группы заинтересованных сторон: пользователи (users), операторы (operators), покупатель (acquirers), владельцы (owners), поставщики (suppliers), разработчики (developers), наладчик, изготовитель, специалист по эксплуатации (maintainers). В качестве интересов предлагается рассматривать следующие моменты: цели создания системы, степень достижения поставленных целей, возможность реализации, потенциальные риски заинтересованных сторон на протяжении всего времени жизни системы, простота поддержки и модернизации системы. Описание должно в явном виде связывать интересы с заинтересованными сторонами. Стандарт не определяет такие моменты как уровень детализации при описании интересов и взаимосвязи отдельных интересов, каким образом интересы соотносятся с такими понятиями как цели создания системы, требования пользователей. Эти моменты относят к фреймворкам или конкретным практикам.

Описание каждой точки зрения должно содержать: один или несколько интересов и соответствующих им точек зрения, перечисление типовых заинтересованных сторон, с указанием соответствующих им точек зрения, типы моделей, используемых в точках зрения, при этом для каждой модели определяются; язык, используемые нотации, техника моделирования, описание аналитических моделей, ссылки на источники, содержащие описания моделей.

Архитектурный вид связывается с одной или несколькими моделями, каждая из которых имеет идентификатор версии в рамках проекта или организации. Каждая архитектурная модель принадлежит определенному типу и использует соглашения о способе моделирования, которые определяются типом модели. Для описания типов моделей могут использоваться метамодели. Должно определяться преобразование типа модели в конкретный экземпляр. Совместное использование моделей в нескольких архитектурных видах открывает возможность использования аспектно-ориентированного стиля описания архитектуры. Архитектурные модели можно рассматривать как контейнеры, в которые помещаются архитектурные стили и паттерны. Сам стандарт не предписывает использование тех или иных моделей.

Архитектурное описание должно содержать описание всех соответствий между отдельными элементами, в частности, между моделями, видами.

Для определения соответствия элементы архитектурного описания, в качестве которых могут выступать экземпляры таких классов, как заинтересованные стороны, интересы, точки зрения, виды, типы моделей (кроме того, могут быть введены и другие элементы), описываются с помощью правил соответствия (correspondence rules).

Архитектурные обоснования. Архитектурное описание должно содержать обоснование всех ключевых решений.

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

Архитектурный процесс поддержки системы включает два основных механизма – архитектурные фреймворки и языки описания архитектур (architecture description languages – ADLs). Архитектурный фреймворк в соответствии с [6] показан на рис. 7.6.

Рис. 7.6. Архитектурный фреймворк

Архитектурные фреймворки предназначены, прежде всего, для создания архитектурных описаний конкретных проектов, разработки семейств и линеек продуктов, разработки инструментария архитектурного моделирования как в рамках одной организации, так и многих. Типичными примерами архитектурных фреймворков могут служить Zachman’s Information Systems Architecture Framework, UK Ministry of Defence Architecture Framework, The Open Group’s Architecture Framework (TOGAF), Kruchten’s «4 + 1» view model, Siemens’ 4 views method, Reference Model for Open Distributed Processing (RM-ODP), Generalized Enterprise Reference Architecture (GERA) [99], [100], [101], [102].

Архитектурное описание фреймворка должно содержать следующие элементы: идентификатор фреймворка, идентификаторы одного или нескольких интересов, идентификаторы одного или более пользователей, которые имеют данные интересы, одну или несколько архитектурных точек зрения, которые инкапсулируют интересы, правила, определяющие соответствия. Кроме того, описание фреймворка должно содержать условия его применимости.

Язык архитектурного описания (ADL) (рис. 7.7) – предлагает один (или более) тип моделей для описания области интересов конкретных заинтересованных сторон. ADL отличаются многообразием. Можно выделить специализированные языки, ориентированные на модели одного типа или на поддержку многих моделей, например, такие как UML. Обычно для ADL имеются соответствующие инструментальные средства, с помощью которых можно создавать и анализировать модели. В качестве примера ADL могут выступать такие языки, как UML, Rapide, Wright, SysML, ArchiMate и viewpoint languages of RM-ODP [99] - [111].

Рис. 7.7. Язык архитектурного описания

Язык описания архитектуры определяется через описание следующих элементов: определение одного или нескольких интересов, определение заинтересованных сторон, имеющих данные интересы, определение используемых типов моделей и соответствующих им точек зрения.