Архитектура ИС 2014 весна Понятия и определения

Архитектура ИС 2014 весна

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

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

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

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

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

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

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

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

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

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

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

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

• Термин Система используется в смысле [ISO/IEC 15288 ], где этот термин определяется следующим образом «система, которые созданы человеком и которые могут конфигурироваться на уровне аппаратных средств, программного обеспечения, данных, людей, процессов, предоставляющих сервисы людям, процедур, в частности, инструкций для операторов, а также программные системы и сервисы (software-intensive systems) [ISO/IEC 12207]» , которые определяются как «любая система, в которой программная составляющая является существенной для ее разработки, производства, эксплуатации и модернизации [IEEE Std 1471: 2000].

На рис. показано как соотносятся между собой введенные выше понятия

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

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

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

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

• В стандарте ISO/IEC 25010: 2011 не используются такие термины как “business architecture”, “physical architecture”, and “technical architecture” вместо них предлагается использовать соответствующие виды: “business view”, “physical view” и “technical view”, соответственно.

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

• В качестве примитивов при составлении архитектурного описания могут выступать такие элементы архитектурного описания как заинтересованная сторона, архитектурный вид, тип модели, архитектурные модели архитектурные решения (architecture decision) и обоснования (rationale).

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

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

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

. • Архитектурные фреймворки и языки описания архитектур (architecture description languages, ADLs) – это два основных механизма архитектурного процесса

В 42010 архитектурный фреймворк определяют как общепринятую в рамках конкретного предметного домена и (или) профессионального сообщества практику создания, интерпретации, анализа и использования архитектурных описаний

• Архитектурные фреймворки предназначены, прежде всего, для создания архитектурных описаний конкретных проектов, разработки семейств и линеек продуктов, разработки инструментария архитектурного моделирования как в рамках одной, так и многих организаций.

• Типичными примерами архитектурных фреймворков могут служить 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), [ISO/IEC 10746], Generalized Enterprise Reference Architecture (GERA) (ISO 15704)

Язык архитектурного описания • – это форма представления архитектурного описания. ADL предлагает один или более тип моделей для описания области интересов конкретных заинтересованных сторон. ADL отличаются многообразием. Можно выделить узко специализированные языки, ориентированные на модели одного типа, или ориентированные на поддержку многих моделей, например, такие как UML. Обычно для ADL имеются соответствующие инструментальные средства , с помощью которых можно создавать и анализировать модели. • В качестве примера ADL могут выступать такие языки как UML, Rapide, Wright, Sys. ML, Archi. Mate и viewpoint languages of RM-ODP (ISO 10746).

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

Заинтересованных стороны. • Стандарт ISO/IEC 25010: 2011 определяет следующие типовые группы заинтересованных сторон: пользователи (users), операторы (operators), покупатель (acquirers), владелец (owners), поставщик (suppliers), разработчик (developers), наладчик, изготовитель, специалист по эксплуатации (maintainers).

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

Стандарт не определяет • такие моменты как уровень детализации при описании интересов и взаимосвязи отдельных интересов, каким образом интересы соотносятся с такими понятиями как цели создания системы, требования пользователей. Эти моменты относят к фреймворкам или конкретным практикам.

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

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

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

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

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

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

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

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

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