Выбор модели данных для задачи технологической подготовки производства винтовых поверхностей

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

Выбор модели данных для задачи технологической подготовки производства винтовых поверхностей

Правдин А.Л.

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

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

Генерация и использование данных в процессе проектирования

Опишем процесс технологического проектирования производства винтовых поверхностей (ТППВП, здесь и далее подразумевается процесс обработки фрезерованием). Рассматриваемый процесс основывается на модели, описанной в [3].

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

Рассматриваемый процесс, неявно выраженный в [3], уместно рассматривать с двух точек зрения:

процесс базируется на математической модели;

процесс во многом является творческим.

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

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

начальное неопределённое состояние, в котором не определено ни одного значения параметра модели;

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

конечное состояние, в котором определены значения всех параметров модели;

промежуточное состояние, более определённое чем начальное определённое положение, но менее определённое, чем конечное состояние; такое состояние может быть помечено как промежуточное решение (прототип, точка возврата).

Для того чтобы обеспечить такие требования процесса проектирования, как его непрерывность, сохранность данных, документируемость изменений, наглядность процесса, необходимо обеспечение хранения всех данных, генерируемых в процессе проектирования. Это является основной мотивацией поиска адекватного способа моделирования данных. Обозначим группы элементов данных, которые можно выделить в процессе проектирования (развивая [4]):

винтовая поверхность, профиль ВП, заготовка;

инструмент, технология обработки, профиль инструмента;

установка инструмента, параметры станка, режим обработки;

вычислитель;

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

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

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

Для лучшего понимания задачи моделирования данных определим цели моделирования. Моделирование данных процесса ТППВП преследует следующие цели:

обеспечение основы проектирования программной системы (ПС):

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

сохранение семантической информации о предметной области;

обеспечение возможности переработки ПС на основе имеющейся структуры;

создание структуры данных, воспроизводимых в вычислительной системе (создание каркаса ПС):

приведение элементов данных к типам, пригодным для компьютерной обработки (КО);

перегруппировка элементов данных для удобства КО;

выявление связей между элементами данных, группами элементов данных и их преобразование в зависимости, пригодные для КО;

проектирование структур данных, пригодных для долговременного хранения информации.

Из структуры целей следует условное разбиение моделирования минимум на 2 уровня: сохранение семантической структуры данных предметной области и проектирование отображения данных в конкретной ПС. Разделение на уровни при моделировании данных первоначально было предложено и закреплено в архитектуре ANSI / SPARC [5]. На сегодняшний день укрепилась модель двухуровневого разделения: логический и физический уровень, которую можно проследить на примере реализаций компиляторов, виртуальных машин, а главное -- при моделировании предметной области в различных системах, с помощью, например, UML. Однако в применении 2-х уровневого разделения кроется проблема: для обеспечения лёгкого преобразования моделей одного уровня в другой, модели, которые должны содержать семантику, делаются максимально приближенными к моделям, реализованным в ПС. В результате всё множество семантических связей преобразуется в ассоциацию и наследование. Даже при использовании OCL или шаблонов объектно-ориентированного проектирования часть семантики остаётся вне построенных схем и ограничений, т.е. во многом подобная практика пропагандируется используемыми технологиями.

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

Попытаемся выявить технологию моделирования, наиболее адекватно подходящую для сохранения семантики процесса ТППВП.

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

Реляционная модель, модель, подразумеваемая языком SQL, исходная модель «сущность-связь» - все они подвергаются критике за семантическую перегруженность связей и нормальные формы -- требование преобразования любых групп элементов данных в отношения [7,8]. Важный момент в сравнении указанных моделей с объектной моделью -- указание на пассивность данных: семантика при применении объектного подхода сохраняется при помощи реализации поведения объектов класса.

Семантические модели данных, расширенная модель «сущность-связь», модель данных, подразумеваемая языком OQL, могут быть использованы для сохранения семантики, однако не удовлетворяют современным требованиям по многообразию типов данных и связей между сущностями [7]. В этом смысле намного большие возможности предоставляет UML [1,9], однако это средство также имеет свои недостатки, к которым можно отнести:

малую связность диаграмм (сложность восстановления системы по набору диаграмм); генерируемый винтовой поверхность фрезерование

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

привязку моделирования структуры данных к её представлению в ПС.

Следует отметить такие технологии быстрого моделирования (agile process), как CRC, ORM и другие [10]. Например, технология ORM предоставляет достаточно обширный набор элементов для обозначения взаимодействий объектов и ограничений на эти взаимодействия. При этом технология не диктует явного способа программной реализации.

Наиболее современной тенденцией, касающейся моделирования данных, является разработка, основанная на моделях (MDD) [9]. Суть её применения заключается в создании моделей, по которым работает ПС и по которым она может быть реализована (сгенерирована). Такая технология требует языка, в полной мере сохраняющего семантику предметной области. Используются языки независимые и зависимые от реализации (PIM, PSM), т.е. реализуется 2-х уровневое моделирование. За основу такого языка может быть взят UML, но расширенный и специализированный под конкретную задачу ([11], MDA). Подобная технология напоминает структуру лингвистического обеспечения САПР, в которой выделяют язык проектирования, с помощью которого создаются описания будущего изделия. При этом реализация изделия в конечном итоге является процессом постепенной формализации и уточнения исходного описания.

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

Предложения по улучшению

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

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

В процессе проектирования происходит активное порождение данных (например, вычисление графиков функций, генерация новых состояний). Целесообразно создать связь, отображающую этот вид взаимодействия. Например, тот же метод класса «Вычислитель» создаёт новый объект класса «Выходной график». В UML это отображается на диаграмме классов только связью, отображающей конечное состояние элементов: ассоциацию (рисунок 1.в). Более информативна будет схема, представленная на рисунке 1.г, где показаны связи порождения и владения для нового объекта в результате выполнения конкретной операции. Связь порождения относится к конкретному методу, связь владения - к классу. В данном случае связь порождения и владения объектом идёт от одного класса «Вычислитель», в общем случае связи идут от разных классов. Схему также имеет смысл представить на отдельной диаграмме «создание объектов при вызове метода «Вычислитель» - «Вычислить толщину срезаемого слоя». Аналогично можно предложить связи вида «причина-результат».

Каждое последующее состояние проектного решения является, по сути, одним и тем же объектом, только имеющим другое состояние. Состояния объекта между его дискретными изменениями можно рассматривать как версии объекта. Невозможно отобразить на схеме всю историю изменений объекта, но важно отобразить возможные изменения его состояния. С использованием UML можно отобразить только стационарные связи между взаимодействующими элементами (рисунок 1.в). Более информативным будет отображение изменений в состоянии связанных элементов данных (рисунок 1.д). Указывается метод, вызвавший изменения, и сами изменения в некоторой форме (на рисунке N и N+1 на связи). Создаётся новая диаграмма «изменение состояния при вызове метода «Вычислитель» - «Вычислить толщину срезаемого слоя».

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

Рисунок 1 - Иллюстрация предложенных улучшений графической нотации

Заключение

Наиболее адекватным методом моделирования данных процесса ТППВП является специализированный язык, основанный на общепринятом стандарте UML. Идея специализированного языка происходит из разработки, основанной на моделях.

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

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

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

Литература

1. Кватрани, Т. Визуальное моделирование с помощью Rational Rose 2002 и UML. [Текст]: [пер. с англ.] / Кватрани Т.. М.: Издательский дом "Вильямс", 2003. - 192 с.: ил. - Парал. тит. англ.

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

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

4. Правдин, А.Л. Анализ требований к интерактивной подсистеме АСТПП расчёта технологических параметров лезвийной обработки винтовых поверхностей [Текст] / А.Л. Правдин, С.И. Брусов // Известия ОрелГТУ. Серия «Фундаментальные и прикладные проблемы и технологии: информационные системы и технологии». - Орел : ОрелГТУ, - 2007. - №4/268 (535). - С. 72-82.

5. Коннолли, Т.. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. [Текст] : [пер. с англ.] : Уч. пос./ Коннолли Т., Бегг К., Страчан А.. Издательский дом «Вильямс», 2000. - 1120 с. : ил. - Парал. тит. англ.

6. Корягин, А. Другой взгляд на базы данных [Текст] / Корягин А. // SoftLine direct №1 - 2006. с.38-39.

7. Кузнецов, С.Д. Базы данных. Модели и языки. [Текст] / Кузнецов С.Д. М.: Бином-Пресс, 2008 г. 720 с. ил., ISBN 5-9518-0232-6.

8. Margo Seltzer. Beyond Relational Databases: There is more to data access than SQL, ACM Queue, Vol. 3, No. 3 - April 2005.

9. Кузнецов, С.Д. Обещания и просчеты UML 2.0. [Электронный ресурс] / Кузнецов С.Д.

10. Scott W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process / John Wiley & Sons, ISBN#: 0471202827

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