Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
186 |
https://openmodelica.org/):
На сегодня активно развиваются компьютерные методы не только «проверочных архитектурных расчётов», но и методы оптимизации (выбора оптимальной архитектуры, т.е. оптимального набора компонент и реализующих их модулей).
Из языков архитектуры предприятия рекомендуется ArchiMate 2.0: стандарт — http://pubs.opengroup.org/architecture/archimate2-doc/, свободный моделер — http://www.archimatetool.com/, лучшая книжка вот тут: http://masteringarchimate.com/mastering-archimate-edition-ii/. Есть русский перевод терминологии: http://ailev.livejournal.com/988360.html
Тут нужно бы обсудить и product lines (например, подход для software product line practice, версия 5 — http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm), и светлое будущее (поиск-ориентированная инженерия и т.д. — http://ailev.livejournal.com/1122876.html), но они для нашей книги факультативны.
Минимальная архитектура
Минимальная архитектура состоит из трёх определений (и, соответственно, трёх тематических описаний — наборов рабочих продуктов/моделей):
●структуры компонент и соединений (чаще всего — принципиальной схемы, иногда просто функциональной декомпозиции). Эту часть архитектуры также называют “логической архитектурой”.
●Структуры модулей (определяемых их интерфейсами, а часто и физической декомпозицией). Эту часть архитектуры называют также “физической архитектурой”.
●Указаний на размещение частей системы в пространстве.
Обратим внимание, что архитектура должна чётко показывать, как увязанные между собой все эти три вида описаний (иногда говорят о “стилях описаний”, а не “видах описаний”) “прозрачного ящика” дают на выходе основные функции системы. Тем самым архитектура неразрывно связана с требованиями. Те требования, которые максимально влияют на архитектуру, называют архитектурными требованиями.
Чаще всего разработка начинается с предложения принципиальной схемы, или функциональной декомпозиции (“логической” схемы) и проведения необходимых мультифизических расчётов (в том числе с учётом киберфизической составляющей: часть физических характеристик может быть обеспечена активным компьютерным управлением). Потом делается попытка определить то, как компоненты будут реализованы теми или иными модулями — которые можно купить, или которые придётся разработать. Часто выясняется, что предполагаемые принципиальной схемой модули трудно реализовать (их нет на рынке, их трудно спроектировать и изготовить и т.д.). Тогда принципиальная схема меняется, и делается очередная
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
187 |
попытка разобраться с модулями оборудования и деталями. И так до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой.
Субъективность и относительность архитектуры.
По поводу архитектуры субъективность проявляется во многих аспектах. Так, архитектура у системы есть всегда — но если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта. Если предложить разным системным архитекторам спроектировать какую-то систему, то разные системные архитекторы также предложат разные архитектуры — но в данном случае они их “придумают”, а не “выявят”. Более того, один и тот же системный архитектор (или команда системных архитекторов) не только могут, но и должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры, выбор разных модулей для реализации компонент, разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как trade-off studies (перевод порусски тут немного нетрадиционен: “прохождение развилок”) — часто готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
Субъективность архитектурных решений проявляется и в том, что где заканчиваются архитектурные (важные) решения, а где начинается конструкторская и проектировочная рутина, не затрагивающая систему в целом знает только системный архитектор — никаких на этот счёт рекомендаций, стандартов, учебников нет. На диаграмме наверху это показано как градиентная размывка решений: число переделок, требуемых при изменении решений плавно
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
188 |
уменьшается так, что чёткой границей архитектурной и неархитекторной части проекта провести нельзя.
Относительность архитектурных решений заключается в том, что “неархитектурные решения” для системного архитектора надсистемы могут быть “архитектурными решениями” системного архитектора подсистемы (для этого архитектора это ведь будет не “подсистема”, а целевая система). Так, архитектура авиадвигателя является таковой только для архитектора авиадвигателя. Для архитектора самолёта все решения внутри двигателя (например, как устроены форсунки реактивного двигателя) не архитектурны, архитектурен только выбор модуля двигателя — если выберется не реактивный двигатель, а поршневой, то придётся менять довольно много конструкторских решений для всего самолёта.
Так что критерий, где остановиться системному инженеру, спускаясь по отношениям часть-целое в структуре системы прост: останавливайтесь там, где вы
●дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений.
●уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения.
Архитектурные описания
Архитектура выражается в архитектурных описаниях (рабочих продуктах). Вот диаграмма из ISO 42010, демонстрирующая связь архитектуры и архитектурных описаний:
Замечания по переводу: очень часто view и viewpoint переводят как “аспект”, но это не совсем верный перевод (тем более, что он не позволяет различить само
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
189 |
описание, выполненное для какого-то аспекта — view, и знания о том, как делать такие описания — viewpoint). View — это то, что видишь. Viewpoint — это та точка, из которой видно то, что видишь. Видишь обычно много разного (разных моделей), объединённого тематикой: описания требований, архитектуры, финансовые описания, физические описания, описания безопасности и т.д.
Как объединять разные модели и группы описаний
Correspondence rule — это правила соответствия элементов в разных моделях, они определяют конкретные соответствия (например, правила соответствия компонент и модулей в инженерной группе описаний. Эти правила определяют набор конкретных соответствий компонент и модулей в данном проекте).
Всё, что говорится про архитектуру и архитектурные описания, верно для двух подходов к конструированию групп описаний из отдельных моделей (диаграмм, наборов формул и т.д.):
●Синтетический подход — когда отдельные модели (например, диаграммы) являются именно отдельными моделями, но к ним добавляется список соответствующих друг другу элементов (”насос-1 на принципиальной схеме реализуется модулем “наклонный жёлоб” на чертеже”).
●Прожекторный (проекторный) подход — когда вся необходимая информация разных моделей содержится в общей базе данных (иногда говорят “интеллектуальной информационной модели”, “цифровом макете”, “цифровой модели” и т.д.), а отдельные модели получаются отфильтровыванием нужной информации из общего хранилища — примерно так, как из белого цвета в проекторах и прожекторах получают нужные цвета, используя цветные фильтры-плёнки.
Эти два подхода логически эквивалентны.
Архитектурные модели и другие виды описаний
Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. Некоторые авторы пытаются даже сказать, что если это не архитектурные модели, то диаграммы и тексты не должны входить в состав архитектурного описания. Но это не так: в архитектурных описаниях, конечно, могут присутствовать и не-модели, например:
●Архитектурные текстовые эссе оказываются очень полезными для краткого описания того, что было положено в основу моделей архитектурных описаний (выбор метода моделирования), краткого обзора архитектуры в целом как совокупности моделей. Эти же эссе могут быть использованы для пояснений того, как именно были связаны архитектурные модели, а также особенностей моделирования.
●Инфографика (а хоть и слайды в PowerPoint) может показать основные архитектурные идеи для не-инженеров (менеджеров, заказчиков, пользователей) — ибо формальные модели могут быть для них непонятны.
В архитектурные описания обязательно входят ещё и архитектурные обоснования (резоны, по которым были приняты те или иные архитектурные решения — architecture rationale).
Тем самым архитектурные описания — это документированные (в том числе в