Размещено на http://www.allbest.ru/

Анализ требований к интерактивной подсистеме АСТПП расчёта технологических параметров лезвийной обработки винтовых поверхностей

Правдин А.Л., Брусов С.И.

• This article is devoted to analysis of requirements to interactive program system for calculation technological parameters of milling of helix surfaces. The requirements are classified. All particular requirements are analyzed in context of common requirements: modifiability and integrability. Possible realization of the requirements, in particular, requirements to user interface, are reviewed.


Введение

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

Прикладная значимость работы определяется анализом требований к интерактивной программной подсистеме (ПС) АСТПП, производящей расчёт технологических параметров лезвийной обработки винтовых поверхностей. За основу взята модель комплексного анализа параметров лезвийной обработки винтовых поверхностей, представленная в работе [3]. Модель позволяет рассчитать шероховатость поверхности, силы резания и другие характеристики технологического процесса по известной конструкции и конфигурации профиля режущей части дискового режущего инструмента.

Классификация требований

Основанием классификации требований к проектируемой ПС являются различные аспекты определения АСТПП. Проектируемая ПС является частью АСТПП, реализующей её функции, что делает возможным применение данной классификации. В зависимости от точки зрения, АСТПП является:

- составной частью АСУП;

- инструментом технолога при проектировании;

- программной системой.

Первый аспект определения подразумевает необходимость интеграции любой вспомогательной подсистемы АСТПП, во-первых, с основными её подсистемами, а во_вторых, согласование интерфейсов АСТПП и АСУП. Требования, связанные с данной интеграцией, назовём требованиями интеграции. Использование АСТПП в качестве инструмента технолога выявляет требования, определяемые логикой и моделью проектирования. Представление АСТПП в виде программной системы порождает специфические требования к её реализации.

Человек принципиально не может быть исключён из процесса проектирования, следствиями чего являются:

- изменчивость требований к системе;

- неполное определение логики и вероятностный характер модели проектирования.

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

Далее рассмотрим три указанных выше класса требований, обращая внимание на их реализацию в контексте модифицируемости.

Требования интеграции

АСТПП является частным случаем системы технологической подготовки производства (СТПП), которая является одной из трёх стадий процесса технической подготовки производства: научно-исследовательской, конструкторской и технологической [11 стр. 346]. Результаты технологической подготовки производства напрямую влияют на технологические процессы, происходящие на предприятии, отвечая на два вопроса: что и как производить. СТПП имеет двунаправленные связи с конструкторской подготовкой производства и непосредственно с производством. Входной информацией от конструкторской подготовки производства является конструкторская документация, выходной информацией является анализ технологичности изделий. Результаты ТПП в виде технологической документации внедряются в производство, обратной связью является анализ эффективности технологических процессов, который может приводить к модификации моделей, принятых при ТПП. Ещё одной внешней связью СТПП является входная нормативная и справочная информация. интерактивная подсистема лезвийная обработка

На АСТПП и её основные подсистемы возлагается определённый набор функций [17 стр. 109, 16 стр. 11] . Отметим те из них, выполнение которых непосредственно связано с функционированием рассматриваемой нами подсистемы:

- определение вида обработки / выбор оборудования и оснастки;

- определение рациональных методов обработки;

- расчёт параметров инструмента / проектирование специального инструмента;

- разработка рекомендаций по изменению производственной системы с целью повышения эффективности производства;

- разработка рекомендаций по модификации изделия с целью повышения его технологичности.

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

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

Требования логики проектирования

Использование целевой ПС в качестве инструмента проектировщика требует определения следующих элементов системы:

- сущностей, с которыми явно или неявно работает проектировщик;

- процессов, которые составляют сущность проектирования;

- режимов взаимодействия человека и системы, которые служат основой выявления процессов, выполняемых при проектировании.

В данной работе мы не будем детально анализировать процессы и сущности предметной области, а только выделим общие закономерности.

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

Проектирование начинается с синтеза структуры технологического процесса исходя из технического задания. Исходный вариант структуры генерируется, а затем оценивается с позиций возможности обеспечения заданных параметров, качества изделия (требование работоспособности). Для каждого варианта структуры производится оптимизация параметров. Если для некоторого варианта структуры технологического процесса операции или технологического перехода обеспечиваются заданные параметры качества изделия, то задача синтеза для данного элемента технологического процесса считается законченной [10].

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

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

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

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

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

- показателей функции оптимальности;

- нарушений априорных ограничений;

- визуализации общего возможного состояния объекта проектирования.

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

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

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

Рисунок 1 - Элементы процесса проектирования с использованием модели комплексного анализа параметров лезвийной обработки винтовых поверхностей

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

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

Использование АСТПП в качестве инструмента проектировщика, помимо выделения сущностей и процессов, поднимает вопросы, связанные с режимами взаимодействия человека и системы. Здесь возникают такие задачи, как: выбор языка взаимодействия человека и системы, организация диалога, которые являются частными задачами построения пользовательского интерфейса системы и будут рассмотрены далее.

Требования к программной системе

На рынке информационных систем существует объективная тенденция: при выборе системы снижается влияние фактора предоставляемой ею функциональности и увеличивается влияние фактора интегрируемости системы с другими системами [8]. Тенденция имеет место, несмотря на то, что эффективное решение проблемы интеграции найдено только для частных случаев взаимодействия систем [12]. При этом подразумевается, что достижение требуемой функциональности - вопрос времени, т.е. система обладает свойством модифицируемости, что делает возможным её развитие в соответствии с требованиями пользователей. Отсюда можно сделать вывод, что два базовых требования к современной программной системе - это:

- интегрируемость;

- модифицируемость.

Современный подход к реализации требования интегрируемости - сервисно-ориентированная архитектура (SOA), которая подразумевает определение всех функций системы, как набора независимых сервисов (компонентов), обращение к которым в определённой последовательности позволяет реализовать тот или иной бизнес-процесс [7]. Подход подразумевает наличие интеграционной платформы, на основе которой разрабатываются сервисы и использующие их прикладные системы.

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

- единственности определения системы и данных;

- поддержки правил и ограничений прикладной области;

- непротиворечивости представления данных (целостность связки «модель - пользовательский интерфейс»);

- сохранности данных;

- открытости интерфейсов;

- модифицируемости модели, которая выражается в определённых структурных требованиях;

- ориентации на пользователя, структуру его представлений о предметной области и изменения этой структуры;

- документирования модификаций.

Рассмотрим возможные подходы к реализации поставленных требований.

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

Единственность определения данных играет важную роль в реализации многих требований. Автором установлено, что при определении прототипа интерактивной системы, реализующей базовые требования (определение пользовательского интерфейса, обеспечение сохранности данных и др.) на языке высокого уровня, внедрение каждого нового параметра в модель должно быть отражено примерно в 10 подпрограммах. Подобное определение является рутинной работой при создании системы и служит потенциальным источником ошибок. Реализация единственности определения данных подразумевает:

- централизованное описание уникальных операций над параметрами модели;

- механизм генерации общих операций с параметрами модели;

- механизм трансляции определений параметров в необходимые действия системы.

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

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

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

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

- языка взаимодействия человека и системы;

- элементов пользовательского интерфейса;

- структурных связей между моделью и ПИ;

- логики диалога.

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

Элементы пользовательского интерфейса служат визуальным отображением элементов модели и являются, по сути, интерфейсными точками системы с пользователем. Эти элементы должны принимать данные от пользователя и отображать состояние элементов модели, с которыми они сопоставлены. Обобщением данной идеи является понятие интерактора [6]. Множество элементов ПИ должно быть структурировано таким образом, чтобы их взаимосвязи отражали взаимосвязи между элементами модели, которые они представляют.

Связи между моделью и ПИ необходимы для обеспечения доступа к её элементам. Ввиду возрастающей сложности моделей, связи структурируют в соответствии с определённым методом, который определяется, например, моделями MVC, PAC [5].

Любое взаимодействие человека с системой подразумевает диалог - обмен информацией, наличие обратной связи. Выделяют пассивный (ведёт система) и активный (ведёт человек) виды диалога; директивную, табличную, фразовую и объектно-ориентированную формы диалога [2]. Понятие диалога трансформировалось в связи с ростом производительности вычислительных систем. Если ранее выделялся лишь диалоговый режим, который было целесообразно применять для решения задач, подразумевающих непосредственное участие человека, то теперь человек полностью управляет процессом проектирования. Это позволяет эффективно реализовать разделение функций между системой и человеком, однако представляет значительные сложности при проектировании. Определение логики диалога является наиболее проблемной частью определения ПИ, т.к. на сегодняшний день не существует проработанной методологии определения диалога, отвечающей следующим требованиям:

- формальной определённости;

- удобства эксплуатации;

- поддержки структур ПИ достаточной сложности.

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

При реализации проектируемой нами целевой ПС требуется не только реализовать ПИ, но и обеспечить его модифицируемость. Модифицируемость ПИ можно разбить на несколько уровней по глубине изменений - от настройки вида и поведения конкретных элементов до глубокой перестройки. При наличии ПИ, жёстко привязанного к определению модели, изменение модели ведёт к значительным изменениям в ПИ. Реализовать требование модифицируемости ПИ в этом случае можно, ослабив указанную связь, например, имея централизованное формальное описание ПИ и систему его генерации по описанию. Следует отметить, что подобные исследования ведутся [9, 20], предложено множество вариантов, однако остаются нерешёнными многие вопросы, такие, как удобство использования, стандартизация, проблемы обратного проектирования, соответствия друг другу описаний различных уровней ПИ.

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

- оптимальность логики диалога - возможность выполнять элементы взаимодействия человека и системы, используя минимум элементарных операций;

- декомпозиция ПИ - баланс между избыточностью и необходимым минимумом предоставляемой пользователю информации на каждой стадии диалога;

- реализация элементарных элементов ПИ - интеракторов [6];

- поддержка возможностей современных устройств ввода-вывода.

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

Последний рассматриваемый нами аспект требования модифицируемости - сохранность данных - означает, что любые данные, введённые пользователем, сохраняются в системе в непротиворечивом состоянии на всё время работы с моделью. Необходимо сохранять:

- определения модели и пользовательского интерфейса;

- настройки системы;

- предпочтения пользователей в процессе проектирования (историю выборов проектных решений из набора допустимых);

- изменения параметров модели, их структур и взаимосвязей, получаемых в процессе проектирования (хранение дерева вариантов).

Это позволит обеспечить непрерывность процесса проектирования вне зависимости от сеансов работы, а также даст проектировщику материал для совершенствования модели и методов работы с ней. Реализация требования модифицируемости подразумевает, что любые хранимые структуры данных не должны быть определены статично, необходима возможность изменения набора хранимых данных для каждой структуры. Для хранения комплексных данных хорошо подходят объектно-ориентированные базы данных (ООБД) [13]. Специфика рассматриваемой области дополнительно к стандартным возможностям ООБД налагает требования ведения версий объектов и динамического формирования множества атрибутов, что может быть реализовано в рамках объектного подхода [15, 1].

Заключение

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

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

Установлено наличие тесной взаимосвязи между всеми элементами интерактивной системы:

- все элементы системы определяются структурой модели;

- логика проектирования детализируется логикой диалога;

- пользовательский интерфейс является отражением самой модели и логики проектирования.

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

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

Литература

1. Андреев, А.М. Внутренняя организация ОСУБД на примере Versant, Poet, ODB-Jupiter [Электронный ресурс] / А.М. Андреев, Д.В. Березкин, Р.С. Самарев // Электронное издательство «Интелтек». - Режим доступа: http://www.inteltec.ru/publish/articles/objtech/cordb.shtml, свободный. - Загл. с экрана.

2. Артемьев, В.И. Организация диалога в САПР: практ пособие [Текст] / В.И.Артемьев, В.Ю.Строганов под ред. А.В.Петрова. - Разработка САПР в 10 кн. Кн. 5. // М.: Высш. шк., 1990. - 158 с.: ил. ISBN 5-06-000742-1

3. Брусов, С.И. Комплексный анализ параметров лезвийной обработки винтовых поверхностей. [Текст] / С.И. Брусов, А.С. Тарапанов, Г.А. Харламов под ред. А.С. Тарапанова. - М.: Машиностроение-1, 2006. - 128 с.: ил. ISBN 5-94275-248-6.

4. Гамма, Э. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. [Текст] / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес / СПб: Питер, 2001. - 368 с.: ил. ISBN 5-272-00355-1.

5. Гордиенко, А.П. Модели графического пользовательского интерфейса [Текст] // Гордиенко А.П. Вестник МЭИ.- 2003.- № 2.- С. 83-90.

6. Гордиенко, А.П. Построение графического пользовательского интерфейса в виде иерархии интеракторов. [Текст] // А.П. Гордиенко Актуальные вопросы построения информационных систем: Материалы международной научно-технической конференции «Информационные технологии в науке, образовании и производстве» (ИТНОП). Том 5. - Орёл: изд-во ОрёлГТУ, 2004, - С. 110-116

7. Дубова, Н. SOA: подходы к реализации. [Электронный ресурс] / Открытые системы 2004, №6 // Режим доступа: http://www.osp.ru/os/2004/06/184450/, свободный. - Загл. с экрана.

8. Интеграционные платформы: молодые, но амбициозные. [Электронный ресурс] / Intelligent enterprise Корпоративные системы 2006, №23(155) // Режим доступа: http://www.iemag.ru/?ID=621265, свободный. - Загл. с экрана.

9. Конюхова, О.В. Графический пользовательский интерфейс для автоматизированных систем раскроя изделий сложной формы [Текст] : // О.В. Конюхова Автореферат дис. к.т.н.-Орёл, 2006.-20 с.

10. Корсаков, В.С. Автоматизация проектирования технологических процессов в машиностроении. [Текст] / В.С. Корсаков, Н.М. Капустин, К.Х. Темпельгоф, Х. Лихтенберг под общ. ред. Капустина Н.М. - М.: Машиностроение, 1985. - 304 с., ил.

11. Паничев, М.Г. Организация и технология отрасли [Текст] / М.Г. Паничев, С.В. Мурадьян - Ростов-на-Дону: Феникс, 2001. - 448 с.: ил. ISBN 5-222-01663-3.

12. Потапова, Т.Б. Интеграция АСУТП и АСУП. [Текст] // Т.Б. Потапова Материалы международной научно-технической конференции «Информационные технологии в науке, образовании и производстве» (ИТНОП). - Орёл: изд-во ОрёлГТУ, 2004, Том 1. - С. 49-53.

13. Правдин, А.Л. Аспекты построения системы управления объектно-ориентированными базами данных [Текст] // А.Л. Правдин Актуальные вопросы проектирования и внедрения распределённых телекоммуникационных систем и структур управления: Материалы международной научно-технической конференции «Информационные технологии в науке, образовании и производстве» (ИТНОП). - Орёл: изд-во ОрёлГТУ, 2006, Том 4. - С. 174-179.

14. Семенков, О.И. Автоматизация проектно-конструкторских работ и технологической подготовки производства в машиностроении. Том 1. [Текст] / под общ. ред. О.И. Семенкова - Минск.: Вышейшая школа, 1976. - 352 с.: ил.

15. Спандерашвили, Д.В. Объектная модель темпорально многомерных данных и её реализация средствами реляционной СУБД [Текст] // Д.В. Спандерашвили Актуальные вопросы проектирования и внедрения распределённых телекоммуникационных систем и структур управления: Материалы международной научно-технической конференции «Информационные технологии в науке, образовании и производстве» (ИТНОП). - Орёл: изд-во ОрёлГТУ, 2006, Том 4. - С. 210-215.

16. Узилевский, Г.Я. Начала эргономической семиотики: монография [Текст] // Г.Я. Узилевский Орёл: издательство ОРАГС, 2000. - 408 с. - список лит.: 727 назв. ISBN 5-93179-008-X

17. Шалаев, П.А. Состояние и перспективы развития автоматизации подготовки производства в машиностроении [Текст] / П.А. Шалаев Автоматизация технологического проектирования: сб. статей, серия «Опыт внедрения ЕСТПП», выпуск 5 // М.: Издательство стандартов, 1977. - с. 3- 20.

18. Alexander H. Formally-based tools and techniques for human-computer dialogues. New York: John Willey & Sons, 1987.

19. Myers B.A. Why are Human-Computer Interfaces Difficult to Design and Implement? // Carnegie Mellon University School of Computer Science Technical Report, no. CMU-CS-93-183 July 1993.

20. Paulo Pinheiro da Silva: User Interface Declarative Models and Development Environments: A Survey. [Текст] / Interactive Systems: Design, Specification, and Verification, 7th International Workshop DSV-IS, Limerick, Ireland, June 5-6, 2000. pp. 207-226.

Размещено на Allbest.ru