CC BY
77
построения иерархической структуры ветвления.
• Rules и Ruleset (правила и наборы правил), позволяют организовать простую проверку значений атрибутов, а в случае соответствия выбрать определенное решение.
• Score Models (Скоринговая модель) реализовывает поддержку в системе базовых скоринговых таблиц, при этом доступны два варианты вычисления - по аддитивному методу и методу, основанному на логистической регрессии [4].
При помощи данных элементов можно достаточно гибко настроить вычислительный процесс при принятии решения, при этом построенный процесс будет обладать большими запасами масштабируемости. Таким образом, появляется возможность создавать большое количество необходимых бизнес продуктов, используя однотипные вычислительные элементы.
Литература
1. Соглашение Базель II (International Convergence of Capital Measurement and Capital Standards), §417 / URL: http://www.bis.org/publ/bcbs107.pdf (дата обращения: 11.11.2011).
2. Fair Isaac / URL: http://www.fico.com/en/Pages/default.aspx (дата обращения: 11.11.2011).
3. Turban, E. Decision support and expert systems: management support systems. - Englewood Cliffs, N.J.: Prentice Hall, 1995.
4. Князев О.В. “ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ ЭКОНОМИЧЕСКИХ И ТЕХНИЧЕСКИХ РЕШЕНИЙ”, Сборник трудов Второй Международной научно-технической конференции «Компьютерные науки и технологии» (КНиТ-2011), Белгород, 2011. ISBN 978-5-902583-64-6.
УДК 519.685
ПРОЕКТИРОВАНИЕ СЕМАНТИЧЕСКОГО СЕРВИСА ДЛЯ АВТОМАТИЗАЦИИ
ВЕРСТКИ ВЕБ-САЙТОВ1
Грегер Сергей Эдуардович, доцент, Уральский федеральный университет имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (филиал), Россия,
Нижний Тагил, [email protected]
Пономарёва Александра Сергеевна, студентка, Уральский федеральный университет имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (филиал),
Россия, Нижний Тагил
Шаламов Максим Вячеславович, студент, Уральский федеральный университет имени первого Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (филиал), Россия,
Нижний Тагил
Введение
В связи с широким развитием «Всемирной паутины» процесс создания сайтов постоянно модернизируется. Современная веб-разработка всё дальше уходит от императивной разработки к декларативной. В связи с этим разрабатываются новые удобные и менее времязатратные методы разработки, такие как использование фреймворков и cms, используются новые подходы и концепции, например, семантические сети, использованию которых мы и уделим внимание в этой статье.
Для начала вспомним один из возможных циклов разработки сайта, опуская тонкости типа итеративной разработки и т.д.
1. Постановка задачи.
2. Создание прототипа приложения.
3. Создание интерфейса приложения (дизайн + вёрстка).
4. Создание функционала сайта.
1 Лауреат номинации "Лучший доклад по UML-моделированию". Авторы доклада награждаются книгой Иванова Д.Ю. и Новикова Ф.А. "Моделирование на UML. Теория, практика, видеокурс" (www.umlmanual.ru) с автографами авторов
34
Рассмотрим подробнее третий этап. На основе прототипа и требований клиента дизайнер рисует макет, передавая свою работу, чаще в виде psd-шаблона, верстальщику, который преобразует ее в HTML+CSS. Процесс вёрстки на сложных макетах занимает длительное время.
В своей работе мы хотим описать вариант автоматизации этого процесса.
1. Определение предметной области
Поставленную задачу можно решать различными способами. В нашей статье мы бы хотели изложить подходы к решению задачи с точки зрения семантических сетей. Семантическая сеть (англ. Semantic Web) — это направление развития Всемирной паутины, целью которого является представление информации в виде, пригодном для машинной обработки.
Рассмотрим также одно из основных понятий семантической сети - онтологии. Можно сказать, что онтология — это точная спецификация некоторой области, которая включает в себя словарь терминов этой области и множество логических связей (типа «элемент-класс», «часть-целое»), которые описывают, как эти термины соотносятся между собой[4].
Прежде чем говорить о реализации, нужно описать предметную область задачи. Для этого создадим онтологию, представленную в виде семантической сети.
На данной схеме показана структура концептов и отношений между ними.
Первым концептом является Page - страница, она может быть представлена как psd-макетом (Template - отображение), так и вёрсткой (Code - готовый html + css код).
Концепт Template может быть разбит на множество блоков (block), которые будут иметь определённые атрибуты:
• type - тип;
• location - местонахождение, из которого мы сможем получить координаты блока X и Y;
• view - вид, атрибутами которого будут цвет фона (backgroubd), высота (height) и ширина (width) блока.
Данный набор концептов позволяет нам описать схему разбиения заданного макета на блоки, для последующего преобразования в HTML код с наложением CSS стилей. Перейдём к описанию части, которая будет производить эту обработку.
35
Концепт Code и все его наследующие концепты позволяют нам преобразовать полученный набор блоков в требуемую вёрстку.
• HTML и CSS концепты служат базовыми для описания всех возможных вариантов кода;
• PseudoElement - псевдо элементы;
• PseudoClass - псевдо классы;
• cssStyle - стили CSS;
• div - блоки;
• select - элемент формы список;
• img - изображения страницы;
• link - ссылки;
• form - формы;
• input - элементы форм;
• textarea - элементы форм.
В связи с постоянным изменением стандартов HTML и CSS приведенный список будет постоянно дополняться и изменяться.
Уже на данном этапе очевидно, что процесс разбиения шаблона на блоки и преобразование этих блоков независимы. Реализовать описанную задачу наиболее эффективно можно в виде семантического веб-сервиса. Семантический вебсервис (англ. Semantic Web Services, SWS; иногда Semantic Web Web Services, SWWS) — законченный элемент программной логики с однозначно описанной семантикой, доступный через Интернет и пригодный для автоматизированного поиска, композиции и выполнения с учетом его семантики. Однако ничто не мешает нам разделить эти задачи на два независимых сервиса, которые смогут обрабатывать результаты друг друга. В итоге мы получим большую гибкость и возможность использования различных языков, платформ и инструментов для реализации сервисов[2][3].
2. Анализ требований к системе
После описания предметной области нам необходимо определиться с требованиями к системе, которые можно наглядно представить в виде диаграммы вариантов использования, приведенной ниже.
Как видно из диаграммы, в системе имеются две независимые части. Первая выполняет разбиение psd-шаблона на блоки, вторая - преобразуется получившийся шаблон в HTML+CSS код. Каждая из этих подсистем может возвращать готовый результат пользователю и передавать его в виде семантической структуры другой системе.
В данной схеме мы выделили два подсервиса, но, как мы писали, выше их можно реализовать как два независимых сервиса. Более того вариант с двумя независимыми сервисами будет более предпочтительным, ввиду уже отмечавшихся преимуществ данного подхода.
3. Проектирование сервиса
Основываясь на предметной области и поставленной задаче, необходимо спроектировать структуру классов, которые будут представлять собой реализацию сервиса. Имея UML-диаграмму классов, можно сгенерировать каркас сервиса с помощью соответствующих средств. Например, для CMS Plone это можно сделать с помощью ArgoUML и ArchGenXML[1]. Диаграмма, приведенная нами, выполнена в VisualStudio 2010, которая также дает возможность генерации кода на основе диаграммы классов.
36
Рис. 2 - Диаграмма вариантов использования
Рис. 3 - Диаграмма классов: 1 - схема хранения онтологии, 2 - сервис разбиение psd-шаблона, 3
сервис преобразования в HTML-CSS
Схема хранения онтологии, используемая для данного сервиса, заимствована из публикации [5], и поэтому мы не будем приводить её в нашей работе. На диаграмме классов схематично обозначим её классом Ontology.
Классы, реализующие интерфейс IUserInterface, служат для взаимодействия сервиса с пользователем. С их помощью происходит загрузка картинки и проверка правильности разбиения блоков. Также они используются классы Errors и Answers для передачи ошибок и сообщений пользователю.
37
Классы, реализующие интерфейс IPage, служат для представления загруженной страницы в виде разбитого на блоки шаблона и шаблона HTML. Его реализуют классы TPL, класс для работы с шаблоном, разбитым на блоки, и класс HTML для работы с HTML-шаблоном.
Классы, реализующие интерфейс ICreateTPL, служат для создания шаблона, разбитого на блоки, из полученных от пользователя данных. Они получают данные от классов реализующих интерфейс IUserInterface, а в результате создают класс TPL.
Классы, реализующие интерфейс IConversion, служат для конвертации шаблона, разбитого пользователем на блоки и преобразованного классом CreateTPL в семантическую структуру, в семантическую структуру HTML-шаблона. Они обрабатывают класс TPL, преобразуя его в класс HTML и передавая семантические данные в базу хранения онтологии.
Классы, реализующие интерфейс IRepository, служат для работы с хранилищем онтологии. Каждый класс служит для работы с конкретными системами. В диаграмме это показано на примере работы с Plone. Благодаря такому подходу становится возможным использовать любое другое хранилище или любую другую онтологию.
Данную схему мы прекрасно можем реализовать в рамках единого сервиса. Но мы опишем её более универсальное применение. На схемы мы веделили 3 подсистемы (независимых сервиса):
• хранилище онтологии, к которому имеют доступ оба реализуемых сервиса;
• сервис для разбиения шаблона на блоки;
• сервис для создания HTML+CSS кода на основе данных, полученных от сервиса разбивки шаблонов.
Итак, что мы получаем от такой реализации:
• независимость от конкретного хранилища онтологий. Хоть мы и рассматриваем конкретную реализацию хранилища в cms Plone, однако для наших сервисов это не существенно. Главное чтобы в хранилище содержалась нужная онтология и была возможность сделать запросы, удовлетворяющие интерфейсу IRepository.
• Проектируемые нами сервисы обмениваются сообщениями в формате xml, а также взаимодействуют с удалённым хранилищем. Благодаря этому они могут быть реализованы на несовместимых технологиях и различных платформах.
• Классы, отвечающие за взаимодействие, не внесены ни в один сервис, потому что должны поддерживаться всеми.
4. Описание полученного результата
На основе приведенной схемы строим сервис, или группу сервисов, имеющих следующий функционал:
• загрузка данных в виде psd-шаблона;
• интерфейс разбиения загруженного шаблона на блоки: пользователь видит перед собой картинку шаблона, слои, которые содержаться в этом шаблоне, а так же инструменты для разбиения, позволяющие выделить область формы, блока, кнопки и других частей шаблона, а также задать им необходимые параметры (положение, размеры, слои, используемые для выделенной области и т.д.);
• представление данных, полученных от пользователя (psd-шаблона, разбитого на блоки), в виде семантической сети и передача её в формате XML другому сервису или подсервису;
• получение семантической сети разбитого на блоки шаблона в виде XML от подсервиса или стороннего сервиса и преобразование его в семантическую структуру HTML-шаблона;
• передача семантической структуры сервиса стороннему сервису в формате XML;
• запись семантической структуры в базу хранения онтологии;
• выдача семантической структуры пользователю в виде HTML-шаблона.
38
Выводы
В результате решения поставленной задачи получаем сервис, принимающий psd-шаблон и возвращающий семантическую структуру HTML-шаблона, которая может быть использована другими сервисами для дальнейшего создания сайта.
Приведенная онтология может являться спецификацией для описания предметной области, как рассмотренной задачи, так и других задач связанных с веб-разработкой.
Приведённое решение отлично подходит как для единой системы, так и для распределённой.
Литература
1. Грегер С.Э. Сервер приложений «Zope». Учебное пособие для вузов
М.:Горячая линия - Телеком, 2009.-256 с.:ил.
2. Jorge Cardoso. Semantic Web Services: Theory, Tools, and Applications. INFORMATION SCINCE REFERENCE. Hershey. New York. 2007.
3. Leonard Richardson, Sam Ruby. RESTful Web Services. O’REILLY. 2007.
4. А.Я. Гладун, Ю.В. Рогушина, журнал "Корпоративные системы" (№1, 2006) Онтологии в корпоративных системах часть 1
5. Грегера С.Э., Сковородина Е.Ю. Построение онтологического портала с использованием объектной базы данных // Объектные системы - 2010: Материалы I Международной научно-практической конференции. Россия, Ростов-на-Дону, 10-12 мая 2010 г / под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2010. С. 74-78
УДК 004.04
МЕТОДИКА ПОДБОРА ОСНАСТКИ ДЛЯ ФРЕЗЕРНЫХ ПЕРЕХОДОВ В САПР
“TECHCARD”
Кисиль Татьяна Вячеславовна, аспирант, Южно-Уральский государственный университет, инженер-технолог, Челябинский радиозавод «Полёт», Россия, Челябинск, tatiana [email protected]
В современных САПР вопросы автоматического принятия решения представлены слабо. При выборе оснастки пользователю предлагаются реляционные таблицы для ручного выбора. Связано это с широчайшей номенклатурой оснастки и оборудования, представленных на рынке. Поэтому многие программы, такие как Спрут, T-Flex, Интермех и др., оснащены инструментарием для настройки автоматического выбора оснастки, оборудования и т.д. Но методику подбора разработчики оставляют на откуп специалистам предприятия. Хотя многие технологические решения являются типовыми и могут быть прописаны внутри системы.
На ЧРЗ «Полет» в системе Техкард разработаны условия выбора оснастки. Рассмотрим их на примере подбора инструмента для фрезерных переходов.
На этапе проектирования перехода назначается используемая оснастка в следующей последовательности: ЧТО обрабатывать; КАК обрабатывать; ЧЕМ обрабатывать; ВО ЧТО закрепить. На первом этапе определяется материал и геометрия обрабатываемой поверхности. На втором этапе - стадия обработки и используемое оборудование. Далее выбирается тип и геометрия режущего инструмента. И в завершение определяется состав инструментальной системы (вспомогательный инструмент).
Для фрезерных переходов обрабатываемые поверхности можно разделить на несколько видов. Каждому виду поверхности поставить в соответствие используемые переходы и типы инструмента (табл 1):
39
