Функциональные описания: принципиальные схемы и сценарии
У очень и очень многих проектных ролей область интересов включает важные характеристики системы времени работы/operations, когда система готова и эксплуатируется, в run-time/operations. Объяснить, как система работает (то есть описать причины и следствия во взаимодействиях подсистем), можно при помощи функциональных описаний. В них мы объясняем назначение (функцию) каждой части системы и вклад этой части в достижение общего назначения системы, общего поведения системы в её окружении (run-time).
Принципиальные схемы --- это диаграммы, показывающие соединения функциональных частей друг с другом и удобные для объяснения принципа функционирования системы (отвечающие на вопрос «как работает система» --- как взаимодействуют между собой функциональные части, чтобы дать требуемую вовне функциональность системы в целом). Вот несколько типичных примеров принципиальных схем:
В ходе работы/функционирования функциональные части системы взаимодействуют друг с другом через потоки, проходящие через порты (ports) этих функциональных частей. В принципиальных схемах функциональные части обычно изображаются графическими элементами разной формы, а потоки --- линиями между этими графическими элементами. Порт --- это место присоединения соединительной линии к графическому элементу функциональной части.
В компьютере как источнике слайдов есть порт для присоединения слайд-проектора, и через этот порт в проектор текут данные слайда. Это мы дали функциональное описание, оно показывается на диаграмме. В физическом мире мы увидим конструктивную часть «ноутбук» и в нём давно устаревший интерфейс USB, через который кабелем присоединяется проектор. Конструктивный (физический) ноутбук реализует функциональный источник слайдов, конструктивный физический проектор реализует функциональный слайд-проектор, кабель реализует соединение источника слайдов и проектора, интерфейс реализует межпортовое соединение. «Реализует» тут означает, что конструктивный (физический) объект выполняет роль функционального объекта. В функциональном описании обычно присутствуют термины предметной области («показ», «слайды»), а в конструктивном описании этих слов нет. Молоток и микроскоп не знают, что они будут забивать гвозди, в их описаниях поэтому слов предметной области гвоздезабивания нет, равно как в предметной области компьютеров-ноутбуков слов про «слайды» нет, а вот слайд-проектор вполне может содержать такое слово, если он специализирован для показа слайдов, или не содержать этого слова, если он ещё и видеофильмы может показывать.
Функциональные части физичны, они выбираются для системы так, чтобы удобно было объяснять работу системы в ходе её эксплуатации/функционирования (run time, operations). Потоки --- это чаще всего логические/ролевые/функциональные объекты, которые тоже физичны, и через которые функциональные части взаимно влияют друг на друга. Это могут быть и потоки света, и электрический ток, и энергомассоперенос (в тепловых машинах), и даже данные (в программных системах).
В любом случае, мы приводим нашу мысль всегда в физический мир, но помним, что на принципиальных схемах изображается функциональный поток, а не физический объект, играющий роль проводника этого потока: например, электрический ток может течь по проводнику, по корпусу, по болтовому соединению, но в принципиальной схеме это разнообразие сред не будет изображено. В электрической схеме совершенно необязательно иметь ровно такое же количество проводов, которое изображено на этой схеме. Но между реализующими функциональные части продуктами/модулями ток всё-таки должен иметь возможность течь, чтобы система работала, «провод» лишь один из вариантов реализации потока/соединения/связи/взаимодействия.
Точно так же «труба» на гидравлической схеме будет только одним из способов реализации взаимодействия --- играющие роль функциональных частей системы конструктивные части/модули могут быть соединены друг с другом непосредственно, фланец во фланец, вообще без трубы, или вместо трубы жидкость может идти по какому-нибудь жёлобу, вариантов тут не счесть. Главное, что на диаграмме изображены соединения функциональных частей друг с другом так, что можно отследить их взаимодействие через передачу какого-то вещества или энергии, или данных. При этом данные в конечном физическом итоге будут тоже переданы через передачу вещества, например, перевозку грузовика с магнитными дисками, или энергии, например, через оптоволоконную связь, или через электрический ток между частями компьютера.
Помним, что функциональные описания могут показывать не только функциональные/ролевые части системы, но и непосредственно поведение/функции этих частей --- и это поведение тоже будет осуществляться над потоками. Тогда обычно говорят о входе (входной поток), обработке/функции/процессе (преобразование входного потока в выходной) и выходе (выходной поток). В этом случае говорят не о принципиальных схемах, а о функциональных диаграммах, процессных описаниях.
Вот пример такой функциональной диаграммы (function model[1]) в давно морально устаревшей, но чрезвычайно распространённой и часто встречающейся нотации IDEF0. Слева от каждого элемента его входы, а справа --- выходы, на стрелках написано, что именно передаётся от выхода предыдущей функциональной части на вход следующей.
Ещё один вид функциональных описаний --- это сценарии (scenario), иногда говорят о сценариях использования (use cases, переводить нужно не как «варианты использования», а именно «сценарии использования» --- оригинальный термин придумал Ivar Jacobson по-шведски, и это был как раз «сценарий», case был признан им неудачным переводом на английский).
Пример такой диаграммы[2] иллюстрирует действие активных частей системы, показываемых фигурками человечков. На картинке это проектные роли, но в жизни это вполне могут быть функциональные/ролевые части, которые играются не-людьми. В этих диаграммах используется «аристотелева физика» («палец давит на стол, но стол не давит на палец»), то есть показываются не взаимодействия, а именно действия: функциональные элементы обозначаются человечками-ролями/actors/деятелями, их действия (функции) моделируются отдельными элементами и диаграмма отражает «логические» сценарии (не в физическом времени! В «причинно-следственной» последовательности объяснения происходящего) как действия, осуществляемые функциональными частями/ролями/акторами/actors. Тут акторы могут быть и неживыми, это не «агенты», принимающие решения. Хотя когда мы пишем в материалах курса «актёр», то подразумеваем, что это часть агента, играющая роли. А то, что в use case называют actor, будет не «исполнитель роли», а собственно роль, причём ещё и безотносительно агентства (то есть без свободы воли, без возможности принимать решения, молоток в забивании тоже будет actor). Нужно всегда помнить, что слов в языке мало, и у каждого слова есть много разных значений, и термины «actor», «актор», «актёр» могут в разных дисциплинах разных практик обозначать совсем разные понятия, хотя иногда они и оказываются похожими до неразличимости. Так что не теряйте бдительности.
Режимы работы/функционирования какой-то системы обычно рассчитываются именно по функциональным описаниям, они ведь привязаны именно ко времени работы системы, а не ко времени её создания. Мультифизическое моделирование делается именно для функциональных описаний: ищутся оптимальные характеристики функциональных объектов для заданных режимов работы. Конечно, система моделируется в её окружении (это ведь run-time/operations-time, и работа системы существенно зависит от состояния её окружения).
Иногда рассмотренные функциональные диаграммы дополняют ещё и совсем уже процессными диаграммами, в которых объектами являются сами функции/поведение, называемые глаголами или отглагольными существительными --- «переноска», «охлаждение», «освещение». Но процессные диаграммы встречаются реже «принципиальных схем» с функциональными объектами как элементами диаграммы, а не поведением функциональных элементов как на процессных диаграммах. Скажем, на процессной диаграмме может быть изображено поведение «повышение давления жидкости», а на принципиальной схеме будет «насос» («объект-повышатель давления», а не его действие «повышение давления»).
Конечно, нужно помнить, что большинство описаний в реальных проектах «гибридны»: люди и в диаграммах, и в таблицах, и в текстах вполне могут уточнить, что функция повышения давления жидкости реализуется модулем-насосом, а не перепадом высот и модулем-жёлобом, или даже явно указать марку и технические характеристики оборудования, которое нужно закупить!
Основная проблема функциональных описаний: их обычно понимают только узкие специалисты, функциональное/ролевое/по назначению разбиение системы на части контринтуитивно. Но если вам задаётся вопрос о том, как именно работает система, то без какой-то хотя бы упрощённой принципиальной схемы или процессной диаграммы вам не обойтись. Обязательно готовьтесь к таким вопросам: в конце концов системы делаются для того, чтобы они работали, и большинству людей интересно, как они работают --- и только после разъяснений на эту тему с ними можно будет обсудить, как и из чего система сделана.
Системное мышление не учит тому, как читать и строить функциональные описания и документировать их. Системное мышление говорит, что функциональные описания должны быть сделаны (и документированы!). Как делать функциональные описания (с функциональной декомпозицией), как потом делать модульный синтез (принимать решения о том, какими модулями будут реализованы какие функциональные части) --- это говорит системная инженерия. А если вы хотите стать профессионалом, то вам потребуется изучить ещё и прикладную дисциплину, занимающуюся конкретно какой-то инженерной подпрактикой (например, освоить пару-тройку учебников, где объясняются use cases и как их использовать в проектах для создания моделей использования).