Всего на сайте:
166 тыс. 848 статей

Главная | Финансы, Менеджмент

Практики определения системы – архитектура  Просмотрен 146

 

Тема 6. Практики определения системы – архитектура.

Зависимость архитектуры от требований. Бытовой пример построения архитектуры. Работа и компетенции системного архитектора. Инженерия системной архитектуры, стандарт ISO 42010. Архитектурные описания, методы описаний и группы описаний. Синтетический и проекционный подходы. Архитектурные практики. Онтология архитектурных работ. Язык ArchiMate 2.0, его назначение, достоинства и недостатки.

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

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

 

Для иллюстрации того факта, как требования влияют на архитектуру, рассмотрим упрощенный пример – создание системы бытовой музыкальной аппаратуры. Этот пример покажет, как применяется системное мышление, язык системной инженерии к простым бытовым действиям. Как уже говорилось ранее, в системной инженерии мышление «экономится», то есть можно о чем угодно рассказывать с единой точки зрения – системного подхода (о домашней аппаратуре и об атомных станциях). Предположим, что системный инженер решил у себя дома собрать аудиосистему, подключить ее к компьютеру и слушать исполнение музыки. Он идет в магазин и смотрит на имеющиеся решения стоимостью в широком диапазоне. Если качество их звучания удовлетворяет, то цена выше $10000 – уже не очень. Попробуем здесь рассмотреть варианты требований с позиций системной инженерии. Требования к аудиоаппаратуре могут выражаться в значениях следующих параметров: искажения, шумы, диапазон звуковых частот, цена. Заметим, что обычно в конкретных проектах создаваемых систем цена и сроки – для системного инженера выходные параметры, хотя, конечно, он вычисляет цену и стремится ее снизить. Мы же сейчас рассматриваем специфический пример (покупка и сборка готового изделия), поэтому цена – тоже требование, входной параметр. Перечисленные выше характеристики и требования к ним хороши, то есть вполне определяют конечный результат. Однако у покупателя могут быть и более «лирические» пожелания: «теплый звук», «прозрачный звук», Hi-Fi, Hi-End. Требование может быть и таким: «я хочу слышать музыку так же, как ее слышал и записал звукооператор». Последнее означает, что покупатель должен, например, взять аппаратуру звукооператора и установить ее у себя. Но в бытовом магазине такой аппаратуры нет. Какие требования могут быть к аппаратуре у звукооператора? – Очевидно, что они направлены к тем же параметрам (искажения, шумы, диапазон частот, цена). Однако ему не до «лирики», у него нет требования «прозрачный звук». Означает ли это, что ему нужен звук худшего качества? – Нет, ему нужен звук лучшего качества!

 

Рассмотрим, к чему стремятся производители аудиоаппаратуры и насколько это по-разному решается в бытовом и профессиональном аудио. Если требуется передать сигнал по кабелю от одного устройства другому, то для этого используется некоторое электрическое напряжение. В бытовой аппаратуре оно составляет примерно 2,5в, в профессиональной – 6в. При разработке бытовой аппаратуры производители борются с фоновым шумом, шипением и т.п. Значительная часть шума порождается электрическими «наводками» из окружающей среды. При напряжении 2,5в борьба с шумами обходится дорого. Используются дорогие кабели, экранирование, и эта цена включается в общую стоимость аппаратуры. В то же время в профессиональной аппаратуре (для звукооператора) такой проблемы практически нет, поскольку принято другое архитектурное решение – напряжение 6в. Наводки составляют примерно 0,5в и полностью «забиваются» полезным сигналом, т.е. соотношение полезный сигнал/шум достаточно высоко. Далее предположим, что все происходит в условиях, «приближенных к боевым», например, в автомобиле. Там работает зажигание, оно искрит, мимо проносятся опоры с электричеством, троллейбусы и требуется, чтобы наводок от них не было слышно. Чтобы удовлетворить новым требованиям, производители снова меняют архитектуру. Интерфейсный стандарт напряжения для передачи сигнала в описанных условиях – 17в. При таком напряжении помех практически не слышно. Вопрос: насколько это дороже? – Ответ: это дешевле. Кабели используются дешевые, с большим диаметром, отсюда даже повышается площадь (и надежность) контактов. Чем меньше напряжение, тем дороже кабель, который должен быть еще и экранированным.

 

Выбор архитектуры не ограничивается напряжением. Дело в том, что дорогие кабели являются одновременно и фильтрами, «срезающими» некоторые частоты, чтобы звук становился приятнее (Hi-Fi, Hi-End). Это тоже пример архитектурного решения в дорогой бытовой аппаратуре.

Однако в любой кабель достаточно было бы встроить короткий участок дорогого или вообще добавить 2-3 дешевых фильтра, и тогда результат будет аналогичным. Таковы архитектурные решения, зависящие от различных стейкхолдеров. Есть люди, которые хотят, чтобы у них был Hi-Fi или Hi-End. И архитекторы борются инженерными методами с ненужными частотами, создают деревянные корпуса и т.п., в результате чего стоимость аппаратуры достигает десятков тысяч у.е. С другой стороны, в аудио есть профессиональные люди, у которых другие требования. Им нужно как можно дешевле обеспечить хорошее (истинное) качество передачи (а не восприятия) сигнала. И это сделать просто – пойти в другой магазин, купить более дешевую аппаратуру – профессиональную, на другом стандарте (с повышенным напряжением, толстым недорогим кабелем). При этом получится тот же звук, что у звукорежиссера. Требования другие – архитектура другая, решения другие. В бытовой технике существует весьма дорогое устройство – предварительный усилитель, имеющий много входов. Он «собирает» много различных аудиоустройств и компьютеров. Однако вместо него можно купить за $100 профессиональное устройство, которое выполняет не меньше функций (но не в бытовом магазине, а в профессиональном). И в нем практически не слышен шум. А как же при этом быть с «теплотой звучания»? Она постепенно превращается в психологическое явление, поскольку большинство людей при «слепом» сравнительном прослушивании при потоке 192кбит/сек практически не обнаруживают отличий Hi-Fi от CD. А если поток составляет 320 кбит/сек, то этого не отличает никто.

 

Почему же аналогичным образом не поступают производители бытовых аудиосистем? Потому что в этой области свои требования, интерфейсы, стандарты, унаследованные системы, рынки, брэнды, маркетинг. Например, если перейти на 6в-интерфейсы, то невозможно будет оправдать высокую стоимость аппаратуры. Есть люди, которые требуют приятного звука (в том числе соответствующую запись на бумаге), и на них работает аудиопромышленность с ее огромными масштабами. Там функционирует множество архитекторов, каждый из которых изобретает что-то свое. Подводя итог, можно сказать, что рассмотренные с самого начала параметры (искажения, шумы, диапазон частот) вторичны. Хороший инженер по требованиям в данной задаче может выделить первичные (и противоречивые) требования – приятный звук или истинный звук. Приятный звук свойственен бытовой аудиосистеме, истинный – профессиональной аппаратуре.

 

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

За отдельные части конструкции отвечают инженеры по специальностям. Если требования определены (в результате колебательных движений вдоль левой части буквы V), системный инженер-архитектор должен найти (или изобрести) прием, как реализовать конструкцию, как ее упростить и облегчить. Например, новый компьютер может быть очень похожим на предыдущую версию, но весить на 300г меньше за счет того, что жесткий диск, графику и часть портов вынесли в отдельную dock-станцию весом 600г. Вместе с ней он тяжелее, но многим людям на выезде это все не требуется. Для показа презентации, чтения лекции достаточно, например, одного USB-порта. Таково архитектурное решение системных инженеров: одну конструкцию разбить на 2 модуля, сделав между ними интерфейс с оптическим кабелем (нужно передавать графику). Архитектор придумывает, как удовлетворить требованиям. Инженер по требованиям этого не делает, он требования находит и систематизирует. Проводя исследования рынка, он может выявить, что снижение веса при каждодневном использовании компьютера важнее продвинутой графики, которая может использоваться не всегда. Архитектор изобретает, что нужно сделать в ответ на такие требования. Такой способности нужно учиться, причем в конкретной предметной области. Для этой цели нужно также обладать воображением, уметь моделировать, знать имеющиеся решения, патенты и т.д. В этом состоит некоторая «поэзия» работы архитектора.

 

Далее перейдем к «прозе» системной архитектуры. Напомним, что выделяют 3 поколения инженерии. Первое поколение – это когда пришел инженер по требованиям к архитектору, они поговорили, и последний, например, в PowerPoint создал презентацию архитектуры. Современная инженерия работает в основном со специальными диаграммами, которые можно интерпретировать как «псевдокод» (фактически – запись алгоритма).

 

Инженерия нового поколения основана на формальных моделях, она использует алгоритмические языки и вычисляемый код. Если есть описание системы, даже на верхнем архитектурном уровне, то можно запустить программу (упомянутый код) и породить более подробное описание – например, настроить задачи предметных инженеров. Другими словами, запустив код, можно сгенерировать новые артефакты, например, текст на другом языке, который будут использовать последующие специалисты (далее по жизненному циклу). Это есть подход model-based. Данное обстоятельство иллюстрирует ту закономерность, что в последние годы в системную инженерию многое приходит из программной инженерии. Однако приходят не последние идеи, а с запозданием лет в 15. Одним из примеров служит UML (вспомним SysML – язык системной инженерии).

Классическим считается высказывание об архитектуре одного из известных специалистов в области объектно-ориентированного проектирования – Ральфа Джонсона.

 

 

Рассмотрим еще раз схему Дитца, с точки зрения архитектуры. Напомним, что терминология здесь немного отличается от той, которую мы использовали ранее. Как уже говорилось, существуют using system construction (это система в системном окружении, system in operation environment, слева). То есть имеется большая система, в которой функционирует целевая система. Прежде всего, требуется сообразить, зачем она (целевая система) нужна. Все требования («приятный звук», «истинный звук» и т.д.) приходят из окружающей системы. В рассматриваемом смысле все требования функциональны. Есть также object system construction (то есть целевая система, system of interest, справа). В ней есть нечто основное – основные элементы устройства, онтология – то, что мы о ней знаем.

 

 

Вообще ontology – это перечисление всего, из чего состоит мир (или его часть), т.е. относится к конструкции. В мире есть стол, человек, компьютер и т.д., что бы это ни значило – это онтологические ответы.

Когда мы смотрим на охватывающую систему (слева) или на целевую (справа), то в соответствии с онтологией рассматриваем, из чего она состоит, находим, в каких терминах ее можно описывать. Слово онтология здесь неслучайно, и задача онтологического описания непроста. Например, архитектура предприятия описывается своей онтологией, и там есть такие термины, как прибыль, процессы и т.п. Если же прийти на предприятие, то невозможно сразу увидеть прибыль или некоторые процессы, хотя все это – часть онтологии. Кроме того, на схеме Дитца онтологии изображены стопкой листов. Это означает, что онтологий у одной и той же системы много, поскольку разные специалисты по-разному рассматривают систему (как использующую, так и целевую), описывают ее с различных точек зрения. Для использующей системы выполняется reverse engineering (она изучается, исследуется, восстанавливается), для целевой – просто engineering (она разрабатывается). Архитектура связывает принципы конструкции с функцией.

 

Далее рассмотрим стандарт ISO 42010. Он посвящен описанию архитектуры в системной и программной инженерии. Его можно изобразить следующей обобщенной схемой, содержащейся в его оригинале.

 

Итак, есть сторона (stakeholder), заинтересованная в системе (system) и у системы – архитектура (architecture). Эта архитектура имеет архитектурное описание (architecture description). Заметим, что архитектурных описаний может быть сделано несколько, различными архитекторами. Обобщенно можно считать, что оно одно. Система функционирует в ее окружении (environment). Заинтересованная сторона имеет к системе интерес (system concern), выраженный в виде ее цели, назначения (purpose). Как видно из схемы, этот посвященный архитектуре стандарт попутно рассказывает азы системного подхода. Основная часть стандарта – это правая верхняя часть схемы. Не следует путать архитектуру с архитектурным описанием. Архитектура – это идеи, принципы конструкции (они нематериальны). Архитектурное описание – это рабочий продукт (артефакт, материален), выражающий (представляющий) архитектуру. Аналогично в программировании различаются алгоритм и его запись.

 

Ниже представлена основная диаграмма стандарта ISO 42010. Она весьма значима, поскольку содержит все важнейшие понятия современного архитектурного подхода. Диаграмма содержит в качестве подмножества все элементы предыдущей схемы. В ее начале изображена system of interest, с ней связана архитектура, которая ее (систему) характеризует и имеет описание. У системы есть заинтересованная сторона со своими заботами (интересами). Напомним, что стейкхолдер – это не «Иван Иванович», а культурно-обусловленная позиция. Это человек (рассматриваемый в позиции – предприниматель, охранник окружающей среды, …), явление, документ и т.п., который имеет конкретные интересы по отношению к системе.

 

 

Далее изображены модули architecture viewpoint и architecture view. Как считают разработчики этого стандарта, их главное достижение – в разделении view и viewpoint. Эти слова не переводятся здесь на русский язык посредством словаря, поскольку имеют специальное терминологическое значение. Под view подразумевается представление – группа описаний (собственно описания). Попутно заметим, что и присутствующее на схеме слово model переводится как «описание». Его можно перевести как «модель», только если речь идет о моделе-ориентированной системной инженерии. Группа описаний (architecture view) включает (группирует в себе, обратите внимание на символ UML-нотации) несколько архитектурных описаний (architecture model) – например, «фас» и «профиль». И все это – основная вертикальная линия, ведущая вверх к architecture description (будем обозначать так, чтобы не путать с описанием – model) и собственно архитектуре. Другой пример: группа описаний может быть одна – финансовая, но содержать две модели (описания) – баланс и отчет о прибылях и убытках, дополняющие друг друга. В одной группе описаний имеются разные описания. То, что хорошо видно в одном описании, может быть малоинформативно в другом. В рассматриваемом контексте viewpoint – это метод описания, в котором перечислены виды моделей (т.е. описаний). Каждому виду описаний соответствует (горизонтальная линия) его представитель, экземпляр – описание.

 

Architecture description состоит из методов описаний и групп описаний. Группа описаний определяется (объединяется) тем, что у нее общий метод. Работая над системой, необходимо ответить на чей-то интерес, понять, чей он и каков. Далее – придумать ответ и выбрать метод записи ответа. Если метод записи выбрать не удается, его надо придумать. Стандарт требует, чтобы для каждой группы описаний был указан метод описания, для каждой модели описания был указан ее вид. Предположим, что необходимо описать модель. Берут некоторый язык программирования Z и описывают систему в виде псевдокода или исполняемого кода. В соответствии с требованием стандарта нужно указать метод, т.е. этот язык Z. Если язык придуман заново, то его (этот viewpoint) необходимо полностью описать и приложить к architecture description. Заметим, что на практике это требование выполняется редко.

 

Кроме перечисленного выше, в архитектурное описание входят наборы correspondence rule и correspondence. В стандарте говорится, что могут быть соответствия между отдельными описаниями, а также между группами описаний. Например, описание «прибыль» в одной модели может соответствовать описанию «убыток» в другой модели; выход одной модели может соответствовать входу другой модели. Это есть соответствия (correspondences) и определяющие их правила соответствий (correspondence rules). Наконец, architecture rationale – это архитектурные обоснования, поскольку архитектуру необходимо обосновывать.

 

Для иллюстрации вспомним пример с бытовой аудиотехникой, когда создается домашняя аудиосистема с хорошим звуком. В качестве основного требования выбирается «приятный звук» или «истинный звук». Требуется описать архитектуру такой системы.

Рассмотрим, какие группы описаний там могут появиться. Согласно основной диаграмме ISO 42010, необходимо выявить заинтересованные стороны и их интересы. К стейкхолдерам, например, относятся соседи, семья (тоже в некотором роде соседи), различные продавцы, которые перед покупкой будут высказывать аргументы в пользу своего товара. Один из интересов покупателя – финансовая сторона. Можно изобразить таблицу цен – компоненты, цены-max, цены-fact, итого. Структура такой таблицы представляет метод описания, поскольку она порождает множество описаний: таблицу с конкретными компонентами и ценами можно применять в различных ситуациях. Возможно, это не лучший метод, поскольку, например, цены-fact станут известны лишь на заключительных этапах жизненного цикла рассматриваемой системы. Но это хороший способ создать архитектуру с возможностью проверки соответствия системы некоторым требованиям. Это артефакт, который можно использовать на стадии тестирования, поскольку там есть графа для проверки стоимости. В инженерии существует даже такой архитектурный метод, когда от любого описания требуется применимость при тестировании. Это не однозначно хороший метод, поскольку описание архитектуры и артефакт для тестирования – разные вещи и их совмещение не обязательно окажется естественным.

 

Кроме финансовой, есть, по-видимому, техническая группа описаний. В нее могут входить схемы соединений устройств: компьютер, микшерский пульт, колонки (две или более) и т.д. Для желающих петь можно добавить еще микрофон. Сами конкретные схемы – это отдельные описания, но не их вид или метод. Вид описания – это абстрактная схема, при этом нужно указать роль каждого обозначения. Если заданы все виды описаний, то их совокупность представляет собой метод. В противном случае наше архитектурное описание (оно, безусловно, им является) будет составлено не по стандарту ISO 42010. Описание, сделанное по стандарту, имеет значительно большие шансы однозначного понимания различными людьми, а значит, увеличиваются шансы на успех проекта. Наряду с упомянутыми группами описаний, может быть еще одна – группа спецификаций. Ее также можно задать в форме таблицы: свойство (напряжение коммуникаций), значение (6в), стандарт (которому оно соответствует – Европа, Америка и т.п.). Здесь свойство и значение – это собственно описание, а стандарт – способ, т.е. вид описания. Кроме самих описаний, в нашей архитектуре нетрудно увидеть и зафиксировать их соответствия. В частности, каждое устройство присутствует как в таблице цен, так и на схеме соединений.

 

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

 

Существуют 2 способа конструирования описаний (view) – синтетический и проекционный. Если независимо подготовлены различные группы описаний, а затем на них устанавливаются (синтезируются) соответствия (например, в таблице цен и на схеме соединений выделяются общие позиции – устройства), то это синтетический способ. Если же вначале выделены соответствия (например, в базе данных или репозитории хранятся уникальные устройства), а затем с учетом этих «соответствий» заполняются (проецируются) различные виды описаний (таблица цен и схема соединений), такой способ считается проекционным. На практике они используются оба, каждый имеет свои достоинства и проблемы, но имеется современная тенденция движения от синтетического к проекционному. Например, изначально может использоваться проекционный способ, который кажется более естественным и прогрессивным. Но в процессе развития системы каждое описание реализуется различными специалистами, и может произойти рассогласование моделей. С целью контроля этого процесса и собираются конфигурации (baselines, см. Лекцию 3), причем данный процесс напоминает синтетический способ построения архитектуры. В фирмах, где PLM-системы строго поддерживают проекционный подход, возникает гораздо меньше проблем с управлением конфигурациями. Здесь нетрудно увидеть аналогию с нисходящим и восходящим проектированием компьютерных программ (нисходящий подход побеждает).

 

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

Такая повторяемая часть обозначается как architecture framework, что в данной ситуации можно перевести как «архитектурный подход». Он состоит из методов описания и может включаться в различные architecture descriptions. Остальное содержимое схемы уже рассмотрено в рамках предыдущей диаграммы. Архитектурные подходы называют также онтологическими, поскольку они говорят о том, из чего устроен мир, содержат терминологию (методы описаний). Известно, что существует множество подобным образом оформленных подходов. Их создание регламентируется некоторыми зарубежными министерствами (например, военными) с целью стандартизации описаний. Эта работа занимает много времени, но польза от архитектурных фреймворков не так велика, поскольку они редко оказываются повторно востребованными. Тем не менее, они полезны в целях обучения системных инженеров-архитекторов.

 

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

Далее рассмотрим «горбатую» диаграмму архитектурных практик. Она отражает методологический подход к построению архитектуры (MFESA – Methodology Framework for Engineering of System Architectures). Методология разработана Дональдом Файерсмитом (Donald Firesmith) и впервые опубликована в 2008г. Практики он назвал задачами (Tasks). Напомним, что «горбатая» диаграмма – это таблица, в которой по горизонтали расположены стадии жизненного цикла, по вертикали – практики. В клетках таблицы графически отображаются необходимые объемы ресурсов.

Диаграмма MFESA содержит только архитектурные практики, при этом – все стадии типового жизненного цикла системы (с некоторыми модификациями в названиях). Отметим, что здесь не выделяется стадия жизненного цикла, называемая «архитектура». «Архитектурные» усилия (в виде практик) предпринимаются на протяжении всего жизненного цикла системы. Кратко рассмотрим каждую из практик – задач.

 

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

 

 

Следующая задача – идентификация возможностей переиспользования архитектурных элементов. Это важнейшая архитектурная практика, означающая поиск готовых архитектурных решений (стандарты, литература), чтобы не изобретать велосипед. Задача начинается несколько позже предыдущей (сначала нужна исходная идея или ее часть), но завершается на тех же, ранних, стадиях. Пятая задача – создание кандидатур архитектурных видений (представлений). Архитектурное видение – это некая общая картина архитектуры, обзор архитектуры, в противовес последующему разбиению на отдельные модели-описания, чтобы «за деревьями увидеть лес». Очевидно, что и эта задача должна решаться на стадии «придумывания» системы. Шестая задача – анализ повторно используемых компонент архитектуры и их источников (откуда их можно взять). Часто решения в одной отрасли переходят в другую отрасль (вспомним инженерию ситуационных методов от Richard J. Mayer – Лекция 3). Данная задача решается в ограниченное время между стадиями задумывания и конструирования системы.

 

Следующая задача – выбор или создание наиболее подходящего архитектурного видения. Если это выбор, то делается из результатов задачи 5 («прохождение развилки»). Судя по диаграмме, данная задача решается быстро в заключение стадии придумывания системы, однако она весьма важна для архитектуры. Восьмая задача – завершение и дальнейшая поддержка (обновление) архитектуры. Она требует внимания на протяжении всего жизненного цикла, причем наиболее интенсивного – на начальных стадиях. Следующая – оценить и принять архитектуру, еще одна практика, выполняемая другими людьми. Она, очевидно, решается на всех стадиях, по мере развития и обновления самой архитектуры. Еще одна – десятая задача состоит в проверке целостности архитектуры («архитектурный надзор»). Она не занимает больших объемов ресурсов, но требует постоянного внимания.

 

Заметим, что на диаграмме речь идет об архитектуре, а не ее описаниях. Как уже говорилось, архитектура первична, а ее описание – вторично. Оценивая диаграмму целиком, можно сказать, что, по версии Дональда Файерсмита, основная работа над архитектурой системы выполняется на стадии задумывания (Initiation) и частично конструирования (Construction). Рассмотренная диаграмма содержит практики, выполняемые системными архитекторами.

 

На следующем слайде представлена онтология архитектурных работ (по версии MFESA), показывающая все их многообразие. Архитектура – это абстракция системы. Рассмотренный ранее стандарт ISO 42010 лишь регламентирует общие положения, и, очевидно, может считаться лишь «бледной копией» в сравнении с такими масштабами. На слайде изображена также книга Д. Файерсмита с несколькими соавторами, где подробно изложен подход MFESA.

Далее поговорим об ArchiMate (2.0 – версия 2012г.). Это язык архитектурных описаний для предприятий в соответствии с ISO 42010. Согласно его (проективному) подходу, есть пирамида (иерархия) понятий, в терминах которых рассматривается предприятие.

Вверху – наиболее общие понятия, внизу – наиболее специфичные. Верхняя часть задает онтологию, в которой нет ничего от предприятия – generic concepts (сущности и отношения). Средняя часть отражает общую терминологию предприятий (например, программа, процесс). Нижняя часть описывает специфику конкретного предприятия. Язык ArchiMate предназначен для информационного моделирования предприятий. Далее представлен полный набор понятий, содержащихся в языке. Левая колонка – объекты работы (внизу – виды связей и их обозначения), следующая – работы/практики, третья – кто/что работает.

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

 

Аргументы, поддерживающие выбор ArchiMate, таковы.

1. Позволяет учитывать работу людей (можно описать организацию –деятельность людей), а также и оборудование. В ArchiMate 2.0 добавлена возможность описать также требования к архитектуре организации, и проекты по воплощению архитектуры.

2. Это архитектурный язык (его онтология: набор типов и отношений), содержащий также архитектурный подход (набор групп описаний). При этом он проще, чем UML и SysML.

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

4. Содержит элементы сервис-ориентированности – системного подхода.

 

Перечислим также некоторые аргументы против выбора ArchiMate.

1. В языке нет понятия «система» как такового. С другой стороны, система легко моделируется – есть множество способов показать функцию, конструкцию, поведение, подчеркнуть модульность. Со второй версии можно некоторым образом показать и жизненный цикл архитектуры, описать ее изменения по ходу реализации или модификации.

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

3. Невыразимы workflow («детальные процессы»), требуется дополнительно использовать BPMN 2.0 – специальное средство моделирования бизнес-процессов.

4. Невыразимы ситуационные методы (требуется SPEM 2.0 или ISO 24744).

5. Невыразима детализация данных (нельзя моделировать данные).

6. Софт Archi будет иметь возможность подключения генератора отчётов общего вида только в перспективных планах.

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

 

Предыдущая статья:Практики определения системы – требования Следующая статья:Системы систем. Организационная инженерия
page speed (0.0103 sec, direct)