Производство программ. Инженерный подход

 
 
 
 
М. Ю. Охтилев, В. Н. Коромысличенко, П. А. Охтилев 
 
 
 
 
 
 
ПРОИЗВОДСТВО ПРОГРАММ 
 
ИНЖЕНЕРНЫЙ ПОДХОД 
 
 
Монография 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Москва    Вологда 
«Инфра-Инженерия» 
2024

УДК 004.4 
ББК 32.973 
О-92 
Рецензенты: 
заведующий кафедрой информационных и вычислительных систем 
Петербургского государственного университета путей сообщения 
доктор технических наук, профессор А. Д. Хомоненко; 
профессор кафедры компьютерных технологий и программной инженерии 
Санкт-Петербургского государственного университета аэрокосмического  
приборостроения доктор технических наук, профессор Ю. А. Скобцов 
Охтилев, М. Ю. 
О-92 
Производство программ. Инженерный подход : монография / 
М. Ю. Охтилев, В. Н. Коромысличенко, П. А. Охтилев. – Москва ; Вологда : 
Инфра-Инженерия, 2024. – 140 с. : ил., табл. 
ISBN 978-5-9729-1679-5 
Излагаются основополагающие понятия инженерного подхода к производству 
программных продуктов на основе таких дисциплин, как системная и программная инженерия. Рассматривается широкий спектр вопросов по анализу исходных потребностей интересантов, разработке исходных данных и ограничений для проектирования 
целевой системы в привязке к этапам жизненного цикла, а также рассматриваются требования к архитектурным решениям целевой системы для производства программного 
продукта. Приведены примеры реализации таких важных этапов жизненного цикла, как 
анализ исходных потребностей интересантов, концептуальное моделирование предметной области в соответствии с бизнес-процессами предприятий, на основе онтологий и 
моделей представления знаний в виде G-моделей на основе которых автоматически 
формируются схемы программ.  
Для студентов вузов, обучающихся по специальности «Программная инженерия» и другим смежным специальностям. Может быть полезно преподавателям и аспирантам. 
УДК 004.4 
ББК 32.973 
ISBN 978-5-9729-1679-5 
” Охтилев М. Ю., Коромысличенко В. Н., Охтилев П. А., 2024 
” Издательство «Инфра-Инженерия», 2024 
” Оформление. Издательство «Инфра-Инженерия», 2024 

ОГ
ЛАВЛЕНИЕ 
ПРЕДИСЛОВИЕ 
.......................................................................................................... 4 
ВВЕДЕНИЕ .................................................................................................................. 5 
ГЛАВА 1. ОСНОВАНИЯ ПРОГРАММНОЙ ИНЖЕНЕРИИ ................................ 8 
Раздел 1.1. Базовые концепты системной инженерии 
......................................... 8 
Раздел 1.2. Система в системной инженерии ..................................................... 10 
Раздел 1.3. Методологии системной инженерии ............................................... 13 
Раздел 1.4. Модели представления систем ......................................................... 15 
Раздел 1.5. Жизненный цикл системной инженерии ......................................... 21 
Раздел 1.6. Исходные потребности интересантов: анализ потребностей  
и разработка исходных данных на основе архитектурного подхода 
............... 23 
Раздел 1.7. Интеграция исходных данных в системной инженерии 
................ 36 
Раздел 1.8. Системная программная инженерия ................................................ 37 
Раздел 1.9. Онтологии в программной инженерии ............................................ 42 
Раздел 1.10. Базовая методология программирования ...................................... 45 
Раздел 1.11. Основания архитектурного подхода к концептуальному 
моделированию программной системы .............................................................. 47 
Выводы по главе 
.................................................................................................... 60 
ГЛАВА 2. АНАЛИЗ ЖИЗНЕННОГО ЦИКЛА  
ПРОГРАММНОЙ ПРОДУКЦИИ 
............................................................................ 61 
Раздел 2.1. Анализ предметной области ............................................................. 61 
Раздел 2.2. Концептуальное моделирование, на основе онтологий, этапов 
жизненного цикла разработки программного продукта ................................... 68 
Выводы по главе 
.................................................................................................... 71 
ГЛАВА 3. ВОПРОСЫ ТЕОРЕТИЧЕСКОГО ОБОСНОВАНИЯ 
ПРАКТИЧЕСКОЙ РЕАЛИЗАЦИИ ЕДИНОЙ ТЕХНОЛОГИИ  
УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ ........................................................... 72 
Раздел 3.1. Вычислительные G-модели как основа представления знаний .... 72 
Раздел 3.2. Онтолого-управляемое моделирование предметной области 
....... 92 
Раздел 3.3. Онтолого-управляемое проектирование  
графического интерфейса 
..................................................................................... 96 
Выводы по главе 
.................................................................................................. 102 
ГЛАВА 4. ОПИСАНИЕ ПРОГРАММНОГО КОМПЛЕКСА ............................. 103 
Выводы по главе 
.................................................................................................. 114 
ЗАКЛЮЧЕНИЕ ....................................................................................................... 115 
СПИСОК ЛИТЕРАТУРЫ 
....................................................................................... 116 
СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ .......................... 122 
СПИСОК ИЛЛЮСТРАЦИЙ И ТАБЛИЦ 
............................................................. 123 
СЛОВАРЬ ТЕРМИНОВ 
.......................................................................................... 125 
ПРИЛОЖЕНИЕ ....................................................................................................... 134 
ГОСТЫ ..................................................................................................................... 134 
ПАТЕНТЫ 
................................................................................................................ 138 
3 

ПРЕДИСЛОВИЕ 
Производство программ опирается на программную инженерию – важный 
элемент цифрового уклада экономики и является методологической и технологической основой промышленного производства прикладного программного продукта [59]. Быстрыми темпами развиваются разнообразные парадигмы программирования [7, 8, 43, 50, 51, 78]. Однако, практически все парадигмы программирования ориентированы на создание программ, как таковых, практически без 
привлечения богатейшего опыта инженерной деятельности, накопленного при 
реализации крупнейших проектов [32, 41]. В тех случаях, когда идеи инженерного подхода реализуются на практике, они, как правило, реализуют идеи сборки 
программ из готовых компонент [42, 43] сужая тем самым класс решаемых задач. 
С другой стороны, большинство публикаций по теме «Программная инженерия» 
посвящены обобщению зарубежного опыта, практически не рассматривая достижения отечественных исследователей. Предлагаемая монография призвано восполнить этот пробел. В нём рассматривается, созданная и развиваемая научной 
школой М. Ю. Охтилева, единая технология управления жизненным циклом программной продукции базирующаяся на парадигме концептуального программирования, концепции недоопределённых вычислений, модельного, онтологического, представления предметной области и обеспечивающая автоматизированное производство программного продукта [60, 61, 62, 179].  
Авторы выражают глубокую благодарность всему коллективу высококлассных программистов и разработчиков и надеются на дальнейшую плодотворную 
совместную работу. 
Главы 1 и 2 написаны Коромысличенко В. Н., разделы 3.1 и 3.2 главы 3, 
написаны Охтелевым М. Ю., раздел 2.1 главы 2 написан совместно, раздел 2.2 
написан Коромысличенко В. Н. совместно с Охтилевым П. А., раздел 3.3 написан 
Охтилевым П. А., раздел 3.4 главы 3 написан аспирантом Зянчуриным А. Э.  
4 

ВВЕДЕНИЕ 
Информатика и её составляющие – вычислительная техника и программное 
обеспечение – катализаторы научно-технического прогресса. Очевидным фактом является то, что практическая экономика становится цифровой. Инвестиции 
в цифровые технологии и капитал приводят к основанным на знаниях глубоким 
трансформациям нашего общества. Важным фактором для правительства нашей 
страны является содействие более устойчивому и всеобъемлющему росту экономики для достижения благополучия и равенства возможностей. Программная инженерия – важный элемент цифрового уклада экономики и является методологической и технологической основой промышленного производства прикладного программного обеспечения (ПО) – программного продукта.  
Это стало возможным потому, что в процессе развития программирования 
как деятельности оказалось: 
– во-первых, что возможен переход в оценке деятельности «программностроительных» организаций от показателей эффективности к показателям прибыли, что дало толчок к развитию на этой основе хозяйственно-экономических 
отношений между разработчиками и пользователями программной продукции; 
– во-вторых, хозяйственные отношения между поставщиками и пользователями программных продуктов оказались неотличимыми от таких же, что и при 
поставке всех других видов продукции. То есть поставщик гарантирует качество 
программных средств, в соответствии с регламентирующими документами, а 
пользователь формулирует требования и использует программные средства. 
Для обеспечения всех этапов жизненного цикла программных средств, как 
продукции производственно-технического назначения, в 1984–1986 годах были 
разработаны, утверждены и введены в действие нормативные документы, регламентирующие соответствующие этапы жизненного цикла разработки, производства и поставки программных средств как продукции [23].  
Естественно, что при текущих трендах развития технологий разработки ПО, 
рассматриваемых как составная часть производственно-технологического производства, производство ПО должно рассматриваться как инженерная деятельность.  
При рассмотрении программирования как инженерной деятельности следует учесть, что «единой технологии программирования всего» не существует. 
По мнению Н. Н. Непейводы: «нельзя получить универсальную формализацию, 
ни одна формализация не является универсальной, каждая формализация ограничена, и, более того, сама подсказывает собственные альтернативы» [55]. Это 
утверждение есть следствие теоремы Гёделя о неполноте: «всякая система математических аксиом начиная с определённого уровня сложности либо внутренне 
противоречива, либо не полна» [56], и теоремы Тарского о невыразимости: 
«..множество истинных формул арифметики первого порядка (то есть множество 
их номеров при любой фиксированной гёделевской нумерации) не является 
арифметическим множеством, другими словами, понятие арифметической истины не может быть выражено средствами самой арифметики» [56]. 
5 

Технология производства программной продукции (ТППП) не должна зависеть (определяться) от методологии, технологии (стиля) программирования, 
кроме этапа непосредственного производства кода. Это означает, что этапы жизненного цикла (ЖЦ) предшествующие этапу разработки кода должны описывать 
программу в понятиях высшего уровня, не используемых программой, и завершаться разработкой модели и спецификации программы, в которых типы данных 
и структуры типов находятся в рамках строгих ограничений. Всё должно быть 
подчинено «ясности и логичности программного кода» [57]. 
Среди программистов принято рассматривать программирование с двух полярных точек зрения: 
– как искусство, не подлежащее какой-либо регламентации [4]; 
– как организационно – техническую деятельность в приложении к одной из 
выбранных методологий программирования [38]. 
Действительно, для уникальных, архисложных проектов, возможно, всякая 
регламентация процессов создания программы не уместна. В тоже время опыт 
создания и использования теории решения изобретательских задач (ТРИЗ [2]) 
показывает, что эвристическая составляющая вполне может уживаться с инженерной деятельностью. 
Программирование, рассматриваемое как инженерная деятельность, базируется на рассмотрении задачи порождения (производства, создания) программ 
[28], как задачи индустриального производства. При таком рассмотрении, этапы 
ЖЦ включают обоснование замысла программного продукта, проектную деятельность, разработку технологической оснастки и подготовку производства – 
среду разработки программного продукта и технических средств, производство 
программного продукта на базе разработанных проектных решений (желательно 
в автоматическом режиме), включая контроль качества и верификацию, эксплуатацию и техническую поддержку эксплуатации (сопровождение). С этой точки 
зрения вопросы выбора определённого языка программирования, конкретной 
методологии программирования (структурная, функциональная или иная) являются важными, но не определяющими. Гораздо более существенны задачи анализа предметной области (ПрО) и исходных требований, системный или кибернетический анализ материальных и информационных процессов, протекающих 
в рассматриваемой области, их проекция на выбор и обоснование типов и структур данных, типов вычислительных процессов, технологий хранения и обмена 
данными, и в конечном значении, на модель (спецификацию) представления программы. Инженерный подход предполагает автоматический, автоматизированный, переход от модели представления программы к исполняемому коду. Иными 
словами, переход от инженерных, экспертных знаний к модели предметной области (ПрО) далее к модели объекта информатизации, затем к модели представления программы, от которой непосредственно к исполняемому коду. 
Необходимо отметить, что такая постановка задачи не является новой. Проектирование специализированного ПО, основанного на экспертных знаниях, базируется на изменении парадигмы программирования и переходе – от алгоритмической, к модельной методологии [53, 60, 62]. В этом направлении в СССР, 
затем в РФ, были достигнуты весьма значительные результаты [60, 74, 75]. 
6 

Программы, основанные на экспертных знаниях, проектируются и создаются на 
принципах «программирование без программирования» [179], в основном для 
космической отрасли и атомной энергетики [62]. Для внедрения накопленного 
опыта в практику разработки программных продуктов для иных ПрО, рассмотрим, основные этапы инженерного подходы с общих системных позиций, в том 
числе с учетом имеющегося опыта реализации подобных систем в космической 
отрасли.  
 
 
7 

Г
ЛАВА 1. ОСНОВАНИЯ ПРОГРАММНОЙ ИНЖЕНЕРИИ 
Цель раздела – определить таксономию ПрО программной инженерии (основные терминологические понятия и семантические связи между ними) и сформулировать основания программной инженерии.  
Инженерный подход к производству программного продукта естественно 
начать с рассмотрения общего инженерного подхода к решению задач создания 
сложных организационно – технических систем, который называется системной 
инженерий [41]. Понятие системная инженерия в качестве методологической 
основы, позволяющей установить устойчивую, сквозную связь между стратегическими целями, конкретными задачами и измеримыми результатами инженерной деятельности по созданию систем любых классов и назначения широко используется мировым инженерным и научным сообществом [41]. 
Раздел 1.1. Базовые концепты системной инженерии 
Системная инженерия – это яркий пример синтеза науки и практики. В её основе лежат информатика, теория систем и кибернетика [33]. С одной стороны – 
системная инженерия продукт современной науки и опирается на созданные специально для неё методы и процедуры, что ставит её в ряд с другими прикладными 
направлениями современной науки. С другой – в векторе развития системной инженерии практически отсутствует тренд к оформлению её в строгую и законченную теорию. Это, по-видимому, обусловлено тем, что значительная междисциплинарность и высокая вариативность, присущая сложным системам, существенно затрудняют формализацию методов для создания специализированной 
теории системной инженерии. Поэтому в методологических основаниях современной системной инженерии лежат, главным образом, опыт успешных разработок (практик). Основания системной инженерии представляют собой междисциплинарный комплекс методик и технологий, применяемых на всех стадиях жизненного цикла (ЖЦ), от замысла до вывода из эксплуатации, сложных систем любого масштаба и назначения в различных областях человеческой деятельности 
[41].  
Системная инженерия рассматривает решение любой сложной проблемы с 
позиций [33]: 
– системного подхода, который заключается в видении мира как системы, 
имеющей границы, назначение, элементы, связи между элементами, подсистемами, системой и окружающим миром, в состав системы входят заказчики и заинтересованные лица – интересанты, а также их интересы. Системный подход 
предписывает описывать мир с использованием именно этих терминов и понятий; 
– архитектурного подхода – методик и технологий декомпозиции на составляющие с целью получения таких архитектурных описаний системы, которые отвечают всем требованиям и интересам всех выявленных в проекте интересантов; 
– деятельностного подхода – подхода, в котором интересы интересантов и 
методы описания (онтологии и нотации описания) реализуются через призму 
описания деятельности акторов, осуществляемой над или с целевой системой; 
8 

– процессного подхода – по существу, деятельностного подхода, онтология 
и нотация описания которого включают обязательное рассмотрение и фиксацию 
деятельностей, осуществляемых над или с целевой системой, именно как процессов, то есть с рассмотрением и описанием элементов деятельности (практик), 
соединённых определёнными связями; 
– проектного подхода – деятельностного подхода, онтология и нотация описания которого включают обязательное рассмотрение и описание деятельностей, 
осуществляемых над или с целевой системой, именно как проектов, с рассмотрением и описанием ограничений по ресурсам и времени, а также достижимой 
цели, с привязкой к этапам ЖЦ и во взаимосвязи с внешними и внутренними 
надсистемами и подсистемами соответственно. 
Целевая система рассматривается с одной стороны, как имеющая в своём составе открытые, взаимодействующие между собой подсистемы и с другой, как 
представляющая собой часть более широкой или объемлющей системы. 
Целое невозможно свести к сумме частей этого целого – вот суть системного 
подхода. Само выделение целого как «фигуры из фона» не может быть произвольным, то же относится к элементам системы: важна цель системы, важно взаимодействие элементов для достижения этой цели, а не просто наличие произвольно выбранных частей. Любая система имеет надсистему и подсистемы, системы иерархичны. Границы системы с окружающими её системами важны и 
требуют явного определения: все участники междисциплинарного обсуждения 
должны говорить об одной и той же системе в одних и тех же границах, используя одну и ту же терминологию, чтобы не подменять системы в ходе их обсуждения. Это достаточно просто звучит, но по факту «редукционистский» (выделение отдельных черт исследуемого или проектируемого объекта, без обсуждения 
принципов, по которым эти отдельные черты были выделены) или «натуральный» («естественный», «здравого смысла») подход применяется повсеместно до 
сих пор. Системное мышление не становится системным только потому, что в 
текстах упоминается слово «система» и «выделяются части системы». 
Идея верификации (проверка на соответствие формальным требованиям) 
всем привычна. Намного труднее воспринимается идея, что такой проверки явно 
недостаточно: важно не столько соответствие требованиям, сколько то, чтобы 
системой можно было пользоваться – ибо при разработке системы ошибка могла 
закрасться в сами требования. Поэтому необходима не только верификация, но 
и валидация – проверка того, что требования конкретного внешнего потребителя 
или пользователя продукта, услуги или системы удовлетворены. 
Любые предсказания будущего (в том числе в таких формах, как тщательно 
разработанные планы) являются заведомо неполными и неточными, и с планами 
нужно работать как с «прогнозами», а не «обещаниями», что обычно воспринимаются очень тяжело. В этом смысле переход к риск-ориентированным формам ЖЦ, 
подразумевающим пошаговое выделение ресурсов на основе постоянного пересмотра структуры их выделения на основе непрерывно меняющихся оценок проектной ситуации и есть системный подход. Гибкие методы ведут к модификациям 
основных практик системной инженерии, когда планировать приходится в условиях отсутствия прецедентов (в этом случае требования должны меняться в тече9 

ние всего ЖЦ, что существенно отличается от традиционного не системного подхода – ведь в традиционных методах «предсказания будущего» все полные и детальные требования должны быть «предсказаны» в самом начале разработки). 
Для любой системы всегда есть множество заинтересованных сторон, мнение которых нужно учитывать. Это означает, что требования к системе всегда 
противоречивы, исходят из самых разных источников, и нужна специальная работа по их согласованию – значительная часть этой работы сводится не к техническим решениям, а к проведению переговоров между заинтересованными лицами и нахождению технических и организационных компромисов. Наличие 
множества заинтересованных в системе сторон существенно меняет содержание 
инженерной деятельности: эта деятельность по «инженерии требований» уже не 
проходит в мире исключительно технических решений, а должна учитывать противоречивые интересы самых разных людей. 
Процесс управления ЖЦ нельзя считать «конвейером», просто выполнением 
серии технологически предписанных работ (в теории управления организационными процессами это называют «оркестровка»). В жизни независимые действующие лица участвуют в процессе, выполняя контракт на оказание услуги по 
своей части, участвуя в общем процессе (в теории управления организационными процессами это называют «хореография»). В системной инженерии этот 
вопрос обсуждается как отдельная группа контрактных практик, причем самым 
трудным тут является понимание того факта, что контракты могут быть не 
только явные между различными юридическими лицами, но и неявные внутри 
действующих лиц в рамках одной организации. 
Подход системной инженерии к проектированию состоит в декомпозиции 
целевой системы на составляющие части, системы, подсистемы, модули, блоки, 
детали конструкций, и создание дерева структуры системы (System Breakdown 
Structure, структура разбиения системы, или Plant Breakdown Structure). Последовательное разбиение, декомпозиция системы создает слои, и каждому слою 
компонентов (элементов) целевой системы соответствуют слой требований и 
слой функций. Само архитектурное проектирование состоит в выборе методов 
разбиения системы на элементы, назначения элементам разбиения функций и 
требований, декомпозиции в свою очередь функций и требований на более конкретные и специфические элементы. После очередного разбиения в обязательном порядке проводится работа по установлению трассировочных связей, оценке 
зависимостей и описанию интерфейсов между элементами системы [41].  
Системная инженерия на международном уровне представлена международным советом по системной инженерии INCOSE [41]. Основным стандартом системной инженерии считается ISO/IEC 15288-2015. Системная и программная 
инженерия. Процессы ЖЦ систем [150]. 
Раздел 1.2. Система в системной инженерии 
Определение 1.1. Система (по INOSE) – интегрированный набор подсистем 
или блоков, элементов, выполняющий определенную задачу с определённой 
целью. Система включают в себя продукты (аппаратные средства, ПО, 
процессы, людей, информацию, методы, средства, службы, и другие элементы поддержки. 
10