Модульные/продуктные/конструктивные описания
Когда ролевой/деятельностный/трудовой предмет интереса относится не ко времени работы системы, а ко времени построения системы --- модульного синтеза, закупки конструктивных частей/продуктов/модулей/изделий/блоков, сборки системы из закупленных конструктивных частей, отгрузки получившейся системы-продукта, то необходимо использовать модульные/конструктивные/продуктные описания. Эти описания отвечают на вопрос «как сделана система» (ср. с функциональным «как работает система»: это design-time против run-time. Помним, что в design-time мы включаем не только проектирование, но и изготовление, или модернизацию, и уничтожение. Но не включаем время работы/operation/функционирования).
На продуктных/конструктивных/модульных диаграммах показываются модули (modules), соединяемые через интерфейсы (interfaces, буквально --- «междумордия», «то, что между»). Интерфейс обычно описывается каким-то стандартом, описывающим как свойства соединения, так и события, происходящие в ходе взаимодействия модулей через соединение. Принято говорить о сборке модулей для их взаимодействия через интерфейсы как об интеграции. Описывающие двустороннее взаимодействие стандарты называют протоколами.
Интерфейсы модулей похожи на порты функциональных частей в том плане, что это именно места присоединения, то есть интерфейсы не конструктивные элементы, они не занимают объёма в пространстве, хотя у них и может быть форма. Вилка и штепсель, гнездо и штеккер, кабель USB и гнездо USB: интерфейс --- это то, что между ними. А сам физический конец кабеля, оформленный в соответствии со стандартом, сам разъём в компьютере, если речь идёт о USB? Это интерфейсный модуль, главное назначение которого --- реализовать какой-то интерфейс в физическом мире. И у этого модуля не один интерфейс обычно, а два интерфейса: один целевой, а другой --- присоединяющий его к какому-то модулю, для которого нужен целевой интерфейс. Это очень частая ошибка: путать интерфейс и интерфейсный модуль. Не делайте эту ошибку (а студенты не удивляйтесь отсылке на пересдачу, если вы не дочитали до этого места и называете интерфейсом какую-то часть конструкции). Скажем, мембрана клетки --- это интерфейс клетки с окружающим миром, или интерфейсный модуль? Поскольку мембрана состоит из молекул, занимающих пространство-время, то это модуль. Мембраны, корпуса --- это интерфейсные модули с окружением, а не интерфейсы! У них по два интерфейса: внутрь системы и вовне системы.
Вот пример такого интерфейсного модуля (который в просторечии называют USB-интерфейс, что неверно --- у него есть ещё и сигнальный интерфейс к плате, и отдельный интерфейс к питанию и даже интерфейс к человеку: светодиод, который мигает, когда идёт передача данных и кнопка включения, а ещё есть механический интерфейс крепления к корпусу или другой плате):
А как же соединения, которые нужны для работы --- все эти трубы, кабели, волноводы? Это тоже модули/продукты/изделия/артефакты, и у них есть свои интерфейсы: они находятся между ними и теми модулями, которые они соединяют. Что проходит через эти интерфейсы, и как оно связано с работой всей системы?
Неизвестно, ибо речь идёт о конструктивных единицах в design-time: функции из run-time тут не определить, для этого нужно выходить за пределы модульного описания в область инженерных решений по реализации функциональных частей системы конструктивными её частями.
Большинство инженерных решений как раз о том, роли каких именно функциональных частей будут играть те или иные конструктивные части/модули, какие между этими конструктивными частями будут интерфейсы, и через эти интерфейсы какие будут выполняться сервисы, соответствующие функциям функциональных частей. Помним: со стороны системы ожидаются от подсистемы как функциональной части выполнение функций, а со стороны подсистемы как конструктивной части для системы ожидается выдача сервиса через интерфейс.
Часто речь идёт о приёме-переработке-выдаче модулем какого-то проходящего через входные и выходные интерфейсы этого модуля физического потока. Этот физический поток будет реализовывать функциональный поток из функционального описания (например, принципиальной схемы), который идёт через функциональную/ролевую часть, на исполнение роли которой назначен модуль. Так, через USB-интерфейс может передаваться тот или иной поток данных (на принтер, на слайд-проектор, на внешний монитор), физически это будет соответствовать прохождению какого-то профиля электрического тока через контакты интерфейсных модулей --- но на принципиальной схеме/функциональной диаграмме/dataflow diagram это будут потоки предметных (страницы для принтера, слайды для проектора, экраны для внешнего монитора) данных между функциональными частями системы.
При интеграции важна не просто сборка, а согласование работы модулей на своих интерфейсах: монтажник должен убедиться, что соединение через интерфейс между парой интерфейсных модулей установлено, соответствует стандарту, описывающему интерфейс, и тем самым модуль сможет выполнять свой сервис в run-time.
Для интерфейсов известны правила, по которым устанавливается соединение через интерфейс, но неизвестно, что именно и зачем передаётся через этот интерфейс --- это будет известным только из принципиальной схемы. Предметная область появляется на принципиальной схеме, она появляется из разбирательства с функционированием, а не разбирательства с конструкцией. «Спальня» появляется из понимания того, что там делают, в функциональном мире. В конструктивном мире, мире продуктов/модулей это «комната». «Спальня» реализуется «комнатой» (а не, например, коридором или балконом).
Например, принтер и компьютер связаны через USB интерфейс, но какая информация идёт принтеру, это интерфейсу неизвестно. Утюг к электросети подсоединён через интерфейс между евровилкой и евророзеткой, но этому интерфейсу неизвестно, какой через неё пойдёт ток и что этот ток будет делать в run-time. Но известны не зависящие от функциональности предельные значения тока, который может пройти через этот интерфейс, равно как предельное количество информации, которое может пройти через USB-интерфейс. Задача модульного синтеза при проектировании системы --- это выбрать такие интерфейсные модули,интерфейсы которых смогли бы выдержать потоки с их рабочими режимами, предусмотренные функциональной структурой системы.
Вот ещё пример модульного/компонентного (в IEC 81346-1 предлагается компонентом называть заказной продукт, который приходит в проект от других создателей) описания, в этом случае речь идёт просто о списке комплектующих (ещё одно название продукта/компонента), которые нужно купить для изготовления iPhone 2008 года, при этом приведены цены --- и тут же это становится гибридным описанием, ибо включает и стоимостные оценки[1]:
Обратите внимание, сколько тут упоминается разных стандартов: GPS, HSPDA, DDR, Bluetooth --- перечисление интерфейсов, описываемых стандартами, обычно для модульных описаний. Ведь вся суть модулей --- это замена реализации какой-то функциональной части системы путём простой замены конструктивной части: модуля на стандартном интерфейсе. Быстрый прогресс в инженерии смартфонов и ноутбуков определяется именно этим: тщательным описанием интерфейсов.
Вместо одного принтера через интерфейс USB к компьютеру можно подключить другой экземпляр принтера той же марки, или даже принтер другой марки, или не принтер, а какое-то другое устройство (скажем, сканер, или даже дополнительный дисплей) --- без стандартизации интерфейса это было бы невозможно. Дальше будет работать конкуренция: цена и качество сервиса, получаемого через один и тот же интерфейс у конкурентов-поставщиков модулей будет разная, но смена модуля будет происходить легко для инженеров, им ничего не нужно будет менять в проекте, если они использовали стандартный интерфейс!
Стандартные (со стандартными интерфейсами) детали стоят дёшево, ибо их цену двигает вниз конкуренция. Если вы хотите увеличить цену изделия, то уберите из этого изделия стандартные интерфейсы --- и сразу получите огромную работу, которую в случае использования стандартов провели разработчики стандартов. Этим часто пользуются в государственных проектах, чтобы обосновать их высокую стоимость, просто прописывают нестандартный интерфейс в контракте --- и дело сделано! Метод борьбы --- требовать, чтобы межмодульные интерфейсы были прописаны не в контракте, а в открытом стандарте, контракт же содержал только ссылку на открытый широкой публике стандарт. Тогда больше шанс, что возникнет конкуренция и цены на закупаемые модули станут ниже. Этот метод борьбы за низкие цены комплектующих называется открытая архитектура/open architecture. Но регулярно архитектуру не открывают из соображений защиты от конкурентов, а также для того, чтобы проще было управлять конфигурацией. В закрытой архитектуре, чтобы поменять интерфейс взаимодействия модулей, нужно договориться меньшему числу людей --- чтобы поменять стандарт, нужно много больше времени. Архитектура iPhone как раз относится к этому классу закрытых архитектур. И это не самое дешёвое устройство, хотя переговорная сила Apple достаточно велика, чтобы держать низкими цены на комплектующие: просто там большие объёмы выпуска каждого модуля, и это мощный фактор на переговорах.
Все эти рассуждения относятся и к предприятиям/организациям, но для них функциональные части --- это оргроли, функции --- практики работы, а конструктивные части --- это оргзвенья, выполняющие сервисы. Об этом будет рассказано подробней в курсах «Методология» и «Системный менеджмент».