ТЕХНОЛОГИИ ПРИМЕНЕНИЯ ГЕОМЕТРИЧЕСКОГО ИНСТРУМЕНТА. ОСНОВЫ

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

Материал, который представляется вниманию читателей в новой серии статей о разработке технологий геометрического эксперимента и приложении их результатов к решению практических задач в определенной части будет отделен от вопросов сугубо геометрической тематики. В нем, в частности, не планируется приводить решения каких-либо принципиально новых геометрических задач, представлять доказательства ранее не известных теорем. Не будет и дискуссии о значимости и роли геометрической науки в образовательном процессе. Вопросы такого рода неоднократно обсуждались на конференциях разных лет: каждый из читателей волен давать ответы на них, исходя из собственных воззрений, возможностей и компетенции. Позиция автора по проблемам данной тематики давно известна [1].

Разговор пойдет об определении вектора развития современной конструктивной геометрии, о взаимопроникновении и возможном слиянии воедино кибернетического и геометрического знания по ряду направлений. Полученные на его основе выводы должны привести нас к новому качеству: к обоснованию необходимости разработки ранее не существовавших информационных технологий, выявлению их потребительских качеств и преимуществ перед ныне существующими технологиями в практических приложениях конструктивного геометрического моделирования. Сделать это необходимо, для того чтобы двигаться вперед, чтобы развивать и разрабатывать методы представления и обработки информации, ассоциированной с понятием «форма», а не сетовать о том, что, дескать, приложения конструктивной геометрии к реалиям жизни закончились.

Несмотря на то, что термин «геометрическое моделирование» возник достаточно давно, понимание того, что геометрическая наука – это наука об информации, представленной сигналами особого рода, и, следовательно, к ней следует относиться, как к инструменту кибернетического содержания, нельзя назвать устоявшимся. В отличие от многих других областей знания, названия которых конкретно определяют их метод и сферы приложений, геометрическое моделирование «страдает» своеобразным дуализмом толкования. И, если под векторным исчислением обычно понимают применение аппарата именно векторов для моделирования сущностей и явлений окружающего мира (причем, возможно, и самих векторов тоже), а матричная алгебра – это наука о приложениях матриц, то за термином «геометрическое моделирование», очень часто скрывается применение всего, чего угодно, приспособляемого для моделирования геометрической формы, а вовсе не наоборот, как, по сути, должно было бы быть [2].  

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

Тот факт, что мы применяем геометрический метод, когда перед нами возникают задачи, суть которых наиболее полно и содержательно выражается в геометрических понятиях, вряд ли кто-то будет серьезно отрицать. Практичность и простота восприятия визуальных интерпретаций геометрических образов понятна каждому, кто хоть раз в жизни попытался представить, а тем более, передать кому-либо информацию о геометрической форме негеометрическими средствами вручную. Именно поэтому модель любого проектируемого объекта, выполненная в виде чертежа, для человека существенно удобнее модели, исполненной в виде списка уравнений, несмотря на то, что второй способ тоже возможен и с точки зрения информационной полноты равноценен первому. Первый метод изначально проще, но вслед за простотой, начинается рутина, а от рутины всегда хочется избавиться, переложить ее на плечи кого-нибудь другого. И если не на человека, то уж на автоматическое устройство –  обязательно.

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

Геометрия, пожалуй, единственная из наук, которая успешно противостоит победоносному шествию подобных иллюзий. И дело здесь вовсе не в какой-то ее принципиальной исключительности: она вся пронизана формализмами, строится на них, и, более того, сама она послужила причиной появления формального аксиоматического метода, который рассматривается многими современными исследователями как перспективный инструмент для принятия безошибочных предельно обоснованных решений и создания совершенной искусственной мысли. Но она же этот миф и разрушает, препятствует абсолютизации самой идеи о том, что истину можно однозначно определить или вычислить формально. Заслуга геометрии состоит в том, что для одних и тех же привычных понятий и их визуально интерпретируемых образов ее метод может быть положен в основу принципиально разных не сводимых друг к другу формальных систем, каждая из которых не только не противоречит здравой логике, но и находит себе применение при моделировании явлений окружающего мира. Иными словами, элементарные операции, принимаемые в аксиоматике без доказательств на основе здравой интуиции – это не божественная константа, а прецедент для свободы выбора и торжества иных здравых интуиций во всем их многообразии.

Поэтому система геометрического моделирования, если воспринимать этот термин во всей его полноте, не должна, просто не может строиться без учета вышеперечисленных обстоятельств. Ядро системы обязано быть гибким, оно должно предполагать возможность предписания привычным или вновь создаваемым образам геометрии качеств, порождаемых формализмами с различными операционными базисами. О требованиях, предъявляемых к системам подобного рода, о принципах и методах их построения и пойдет далее речь. Высказываемые соображения будут иллюстрироваться примерами, возникшими из опыта многолетней разработки автором системы конструктивного геометрического моделирования Симплекс [5]. На этом пути были и взлеты, и поражения, и восторг, и разочарование. Поэтому не стоит рассматривать приводимые примеры, как истину в последней инстанции. Излагаемые мысли – это адресованное к читателю приглашение заглянуть в систему с изнаночной стороны, посмотреть как, для чего и на основе каких соображений она создавалась. А значит, и лучше понять, о чем она и для чего она нужна. И создать что-то свое.

* * *

Мы пользуемся термином «геометрическое моделирование», когда перед нами возникают задачи, суть которых наиболее полно и содержательно выражается геометрическими понятиями, символами формы. Моделирование – это один из основных инструментов познания, доставляющих информацию ее потребителю: человеку или техническому устройству. А для того чтобы этот процесс был действенным и приносил практическую пользу, модель должна работать, она должна действительно доставлять информацию, функционировать, как кибернетическое устройство, как абстрактная или материально воплощенная геометрическая машина [3].

О причинах былой «несостоятельности» геометрических моделей уже много говорилось [1, 4]. Подводя итог соображениям, высказанным в этих работах, отметим, что виною произошедшего в геометрии застоя явилось инструментальное несоответствие между предметом и методом геометрической науки, а не ее качество или «второсортность». Инструментальные ограничения длительное время не позволяли воплотить парадигму геометрической машины в нечто материальное и действенное, что, по сути, является технологической проблемой, а не математической. В настоящее время эта проблема решена, и инструментальные возможности аналитической и синтетической ветвей математики уравнены. И хотя реальное состояние дел в геометрическом моделировании, разумеется, находится в непосредственной зависимости от исторически обусловленных факторов, его будущее в самой большой степени зависит от увлеченности и энтузиазма нового поколения исследователей, которые сумеют обнаружить необычайный простор для приложения своих сил и творческого потенциала в деле единения геометрического и кибернетического знания, если подобное желание возникнет. Хочется надеяться на то, что соображения, которые будут представлены в данной и последующих статьях, послужат отправной точкой для тех из них, кто не побоится создать свою собственную систему геометрического моделирования, и уже почти тридцатилетний опыт автора данной статьи в деле разработки системы конструктивного геометрического моделирования Симплекс окажется в этом деле полезным подспорьем. 

Можно, конечно, пожурить автора за то, что тридцать лет – это очень много для создания всего лишь одной программной системы, да еще и позиционируемой, как средство проведения геометрических экспериментов [6-8]. Да, это немалый срок, но все это время – это период поиска ответов на трудные вопросы. Эти вопросы определяли и будут определять идеологию системы, развитие ее архитектуры.

Таких вопросов достаточно много, далеко не все они относятся непосредственно к геометрии. Но начнем все же с таких, которые имеют более-менее геометрическое содержание. Несмотря на то, что многие из них в своей формулировке кажутся исключительно простыми, они легко могут поставить «в тупик» практически каждого, даже тех, кто считает себя вполне сведущим в геометрии человеком. Возможно, они покажутся кому-то несколько странными, частными и непринципиальными. К сожалению, при проектировании системы, при выборе структур данных, алгоритмического базиса частные случаи – это основа для краха всех надежд, это причина тех обстоятельств, из-за которых система теряет свое основное качество– системность и превращается в предмет для устранения причин или последствий исключительных ситуаций и прочих «программных дыр». И еще один аспект: без должных геометрических ответов на вопросы подобного рода не сможет развиваться и их аналитическая интерпретация, ей просто неоткуда будет родиться!

На простые «сложные» вопросы надо обязательно отвечать. Без таких ответов любая информационная система сразу перестает быть системой полноценной – она будет не способна адекватно реагировать на вырожденные ситуации, на исключения, которые в геометрии, скажем откровенно, до сих пор изучены недостаточно. Более того, такие вопросы, как своеобразные прожекторы, высвечивают «проблемные места» теории.

Ниже для примера представлены лишь несколько вопросов. Некоторые из них уже озвучивались на конференциях [4, 6], но все же приведены здесь для полноты картины.

1. Вопрос: состоит ли прямая из точек? Ответ – нет, не состоит. Обоснование: не существует алгоритма, позволяющего построить прямую линию, проходящую через две несовпадающие точки, не опирающегося на понятие прямой линии.
2. Все ли прямые, принадлежащие плоскости, пересекаются в одной точке (пусть даже несобственной, если они параллельные). Ответ – нет, не все. Обоснование: две различные прямые линии, занявшие в результате действия геометрического алгоритма общее геометрическое место пересекаются по прямой. Более того, если они несут на себе различные точечные ряды, то они могут порождать совершенно разные проективитеты.
3. Радикальная ось двух окружностей – это прямая линия? Ответ – нет, это окружность. Обоснование: радикальная ось – это один из элементов пучка окружностей с двумя действительными или мнимыми центрами. На чертеже радикальная ось «выглядит», как прямая линия. Любая другая прямая линия, пересекающая элементы пучка окружностей в действительных или мнимых точках, порождает две точки, инцидентные с каждым элементом пучка. И лишь радикальную ось она будет пересекать одной точке, что нелогично. При этом в операции инверсии относительно произвольной окружности исходный пучок окружностей перейдет в другой пучок окружностей, а радикальная ось одного пучка в окружность другого, которая, между прочим, будет пересекаться с прямой линией в двух точках. Налицо несоответствие, которое можно устранить лишь принятием того факта, что радикальная ось – это окружность, «элементом» которой «в дополнение к имеющейся» является еще и бесконечно удаленная прямая [9].
4. Если две несовпадающие прямые плоскости пересекаются в точке, то является ли прямая объединением двух точек? Ответ – нет, объединение двух точек – это две точки. Обоснование: прямые и точки – это элементы множеств разной природы. Фразу «две прямые пересекаются в точке» следует понимать в том смысле, что каждая из прямых несет на себе по точечному ряду. И лишь поэтому в двух точечных рядах существует одна общая точка, которая и трактуется, как точка пересечения двух прямых. Но, если все же допускать подобный терминологический «жаргон», то тогда в соответствии с принципом двойственности его следует допускать и в отношении двух точек. Каждая точка является центром пучка всех прямых, которые проходят через этот центр, то есть точка, является носителем прямых. Но тогда найдется всего одна прямая, общая для имеющихся в нашем распоряжении пучков с двумя несовпадающими центрами. Из этого непременно следует, что прямая линия является результатом пересечения двух точек.
5. Через любую точку плоскости можно провести лишь одну прямую, параллельную заданной прямой. Для этого требуется провести ее через исходную точку и точку, расположенную в бесконечности на заданной прямой. Вопрос, можно ли считать построенные прямые параллельными, если первая точка отнесена в бесконечность по произвольному направлению? Ответ – нет, нельзя. Если такое допустить, то бесконечно удаленная прямая будет параллельна любой прямой плоскости, а это в силу транзитивности влечет за собой параллельность между собой всех прямых плоскости.

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

На осознание важности этих особенностей уходят годы, они не очевидны в момент начала создания системы и даже на этапе формирования и накопления ее функционального состава. Рано или поздно понимание возникающих проблем, конечно, приходит. Это происходит тогда, когда, казалось бы, очевидные и простые вещи должны были бы работать, но не работают. Приходится останавливать работу, погружаться в осмысление неожиданно возникшей проблемы, менять концепции, переделывать код; в результате внесенных правок начинает отказывать что-то другое уже, как казалось, разумно сделанное и отлаженное. В такие критические моменты обычно посещает мысль: знать бы о всем этом заранее, сколько проблем можно было бы избежать! Но, к сожалению, весь этот «позитивный» опыт приходится получать на собственных ошибках и предшествующем им недомыслии; почитать о проблемах подобного рода попросту негде. Далеко не каждый разработчик станет открыто и публично делиться собственным know how, если, конечно, оно у него есть.

И все же обет молчания – это не тот способ, посредством которого должно формироваться научное знание. О проблемах создания информационных средств для целей автоматизации геометрического моделирования нужно говорить, если есть, о чем сказать.

В первой статье цикла речь пойдет о вещах относительно простых. Будем полагать, что у нас есть какая-то задача и решается она сугубо геометрически. Целью повествования станет развернутый ответ на вопрос: с чего следует начинать разработку средства автоматизации, претендующего на роль инструмента для решения задач методами конструктивного геометрического моделирования?

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

Безусловно, перечисленные цели сложны в реализации. И заявление о том, что все они решены и решены весьма успешно, было бы не только нескромным поступком, но и фактом, далеким от истины. Нерешенных проблем по каждому пункту, хоть отбавляй! Следует учесть, что решение геометрических задач –  это процесс творческий, который не подвержен строгой регламентации, и в этом заключается одна из принципиальных сложностей разработки средств автоматизации. И все же в настоящее время система является цельной, в ней в определенной степени представлены технологические и методические решения по каждому этапу. О них, практически, ничего не известно и поэтому некоторые из них предполагается осветить в статьях цикла. Итак, начнем обсуждение первого этапа.

С чего же все-таки начать проектирование системы автоматизации? А начать, видимо, надо с первичного анализа деятельности человека, решающего задачу с применением конструктивного геометрического метода, причем делающего это традиционным способом – вручную. Для этого непременно нужно отстраниться от вопросов жгучих, но непринципиальных, наподобие следующих: зачем он это делает, можно ли было это вообще не делать, почему бы для решения задачи сразу не использовать графический пакет, который есть под руками и т.д. Приняв эти соображения во внимание, представим себе, что бы делал и как бы поступал рядовой среднеквалифицированный пользователь, решая предложенную ему задачу традиционно, т.е. обычными чертежными инструментами вручную. Подумаем о том, какая автоматизация ему была бы нужна и в чем бы заключался ее смысл.

Можно предположить, что, видя перед собой чистый лист, человек, приступающий к решению задачи, еще не имеет четкого плана достижения результата. Это совсем не значит, что в его голове нет никаких мыслей, относящихся к делу, – они безусловно есть, но их организация –  дело времени, тем более, что любой чертеж допускает определенную свободу в избрании способа его воплощения, и еще до начала процесса решения, нужно определиться по многим другим сопутствующим вопросам: выбрать формат, масштаб, подобрать инструменты, подумать о композиции, организовать рабочее место и проч.

Обычно в повседневной практике решение задач подобного рода работа начинается с нанесения на лист первичных исходных данных. Эти данные, возможно, будут воспроизведены сразу. Но может случиться и так, что потребуются начальная прикидка, эскизирование, какой-нибудь предварительный расчет. Во всяком случае, исключать факт того, что этот процесс может оказаться затяжным, итерационным и многократно изменяемым, нельзя. Затем эти данные начинают «обрастать» теми или иными геометрическими построениями, образующими в конце концов общую последовательность решения всей задачи целиком. Для достижения этого к объектам чертежа прикладываются чертежные инструменты, используются приемы (если они известны проектировщику), позволяющие в той или иной мере повысить точность и сократить время достижения окончательного результата.

Обычно задача разбивается на более-менее крупные логически обусловленные блоки, являющие собой реализацию методов и приемов решения подзадач общей задачи, имеющих единое смысловое содержание. Как правило, каждая подзадача выполняется от начала и до конца, а потом внимание проектировщика переключается на следующую подзадачу, в результате чего последовательность решения всей задачи можно было бы укрупненно представить последовательно обходимой ветвящейся древовидной структурой. Трудно предположить, что человек будет постоянно переключать внимание от одной подзадачи к другой, не достигая логического завершения каждой из них в отдельности, хотя, разумеется, и такой вариант работы списывать со счетов нельзя.

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

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

И, пожалуй, самое главное: при малейшем изменении исходных данных, всю работу приходится начинать сначала. Безусловно, выполненный вручную чертеж – это модель, но модель эта разового применения. Осуществляя чертежные действия, специалист действует в соответствии с некоторым алгоритмом, то есть незримо программирует решение задачи. Конечно, чертеж, реализованный на бумаге и неспособный к изменению, называть программой можно лишь с очень большой натяжкой. Ведь программа должна работать, а чертеж, воспроизведенный на бумаге, – это фиксированное состояние конкретной реализации алгоритма.

Из сказанного вытекает, что при разработке средств автоматизации решения задач конструктивным геометрическим методом первоочередную роль играют следующие аспекты:

1. Необходимо в максимальной степени обеспечить свободу действий пользователя и не обременять эту свободу каким-либо детерминированным регламентом. Данное требование не согласуется с принципами обычного детерминированного программирования, свойственного общетехническим алгоритмическим языкам, в которых ход исполнения программы определяется предписанным порядком следования операторов и команд условного или безусловного перехода. Любая попытка обязать пользователя записывать свои действия в виде последовательности операторов, каждому из которых необходимо определить свое конкретное место в программе, да еще и делать это в текстовом виде, противоестественна геометрическому методу. Детерминизм был бы неоправданным усложнением деятельности: в реальной практике человек, решающий геометрическую задачу, концентрирует внимание на вычерчивании, а не на соблюдении порядка текстовых записей, и он привел бы к отказу от пользования системой, построенной на принципах детерминизма.
2. Процесс создания чертежа должен быть визуальным и интерактивным. Он должен осуществляться путем организации взаимодействия объектов системы, представленных визуальными образами, причем все действия должны восприниматься пользователем как процесс черчения, а не процесс формирования текста.
3. Все операции воздействия на чертеж должны незримо для пользователя фиксироваться системой и неявно формировать программу его построения. Именно поэтому за визуальными и невизуальными объектами чертежа следует понимать не конкретные значения составляющих его объектов, а ассоциированные с этими объектами переменные, несущие в себе их значения и определяющие тот или иной вид отображения чертежа как на этапе его проектирования, так и на будущих этапах его изменения.
4. Для выполнения комплексных построений, а также для обдумывания хода решения, проектировщик должен иметь возможность подразделять единую задачу на законченные смысловые части, которые впоследствии можно было бы объединять в единый алгоритм, то есть реализовывать процедурный подход при проектировании чертежа. Таким образом, комплексные построения становятся информационным базисом, предназначенным для разработки новых виртуальных геометрических инструментов, не только существенно сокращающих сроки и повышающих качество проектирования, но и пригодных для расширения объектного и функционального состава системы.
5. Присутствие в проекте объектов, являющихся результатами всех промежуточных построений, – одно из основных проявлений метода конструктивного геометрического моделирования.  Все такие объекты индивидуальны и различимы, между ними установлены причинно-порождающие связи, фиксирующиеся в программе построения чертежа. Для обеспечения комфортной работы пользователя они должны быть доступны в любой момент проектирования, но в то же время они не должны перегружать своими изображениями интерфейс взаимодействия пользователя с системой. Насыщенность чертежа объектами может быть произвольной: ненужные на каком-то этапе изображения гасятся, но не удаляются.
6. Для достижения результата проектировщик применяет геометрические инструменты. В качестве инструментов используются линейки, циркули, лекала, а также дополнительные комплексные геометрические построения. Инструменты применяются к имеющимся данным с целью получения новых производных данных. Таким образом, одномоментное применение инструмента к данным может рассматриваться как элементарная операция, преобразующая информацию, представленную во входных параметрах преобразователя, в выходные данные. С точки зрения разработчика системы автоматизации проектирования такая операция должна соответствовать функции определенного типа, прилагаемой к конкретным данным. В терминологии системы Симплекс такая функция называется отношением (или элементарной геометрической машиной), преобразующей некоторый набор исходных данных, в набор выходных данных. Здесь важно обратить внимание читателей на то, что операция, связанная функцией, –  это не одно и то же.  Вариация операций, ассоциируемых с функциями, позволяет управлять аксиоматическим базисом информационной системы, а следовательно, при неизменном состоянии общей конструкции совокупной геометрической машины становится возможным получать варианты ее реализации в различных геометрических системах. Безусловно, возможности создания виртуальных инструментов геометрического моделирования при открывающихся возможностях в сравнении с ручными механическими инструментами поистине безграничны [7, 8].
7. Особенностью конструктивных геометрических алгоритмов является необходимость многократного итерационного выполнения однотипных действий над одним и тем же набором исходных данных в условиях вариации позиционных отношений. Такой подход обеспечивает, например, возможность определения некоего интегрального образа, индуцированного этими данными. В качестве примеров можно привести операции проведения сплайновой кривой через множество узловых точек или построение сечений поверхности посредством множества плоскостей. Обычно такие операции воспринимаются проектировщиками как непроизводительная, но неизбежная рутина. В детерминированных языках программирования итерационные процедуры подобного рода реализуются в операторах циклов, однако внедрение несвойственных природе геометрических объектов операторов цикла в геометрическое описание производимых пользователем действий нарушает принятую ранее концепцию о недетерминированном характере синтеза программы. Обозначенная проблема решена в системе Симплекс с использованием концепции согласования параметров отношения.
8. Система должна обеспечивать работу с собственными и несобственными элементами моделируемых пространств, учитывать вещественные и комплкснозначные значения объектов, участвующих в построениях. В противном случае говорить системности реализации геометрического метода не приходится: реализуемые проекты будут изобиловать исключениями, отказами, пропусками решений и ошибками.
9. Как уже говорилось выше, чертеж представляет собой внешнее представление программы, скрытой внутри системы. Очень важно обеспечить такой режим функционирования системы, при котором она могла бы экспортировать такую программу в форматах программ, представленных на общетехнических языках программирования поддерживающих парадигмы как детерминированного, так и недетерминированного способов решения задач. Благодаря этому качеству, алгоритмы, разработанные средствами системы, приобретают практическую значимость. Они могут быть использованы не только как чертежи, но и как управляющие программы для станков с ЧПУ, внешние программные модули открытых систем, становиться программными компонентами встраиваемых систем, драйверами устройств, геометрическими процессорами, системами управления, включаться в закрытый аппаратно-программный состав ядер микроконтроллеров и составлять предмет их интеллектуальной собственности (IP).

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

Обсудим теперь основные идеи и технологии, положенные в основу автоматического синтеза программы, представляющей работу геометрической машины, с практической точки зрения на примере системы Симплекс. Сразу обратим внимание на то, что от рядового пользователя не требуется детальное понимание описываемых здесь программных механизмов. Все их проявления ни в чем не противоречат логике обычного проектирования и практически незаметны при работе в системе. Однако такое знание может быть полезным, когда синтезированную в Симплексе геометрическую модель предполагается использовать во внешних системах и средах разработки, например:

• при внедрении действующей модели в HTML-страницу;
• для генерации интерактивного чертежа на языке JavaScript, сопровождающего научную электронную публикацию или интерактивное кроссплатформенное учебное пособие, доступное обучающимся в дистанционном режиме в браузерах мобильных гаджетов;
• для автоматического создания скрипта, управляющий анимацией трехмерных геометрических моделей в среде системы 3D StudioMax;
• при генерировании программы для встраиваемой системы на микроконтроллере.

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

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

Рис. 1. Обобщенная схема, отражающая логическую структуру отношения

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

Например, отношение вида «Построить точку p1, заданную координатами 10 10», может быть исполнено, поскольку значения всех его входных параметров известны. В результате будет образована точка с именем p1 и координатами X=10, Y=10. В то же время отношение вида «Построить точку p2, заданную координатами a b» не может быть исполнено, поскольку неизвестно, что скрывается за именами еще необъявленных объектов a и b, (т.е. значения объектов а и b не существуют). Тем не менее, этой информации достаточно, для того чтобы зарегистрировать в системе присутствие объектов p2, а и b, которым в данном случае никаких значений не присвоено. Поэтому, даже не обладая информацией о значениях на текущий момент, можно рассуждать о причинно-порождающей зависимости декларированных отношением объектов: в частности, p2 является потомком объектов a и b, в то время как a и b являются предками объекта p2.

Совокупность отношений, рассматриваемых в единстве причинно-следственных взаимосвязей объявленных в них объектов, составляет алгоритм (рис. 2). Объекты, входящие во входные и выходные параметры отношений, являются собственностью алгоритма и регистрируются в списке имен переменных, ассоциированных с этим алгоритмом. Все отношения алгоритма, потенциально способные выполнить вычислительную работу при конкретизации значениями объектов их входных параметров, составляют программу этого алгоритма. Множество отдельных алгоритмов (и некоторые другие не рассматриваемые в рамках статьи понятия) составляют проект системы Симплекс.

Рис. 2. Обобщенная схема, отражающая логическую структуру алгоритма

Поскольку на чертеже конструктивной модели, как уже упоминалось ранее, все объекты индивидуальны, разумно потребовать, чтобы все они имели несовпадающие друг с другом имена. Поэтому в составе алгоритма не допускается наличие отношений, декларирующих объекты с одними и теми же именами (рис. 3). За соблюдением этого важного требования следят специально предназначенные для такого контроля механизмы системы (бизнес-правила), которые, к тому же, избавляют пользователя от проблем именования и идентификации объектов. Именно недопустимость объявления объектов с одним и тем же именем в разных отношениях в сочетании с формальным способом определения причинно-порождающих зависимостей объектов друг от друга позволяют избавить пользователя от забот, связанных с соблюдением строгого порядка выполнения вычислительной работы отношений алгоритма. Запрещена также прямая и опосредованная циклическая зависимость объектов от самих себя (рис. 4). При этих условиях вычислительная работа алгоритма в целом становится инвариантной к порядку следования команд в программе, а это означает, что интерфейсное взаимодействие пользователя с системой можно построить только на графической основе, а сам процесс программирования геометрической модели становится незаметным пользователю, неотличимым от операций обычного вычерчивания геометрических объектов на экране монитора.

Рис. 3. Конфликт двух отношений, декларирующих один и тот же объект

Рис. 4. Конфликт группы отношений, образующих циклическую зависимость

Процедура, принуждающая все отношения алгоритма исполнить вычислительную работу вне зависимости от порядка их объявления в алгоритме, исключительно проста.  Побуждением к выполнению этой процедуры, может стать либо изменение состава отношений алгоритма, либо изменение состава значений входных параметров какого-либо из отношений алгоритма. Это событие может быть связанно с добавлением нового отношения к уже существующему составу отношений алгоритма, изъятием отношения из него, а также изменение хотя бы одного значения из состава параметров уже существующих отношений. Приведем краткое описание принципа работы этой процедуры (рис. 5).

Рис. 5. Алгоритм выполнения совокупной вычислительной работы геометрической машины

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

Логический признак Success, отвечающий за фиксацию факта обнаружения выполнения вычислительной работы отношения, устанавливается в значение false.

После этого система начинает последовательный перебор отношений, имеющих статус «не рассчитано», и пытается выполнить вычислительную работу такого отношения. Как уже отмечалось ранее, вычислительная работа может быть выполнена, если значения всех входных параметров отношения известны, в противном случае выбранное отношение игнорируется. В случае успешного выполнения отношением вычислительной работы, его статус изменяется на значение «рассчитано», а признак Success устанавливается в значение true.

Подобный перебор и попытка исполнения вычислительной работы осуществляется до исчерпания списка отношений. Если после завершения всех итераций признак Success имеет значение true, то это означает, что какое-нибудь из ранее нерассчитанных и пропущенных отношений потенциально стало способным к выполнению вычислительной работы. Поэтому система переводит признак Success в состояние false и приступает к новому просмотру перечня отношений, имеющих статус «не рассчитано».

Итерации будут продолжаться до тех пор, пока в результате последовательного перебора отношений ни одно из них уже не осуществит вычислительную работу. В этом случае перебор завершается со значением признака Success, равным false, и все объекты алгоритма, порождающие отношения которых выполнили вычислительную работу, считаются получившими значения. Объект, обладающий значением, может быть визуализирован. Таким образом, соблюдение требований пунктов 1 и 2 о недетерминированном характере представления модели обеспечено.

Большинство отношений, встроенных систему изначально, причисляются к т.н. простым отношениям. Под простым отношением понимается такое, все выходные параметры которого зависят от всех его входных параметров. Тогда преобразование, осуществляемое таким отношением, можно рассматривать с позиций черного ящика, то есть внутренний механизм взаимодействия его параметров скрыт от наблюдателя и не может быть подвергнут логическому анализу на предмет выявления каких-либо внутренних причинно-порождающих взаимосвязей.

Алгоритм, как результат совокупного действия составляющих его отношений, тоже может быть представлен, как преобразователь информации, имеющий вход и выход, то есть сопоставлен с отношением, имеющим сложную внутреннюю структуру. Формальный анализ причинно-следственных взаимосвязей всех объектов алгоритма позволяет выделить среди них две категории объектов: первые – это такие объекты, которые не имеют иных предшественников, кроме, быть может, констант, и вторые – это такие объекты, которые не имеют последователей. Первую группу имеет смысл отнести к категории естественных входных параметров алгоритма, а вторую – к категории естественных выходных параметров алгоритма. Тогда такой алгоритм можно «свернуть» в отношение, у которого, как и у любого элементарного отношения, имеются входные и выходные параметры и функция, отражающая последовательность производимых алгоритмом преобразований. Такой алгоритм можно использовать в качестве процедуры, если при обращении к нему из вызывающего алгоритма, система будет генерировать его копию, временно ассоциировать с его входными и выходными параметрами объекты вызывающего алгоритма, выполнять вычислительную работу с учетом предписанных ассоциаций и возвращать результаты расчета в выходные параметры вызывающего отношения.

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

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

1. Если внутренняя структура алгоритма известна, то формальная процедура может «разделить» такой алгоритм на независимые части, в каждом из которых она выделит свои группы взаимосвязи входных и выходных параметров, а следовательно, и позволит сформировать несколько различных описаний отношений на основе одного и того же алгоритма. Тогда процедура исполнения вычислительной работы алгоритма не претерпевает изменения, поскольку она по-прежнему обслуживает только простые отношения (рис. 6).

Рис. 6. Иллюстрация принципа декомпозиции сложного отношения

2. Не принимая во внимание внутреннюю структуру вызываемого алгоритма, можно игнорировать избирательную зависимость его выходных параметров от входных и считать такое отношение простым. В этом случае процедура исполнения вычислительной работы алгоритма опять же остается без изменения, поскольку она по-прежнему обслуживает «принудительно» объявленное простое отношение.

3. Если считать отношение сложным, то в этом случае по отношению к нему становится возможным прямо или косвенно установить взаимосвязь его выходных параметров с его же входными параметрами при одном условии: такая взаимосвязь не должна приводить к образованию циклической зависимости объектов в вызывающем алгоритме от самих себя (рис. 4). Естественно для формального доказательства отсутствия такого факта структура алгоритма должна быть либо открытой, либо описание его входных и выходных параметров должно быть дополнено соответствующей информацией. Третий способ является мощным средством для создания открытых функциональных комплектов, скрывающих в себе реализацию какого-либо сложного метода и настраиваемого на конкретное применение за счет включения в «обратную связь» некоторого внешнего регулирующего геометрического построения (рис. 7). Однако приведенная ранее процедура выполнения вычислительной работы для такого отношения уже не может быть применена, так как одно и то же отношение будет выполнять частичную вычислительную работу многократно. Естественно, процедура выполнения вычислительной работы для отношений такого вида должна допускать такую многократность, что можно обеспечить выполняя сравнение статусов получения параметрами значений на каждой итерации в их частичном составе.

Рис. 7. Иллюстрация принципа создания функционального комплекса с открытой обратной связью

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

Комплекс, разумеется, не ограничивается набором правил, затронутых в данной статье. Он не только существенно шире, но и может пополняться квалифицированном пользователем для создания моделей с более сложным поведением. В качестве примера применения расширенных правил можно привести дискретно-непрерывные модели [5], интерпретирующие многомерные пространства на плоских картинах (в частном случае плоских) в нескольких полях. Каждое из таких полей – суть алгоритм, однако изменения, происходящие в любом из них, оказывают влияние и на другие алгоритмы модели, что изначально не предусмотрено в приведенном здесь базовом комплексе правил.

И последнее. Среда разработки геометрических моделей оставалась бы замкнутой системой, если бы не имела возможностей продуцировать отторгаемые от себя приложения. Такими приложениями, например, в Симплексе являются программы на общетехнических языках программирования, автоматически транслируемые с языка внутреннего представления геометрических моделей на эти языки. В настоящее время реализована трансляция на языки Pascal, JavaScript, MaxScript. Ведется разработка транслятора на язык программирования логических матриц VHDL. Описание полученных результатов и обсуждение новых возможностей применения конструктивного геометрического моделирования в информационных системах предполагается привести в следующих статьях цикла.

Список литературы

Короткий Виктор Анатольевич (11 марта 2019 г. 9:53)	Денис Вячеславович, позволю себе "перевести" Ваш пятый вопрос на студенческий язык. Почти немедленно после введения понятия "несобственная прямая на плоскости" и утверждения, что две параллельные прямые пересекаются в несобственной точке, внимательный слушатель легко доказывает, что все прямые на плоскости параллельны друг другу. Действительно, произвольная прямая a пересекается с несобственной прямой в несобственной точке, следовательно, прямая a параллельна несобственной прямой. По этой же причине любая другая прямая b также параллельна несобственной прямой. В силу транзитивности прямые a, b параллельны. Возможно ли найти внятный ответ нашему внимательному слушателю? С уважением, В. Короткий
Волошинов Денис Вячеславович (12 марта 2019 г. 8:41)	Здравствуйте, Виктор Анатольевич! Очень рад встрече с Вами! Благодарю Вас за комментарий! Разумеется, говорить о параллельности можно только по отношению к собственным объектам, поскольку параллельность - метрическое свойство. Любая собственная прямая проходит через одну несобственную точку, а несобственная несет на себе все бесконечно удаленные точки. Для устранения парадокса несобственную прямую надо исключать из "формального" определения параллельности прямых, проходящих через общую несобственную точку. А в проективной геометрии, где нет понятия параллельности, и проблемы нет. Когда проектируется система, в которой изначально планируется наделить все объекты единым средством представления и обработки, приходится вводить дополнительное бизнес-правило, которое контролирует появление исключительных ситуаций и запрещает выполнять какие-то действия, несовместимые со здравой логикой. Но на этом проблемы не заканчиваются. Я понимаю, что сейчас я выскажу "крамольные" мысли и я не знаю четкого ответа на них. Но я не исключаю того, что подобная ситуация имеет смысл. Допустим, у нас есть несобственная прямая. Я хочу найти прямую, параллельную данной прямой и отстоящую от нее на восемь миллиметров. Что я должен получить в ответ? Я вижу два варианта: либо опять же бесконечно удаленную прямую, либо объект с неопределенным значением (nil), сигнализирующий о том, что попытка решения состоялась, но значение функции не определено. Я больше склоняюсь ко второму варианту и объясню почему. Пусть у меня есть некоторая прямая a, значение которой мне пока не известно, но я хочу построить прямую b, которая находится на расстоянии восемь миллиметров от a. Что я получу? Разумеется, отсутствие решения для прямой b, поскольку значения у a нет. Пусть теперь я хочу построить прямую c, которая находится на расстоянии четыре миллиметра от прямой a. По той же причине построить прямую c не удастся. Но эти две неудачи не мешают ответу на следующий вопрос: каково расстояние между прямыми b и с? Для этого значение и явное присутчтвие прямой a не нужно. Если решать задачу "в лоб", то решение не получится, невозможно опереться на конкретные данные. Если же на основе анализа неполных структур данных, то решение получается за счет сокращения одной и той же переменной a.Спрашивается: если задача сформулирована по отношению к переменной a, в которую однажды попадет несобственная прямая, решение тоже будет иметь смысл или его опять же следует обозначить служебным объектом nil?
Чередниченко Ольга Павловна (13 марта 2019 г. 16:15)	В Вашей статье есть хорошая фраза "На осознание важности этих особенностей уходят годы, они не очевидны в момент начала создания системы и даже на этапе формирования и накопления ее функционального состава". Большое спасибо. Материал заставляет думать
Абросимов Сергей Николаевич (13 марта 2019 г. 23:37)	Денис Вячеславович! Добрый вечер. Создание геометрического процессора не нова, но очень притягательна. В ваших публикациях эта идея уже давно присутствует. Но к сожалению, Симплекс таковым не является, но очень интересен для разрешения целого ряда геометрических отношений и является захватывающим при подключении его к какой -либо визуализационной системе. Могу предположить,что настоящая публикация только "затравка" и надеюсь увидеть связку Симплекс- 3DSMax уже среди докладов настоящей конференции (или на очередном заседании Дома Ученых в Санкт-Петербурге). С наилучшими пожеланиями, Абросимов С.Н.
Волошинов Денис Вячеславович (14 марта 2019 г. 12:20)	Ольга Павловна! Благодарю Вас за внимание к моей работе!
Волошинов Денис Вячеславович (14 марта 2019 г. 12:30)	Сергей Николаевич! Спасибо за комментарий! Да, Симплекс - не геометрический процессор, а лишь одно из возможных средств для его создания. И еще он помогает совершенствовать геометрическую теорию, на основе которой такой процессор будет работать. Статьи про связки Симплекс-3DsMax, Симплекс-JavaScript и Симплекс-FPGA запланированы. Если хватит времени и сил, то они появятся на этой конференции, так как практические результаты уже получены и их осталось только описать. Но для того чтобы логика повествования была убелительной, потребуется завершить цикл, начатый этой статьей. Иначе будет непонятно, откуда что берется. Это еще, как минимум, две статьи. Постараюсь успеть, несмотря на надвигающуюся аккредитацию ВУЗа.