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

 

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

 

1. Введение

Программное обеспечение (ПО) обладает высокой степенью гибкости и широкими возможностями масштабирования. Это принципиально отличает его от технических изделий. Например невозможно представить ситуацию, когда одно изделие выполняет одновременно функции истребителя и транспортного самолёта. Однако ПО может иметь необозримое множество функциональных возможностей. По этой причине в последнее время программные продукты универсального применения практически вытеснили с рынка специализированные. Разумеется, у потребителя ПО может возникнуть необходимость  добавления новых функциональных возможностей, которые не вписываются в рамки предлагаемого программного продукта. На этот случай ведущие фирмы – производители программных продуктов оставляют возможность для наращивания самим потребителям.  К примеру, среда быстрой разработки приложений  Delphi компании Inprise, имеет большое число компонентов. Помимо этого пользователь, при необходимости, может создать свой компонент и внедрить его в среду, для того чтобы добиться своей цели. В результате создаются миллионы новых компонентов, которые распространяются через Интернет, либо свободно, либо за вполне умеренную плату. Фактически идёт совместная работа компании, создавшей среду и миллионов программистов – пользователей среды, над её улучшением и наращиванием. Другой пример. Компания Microsoft широко использует технологию COM (разработанную этой же компанией), благодаря которой, созданное для определённой задачи ПО, может быть использовано другими программными продуктами. Так компоненты браузера Internet Explorer применяются и среде разработки приложений Visual Studio. Технология COM разработана Microsoft не только для решения внутренних задач компании. Она открыта. Благодаря этому можно использовать текстовый редактор WinWord, не только для создания документов. Применяя COM объект данного редактора, мы можем импортировать в любую программу компонент проверки правописания. Более того, можно создавать ПО обеспечения для генерирования отчетов содержащих массу цифровой и графической информации.

На рынке ПО, предназначенного для инженерных целей, существует много первоклассных продуктов. Есть программы, посвящённые инженерной графике, теории упругости, электронике и т. д. Недостаток заключается в том, что интеграция этих продуктов весьма неудобна и трудоёмка. Может возникнуть вопрос: а зачем нужна интеграция между ПО, предназначенным для расчётов в области теории упругости и электроники? Ответ следующий. Данная интеграция нужна для разработки изделий содержащих, расположенные на гибкой конструкции тензометрические датчики, включенные в электронную схему. Нельзя исключать и следующую ситуацию. Инженеры разрабатывают изделие при помощи компьютерной программы, а программа не только производит расчёты, но и осуществляет подбор и заказ комплектующих, составляет смету, решает вопросы транспортировки и складирования, а также публикует технические характеристики изделия на соответствующем рекламном сайте.

Необходимо отметить одно важное обстоятельство. С момента появления вычислительной техники была создана масса прикладных инженерных программ. Многие были разработаны в те времена, когда объектно ориентированный подход не существовал. Переделка их под новые технологии потребовала бы колоссальных трудозатрат. К тому же даже если такая переделка оправдана, то она может оказаться болезненной и на неё трудно решиться. Однако при использовании предлагаемого подхода такая переделка вовсе не обязательна. Изложенные принципы позволяют совместно использовать старые программы и универсальное инженерное ПО.

В настоящей статье изложена архитектура универсального инженерного ПО, которое можно наращивать (масштабировать). Её применение обеспечивает многократное снижение трудозатрат при создании инженерных программ. Приведены примеры применения данной архитектуры при решении инженерных задач.

 

 

 

 

2. Постановка задачи. Анализ прототипов.

 

            Разработка сложных программных продуктов осуществляется на основе принципа декомпозиции. ПО разбивается на объекты, имеющие различное функциональное назначение. Очевидно, что и для решения инженерных задач уместна объектная декомпозиция. Например, в радиолокации уместно введение объектов «Летательный аппарат» и «Передающая антенна радиолокатора». Однако создание объектов это часть задачи. Необходимо обеспечить их взаимодействие. В приведённом примере нужно, чтобы антенна облучала летательный аппарат. Кроме того, немаловажно относительное положение антенны и аппарата. Итак, нужны объекты и связи, обеспечивающие взаимодействие. Многие программные продукты построены по данному принципу.  В частности существует превосходная среда LabVIEW предназначенная для моделирования, процессов взаимодействия электронных устройств. Данная среда имеет палитру компонентов между которыми можно устанавливать связи. Однако область её применения ограничена радиоэлектроникой. Если расширить множество типов объектов и связей то можно создать универсальную инженерную среду. Необходимо добавить объекты имеющие отношение к прикладной математике, механике, сопротивлению материалов и т.п.. Разумеется, данная задача не может, осуществлена в один этап. Но если обеспечить возможность потенциального наращивания  ПО, то она вполне реализуема, поэтапно. В принципе разработка ПО, позволяющего решать любую инженерную задачу, невыполнима. Однако если дать возможность пользователю возможность создавать и добавлять новые компоненты, согласующиеся с общей архитектурой, то в случае необходимости он сможет решить любую проблему. Данная ситуация аналогична компонентному подходу в программировании. Любая программная среда, основанная на данном подходе (например Delphi), имеет большое число компонентов. Помимо этого пользователь, при необходимости, может создать свой компонент и внедрить его в среду, для того чтобы добиться своей цели. В результате создаются миллионы новых компонентов, которые либо продаются, либо свободно распространяются. Фактически идёт не дублирование работ, а совместная работа компании, создавшей среду и миллионов программистов – пользователей среды, над её улучшением и наращиванием.

Кроме LabView существуют другие программные среды, оперирующие объектами и связями. Широко известны программные продукты Rational Rose и Visio. Данные среды используются в программировании и бизнес анализе. Главная цель этих продуктов состоит в том, чтобы сформулировать проблему. Следует отметить, что авторская программа, хотя и не предназначалась для бизнес анализа, оказалась вполне применимой для этой цели. Помимо реализованных прототипов существует большое число теоретических разработки связанные с универсализацией в науке и технике. В частности в математике универсализация основана на теории категорий. Данная теория позволила найти общие подход к разным разделам математики, которые на первый взгляд не имеют нечего общего. Также хотя инженерные задачи являются разнородными, общим у них является декомпозиция на подзадачи и объекты. Существуют работы, посвящённые применению теории категорий к программированию. В них рассмотрены вопросы декомпозиции процессов, реализации и требование к программным системам. Однако, по мнению автора, значение теории категорий в программировании ещё недостаточно хорошо понято. Имеет место значительный разрыв между теоретическими работами и внедрением теории категорий в практику. По мнению автора, теория категорий должна стать новым стандартом программирования. Это мнение основано на его практической работе, которая показала высокую эффективность теории категорий. Ниже на конкретных примерах будет показано применение.

 

 

4. Архитектура универсального инженерного программного обеспечения и примеры применения.

 

           

            Архитектура универсального ПО основана на том факте, что все модели реального мира состоят из объектов и связей между ними. В соответствии с этим пользовательский интерфейс должен содержать объекты и связи. Он содержит палитру компонентов и рабочее поле (рис 1).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Рис 1. Прототип пользовательского интерфейса универсального инженерного программного обеспечения.

 

Пользовать выбирает из палитры нужные компоненты и располагает их на рабочем поле. Далее он выбирает связи (из палитры) и связывает нужные объекты. Затем, при помощи редакторов свойств, производится настройка объектов и связей. И, наконец, при помощи компонентов – индикаторов (численных., графических, 3D) пользователь получает результат. В принципе данный интерфейс аналогичен LabView, Visio и т.п.

            Теперь рассмотрим архитектуру ПО. Каждому компоненту на палитре объекту или связи соответствует определённый класс (в смысле объектно ориентированного программирования). Каждый класс реализует один или несколько интерфейсов (снова в смысле объектно ориентированного программирования) связанных с решением инженерных задач. Например, в радиолокации летательный аппарат является объектом, меняющим своё состояние в результате радиоизлучения (облучаемым объектом). Кроме того, он же является и пассивным источником (отражённого) радиоизлучения. Таким образом, летательный аппарат (ЛА) должен реализовывать интерфейсы «облучаемый объект» и «источник радиоизлучения». Программно эти два интерфейса не являются независимыми. Так интерфейс «облучаемый объект» рассчитывает токи на поверхности, наведённые внешним излучением (ЛА). В свою очередь параметры отражённого излучения зависят от этих наведённых токов. С другой стороны передающая антенна реализует только интерфейс «источник радиоизлучения», а приёмная - «облучаемый объект». Кроме того, все перечисленные выше типы объектов реализуют интерфейс «объект, имеющий геометрическое положение». С другой стороны объекту «передатчик» совсем необязательно реализовывать данный интерфейс, поскольку геометрические характеристики излучения зависят только от расположения антенны. Итак, у нас есть типизованные объекты. Они соединяются типизованными направленными (имеющими начало и конец) связями. На связи налагаются ограничения, зависящие от того, какие интерфейсы реализуют их начало и конец. Например, у нас есть связь «электромагнитное облучение». Началом этой связи может быть любой объект, реализующий интерфейс «источник радиоизлучения», а концом – объект, реализующий интерфейс «облучаемый объект». Началом и концом связи «геометрическая привязка» являются объекты, реализующие интерфейс «объект, имеющий геометрическое положение». При этом началом связи, является базовый объект A, а концом объект B положение и скорость которого однозначно определяется положением и скоростью объекта A, но не наоборот. Работу программы осуществляют диспетчеры, соответствующие разным физическим явлениям. Есть электромагнитный диспетчер, геометрический диспетчер, механический диспетчер и т.д.  Электромагнитный диспетчер координирует расчёты, связанные с радиоизлучением, геометрический координирует расчёты, связанные с вычислением абсолютных координат и скоростей объектов в базовой системе координат. По мере разработки ПО число классов, интерфейсов, диспетчеров возрастает. Однако данная архитектура не приводит к состоянию, когда для наращивания функциональных возможностей ПО не приходилось осуществлять кардинальные переделки. Базовая архитектура позволяет обеспечить принцип открытости – закрытости, т. е. ПО открыто для наращивания и закрыто для модификации. Фактически развитие подобного ПО идёт не итерациями (по спирали), а вертикально вверх.