Для поиска проектного решения применен математический аппарат генетических алгоритмов. Применение данной разновидности эволюционных методов признано наиболее подходящим по критерию ресурсоемкости в сравнении с методами полного перебора вариантов решений КР-сложной задачи, поиска по морфологическим таблицам, а также в связи с возможностью параметров иметь лингвистический характер. Хромосома, представляющая проектное решение, обладает свойством изменять длину. Данное свойство проявляется при внесении изменений в набор типов подразделов, составляющих проектное решение. Вызвано это тем, что альтернативные варианты одного типа подраздела отличаются числом параметров. Варианты различных подразделов также отличаются числом параметров.
Литература
1. Волосатова Т.М., Беломойцев Д.Е. Автоматизация процесса синтеза индивидуальных образовательных программ на основе генетических алгоритмов формирования курсов обучения. Казань: Ученые записки ИСГЗ. 2014. № 1-1 (12).
2. Норенков И.П. Генетические методы структурного синтеза проектных решений. Информационные технологии. 1998.- №1.С.9-13.
3. Норенков И.П. Эвристики и их комбинации в генетических методах дискретной оптимизации. Информационные технологии. 1999. - №1.С.3-7.
4. Беломойцев Д. Е. Разработка методики автоматизированного проектирования каналов передачи защищенных сообщений в беспроводных соединениях мобильных устройств : автореф. дис.; МГТУ им. Н. Э. Баумана. - М., 2009.
5. Беломойцев Д.Е. Методика повышения качества образования на основе анализа индивидуальных потребностей к учебным курсам и их представления в форме объектов образовательного контента. Ростов-на-Дону: Объектные системы. 2015. № 1 (10).
УДК 004.512
ОСОБЕННОСТИ РАЗРАБОТКИ КЛИЕНТ-СЕРВЕРНЫХ СИСТЕМ НА JAVA C ИСПОЛЬЗОВАНИЕМ ФРЕЙМВОРКОВ JSF И PRIMEFACES
Резанцева Екатерина Яковлевна, студентка, кафедра Стратегического планирования и методологии управления, Национальный исследовательский ядерный университет «МИФИ», аналитик, ООО «Альтарикс», Россия, Москва, erezantseva@gmail.com
Введение
В данной статье представлены промежуточные результаты разработки краудсорсинговой платформы, описаны концептуальные проблемы, с которыми столкнулись разработчики, а также возможные решения этих проблем. В основном проблемы связаны с веб-разработкой в части front-end и его интеграции с back-end.
На этапе инициации проекта было принято решение о разработке платформы с использованием объектно-ориентированного языка Java. Причин было несколько, во-первых, этот язык обладает свойствами интерпретируемости, инкапсуляции, повторного использования, в том числе на основе полиморфизма, что позволяет разрабатывать систему, когда, как в нашем случае, в процессе участвуют более пятидесяти человек с разным уровнем подготовки и без опыта в данной области. И вторая причина: у всех разработчиков в университете преподавались основы программирования на Java.
Исходя из бизнес-задач, которые должна решать данная система, была необходимость в современной, удобной и понятной визуализации с перспективой дальнейшего увеличения масштабируемости системы.
Для этого был выбран инструмент JSF PrimeFaces по критериям:
• Быстрота разработки прототипов.
• Простота в использовании для новичков.
• Наличие документации и сообщества разработчиков, использующих данный фреймворк.
• Современный внешний вид примитивов.
Среди всех возможных вариантов визуализации были отсеяны варианты с самостоятельной разработкой примитивов, так как сказывается недостаток опыта разработчиков для реализации системы в заданные сроки. При выборе фреймворка рассматривались только готовые библиотеки.
Рис. 1 - Страница «Мои проекты»
В течение последних 5 лет в сообществе разработчиков накопилось множество статистических данных по используемым фреймворкам и опыту их использования, а также по динамике этих показателей. Например, компания zeroturnaround периодически публикует сводные отчеты по продуктам, касающимся разработки на java. Так как эта компания делает инструменты для повышения производительности разработки на этом языке, ее отчеты по сравнению фреймворков представляются особенно интересными [3,4].
Анализ проблем этапа разработки
На этапе разработки мы столкнулись со следующими проблемами:
1. При усложнении структуры веб-интерфейсов системы падает скорость зарузки динамических элементов;
2. При усложнении структуры вложенности элементов (примитивов) система перестает функционировать.
3. Сложность работы с жизненным циклом объектов, осуществление особенного контроля за сессиями.
Рассмотрим каждую из возникающих проблем более подробно.
При усложнении структуры веб-интерфейсов системы падает скорость загрузки динамических элементов
Данная проблема возникает из-за того, что при разработке на JSF front-end зависит от back-end, который написан на Java и является сам по себе довольно тяжелым. Если, помимо
этого, возникает дублирование некоторых частей кода, что бывает, если используются не все возможности Java, либо некоторые элементы используются не по назначению, то это сильно влияет на производительность сервера и, соответственно, на скорость передачи ответа клиенту на запросы.
HEADER
МЕНЮ ДИНАМИЧЕСКАЯ ЧАСТЬ
Рис. 2 - Типовая страница платформы
Например, в разрабатываемой нами системе есть страница my_projects (см. рисунок 1), которая имеет довольно простую структуру. При активизации ссылки «Новых проектов (ожидающих подтверждения) N» отображается всплывающее окно с двумя кнопками, при нажатии на которые в базу заносится статус проекта: «Подтвержден» или «Отклонен», а также с кнопкой «Чат», по нажатию которой отображается всплывающее окно, содержащее чат нескольких пользователей. Данная страница весит 17,2 кб. Время ожидания браузером сервера составляет 959 миллисекунд. Время загрузки контента с сервера составляет 117,52 миллисекунд. Почти секунду браузер ждет ответа сервера.
Чем сложнее структура интерфейса, тем больше кода на back-end и больше часть не оптимизированного кода.
Эта проблема сейчас не является для нас критичной, т.к. система не эксплуатируется. Оптимизировать код необходимо до момента эксплуатации системы на этапе ее использования для взаимодействия с заказчиком.
Необходимо оптимизировать код в двух направлениях:
1. Убрать дублирующиеся элементы, возникшие из-за параллельной разработки множеством людей и невнимательной интеграции кода, убрать не использующиеся элементы;
2. Оптимизировать взаимодействие с базой данных.
При усложнении структуры вложенности элементов система перестает функционировать
Структура веб-интерфейсов в нашей системе была шаблонизирована, что позволило отделять динамические части страниц от статических, чтобы при загрузке страницы в браузере загружалась только динамическая часть. На рисунке 2 представлена типовая страница платформы, желтым обозначена неизменяемая часть, а серым - динамическая. При внедрении шаблона в шаблон, таким образом, что динамическая часть тоже делится на статичную и изменяемую, вложенная динамическая часть страницы не работала, поэтому нам пришлось полностью изменять структуру интерфейса, уйти от верхнеуровневой шаблонизации страниц. Почему возникла эта проблема? Каждый фреймворк, как и его примитивы, созданы для решения каких-то конкретных задач. При использовании готовых решений нужно понимать, что, если фреймворк не может решить какую-то задачу, придется либо подстраиваться под него, либо писать код самостоятельно. Со вторым у JSF-
разработчиков часто возникают проблемы, настройка не кастомных частей кода требует времени и дополнительных усилий, помимо тех, которые тратятся на саму разработку элементов.
Сложность работы с жизненным циклом объектов, осуществление особенного контроля за сессиями
При использовании JSF часто возникают ошибки, связанные с неправильным пониманием жизненного цикла обработки запроса, особенно, если используется AJAX. В спецификации JSF определены шесть этапов жизненного цикла:
1. Восстановление представления.
Если представление осталось с предыдущей транзакции, то оно восстанавливается, в противном случае создается новое представление по новому запросу и сохраняется новое дерево компонентов. Если запрос не требует получения каких-либо данных, то происходит переход на этап подготовки ответа к отображению.
2. Применение значений запроса.
После восстановления представления применяются значения запроса. Происходит обработка входных значений: представление готово к получению обновленных данных, пришедших от клиента.
3. Проверка правильности процесса.
На данном этапе входные значения преобразуются и производится проверка правильности данных. Если проверка прошла успешно, то жизненный цикл идет по основному пути, а если во время преобразования или проверки данных произошли ошибки, то происходит переход к фазе подготовки отображения ответа и повторно выводится та страница, с которой пришли данные, для правильного ввода данных клиентом. Из-за этого нюанса необходимо прописывать дополнительно ошибки на странице. Этот момент является специфичным и его нужно учитывать при разработке. В JSF есть библиотека стандартных сообщений об ошибках «messages.properties», которую можно подгрузить, но также есть возможность настроить свой набор сообщений об ошибках. В нашем проекте это «my-messages.properties»:
javax.faces.component.UIInput.REQUIRED=Поле "{0}" не должно быть пустым.
mesMod = Вы должны указать ФИО модератора
mesEmp = Вы должны указать ФИО исполнителя
mesGroup = Вы должны указать группу
mesCl = Вы должны указать ФИО заказчика
mesAllFlds = Все поля должны быть заполнены
Параметр mesCl и путь к нему прописывается в файле auth_client.xhtml:
<f:loadBundle basename="trg.i18n.my-messages" var="msg"/> <!--путь к файлу с параметром и сообщением по нему-->
<p:selectOneMenu id="cllist" required="true" requiredMessage="#{msg.mesCl}" value="#{clientBean.clientId}" style="width:150px" styleClass="el-style"> <!—параметр сообщения, которое используется для данной страницы-->
Также файл «my-messages.properties» зарегистрирован в "faces-config.xml", на прикладном уровне:
<application>
<message-bundle>trg.i18n.my-messages</message-bundle> </application>
4. Обновление значений модели.
Обновление значений модели происходит автоматически, не нужно писать никакого кода, кроме привязки свойств значений объектов модели, прописанных в классах-бинах к компонентам пользовательского интерфейса. Каждая модель имеет свою область и время
жизни, управление которыми вызывает определенные сложности при увеличении количества моделей в программном коде.
5. Вызов приложения.
На этапе вызова приложения выполняется код методов action или actionListener, которые возвращают результат, передающийся затем обработчику навигации для осуществления перехода к другой странице.
6. Подготовка ответа к отображению.
И, наконец, в фазе подготовки ответа к отображению ответ кодируется и передается браузеру. Если пользователь каким-либо образом генерирует новый запрос, весь цикл начинается сначала.
Данный этап тоже является достаточно сложным, если структура интерфейсов не тривиальная. В нашем случае при использовании типового шаблона страницы происходит процесс сливания статического содержания шаблона с динамическим содержанием из разных компонентов пользовательского интерфейса, а также происходит взаимодействие с разными входными источниками и сборка их в единый видимый ответ. При использовании же технологии AJAX запрос добавляет входные компоненты к исполнению и выходные компоненты - к подготовке к отображению. Для компонентов, направленных на исполнение выполняются все фазы за исключением подготовки ответа к отображению, а для компонентов, находящихся в списке подготовки к отображению, выполняется фаза жизненного цикла подготовки ответа к отображению, результат передается обратно в запрос AJAX [4]. Управление данным этапом в нашем проекте усложнилось нетривиальностью подключения AJAX.
Одной из ключевых проблем стала проблема управления сессиями.
У нас возникала ошибка: org.hibemate.LazyImtializationException - could not initialize proxy - no Session. Оказалось, что с этой проблемой сталкиваются большинство новичков.
В нашем проекте используется lazy loading для доступа к объекту в базе, что позволяет получать лишь тот объект, который нужен, а все ссылки на другие mapped коллекции и сущности указывают на прокси.
LazylnitializationException означает, что обращение к коллекции происходит после закрытия сессии фреймворком hibernate или после того, как объект был отделен от сессии. Необходимо либо заново присоединить объект к сессии, либо изменить обращения к коллекции, либо увеличить время сессии. В нашем случае происходит обращение к mapped коллекции связей объекта после закрытия сессии, поэтому не удавалось инициализировать прокси-сервер.
Решением стало прописать в файле конфигурации Hibernate «hibemate.cfg.xml» строку <property name="hibemate.enable_lazy_load_no_trans">tme</praperty>
Указанное выше решение позволяет загружать lazy-ассоциации (ссылки объекта) за пределами транзакции, а это означает, что данные не будут согласовываться с какой-либо родительской сущностью. Таким образом, мы изменили обращение к коллекции.
Помимо этого, есть осознание, что в будущем при увеличении масштабируемости системы потребуется дополнительная разработка для управления сессиями, т.к. количество пользователей будет большим, понадобится большое количество серверов, и необходимо будет настраивать процесс хранения и передачи объектов.
Выводы
JSF - хороший фреймворк для проектирования систем новичками, с обширными библиотеками и хорошей документацией. Он подходит для быстрой разработки веб-приложений на Java и является интегрируемым с другими распространёнными фреймворками, такими как Spring security, Hibernate, Maven. Но из-за особенностей его архитектуры возникает риск, что, если понадобится решение каких-то задач, на которые он
не рассчитан, то разработка отнимет очень много времени и сил. В частности, есть набор нюансов при работе с сессиями, начиная с использования AJAX и интеграции с Hibernate, и заканчивая проблемами системного управления сессиями при увеличении масштабируемости системы.
Литература
1. PrimeFaces ShowCase [Электронный ресурс]. - Режим доступа: http://www.primefaces.org/showcase/ - Дата доступа: 26.04.2016.
2. Çivici Ç. PrimeFaces User Guide 5.3 [Электронный ресурс]. - Режим доступа: http://www.primefaces.org/docs/guide/primefaces user guide 5 3.pdf- Дата доступа: 26.04.2016.
3. Zeroturnaround [Электронный ресурс]. - Режим доступа: http://zerotumaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/ - Дата доступа: 26.04.2016.
4. Zeroturnaround [Электронный ресурс]. - Режим доступа: http://zeroturnaround.com/rebellabs/top-4-java-web-frameworks-revealed-real-life-usage-data-of-spring-mvc-vaadin-gwt-and-j sf/ - Дата доступа: 26.04. 2016
5. Zeroturnaround [Электронный ресурс]. - Режим доступа: http://javasource.ru:5050/articles.xhtml?artlink=jsf-lifecycle - Дата доступа: 26.04. 2016
УДК 004.89
НОТАЦИЯ ДЛЯ ПРОЕКТИРОВАНИЯ БАЗ ЗНАНИЙ ПРОДУКЦИОННЫХ
ЭКСПЕРТНЫХ СИСТЕМ910
Юрин Александр Юрьевич, к.т.н., ведущий научный сотрудник, заведующий лабораторией, Институт динамики и теории управления им. В.М. Матросова СО РАН (ИДСТУ СО РАН), Иркутск; доцент кафедры Института кибернетики им. Е.И. Попова, Иркутский национальный исследовательский университет (ИрНИТУ), Иркутск, iskander@icc.ru
Введение
Проектирование программного обеспечения для решения различных предметных задач требует создания специализированных программных инструментальных средств, новых подходов или расширения и модификации уже существующих.
Одной из разновидностей прикладного программного обеспечения являются экспертные системы (ЭС), моделирующие процесс рассуждения эксперта при принятии им решений. Центральным элементом ЭС является база знаний (БЗ), представленная множеством систематизированных знаний, описывающих закономерности какой-либо предметной области, при ее создании решаются задачи концептуализации, формализации и моделирования предметной области на определенном языке представления знаний. В настоящий момент можно выделить несколько направлений к повышению эффективности создания экспертных систем и систем, основанных на знаниях:
• Применение систем онтологического и когнитивного моделирования, CASE-средств (Protégé, FreeMind, Xebece, TheBrain, XMind, IBM Rational Rose, StarUML и др.), которые позволяют создать графические модели, соответствующие ключевым абстракциям программного обеспечения. Однако, большинство из подобных систем не охватывают все этапы создания баз знаний и экспертных систем и не обеспечивают
9 Работа выполнена при частичной финансовой поддержке РФФИ, проект № 15-07-03088
10 Лауреат номинации "Лучший доклад по UML-моделированию". Автор доклада награждается правом бесплатной публикации одного доклада по данной тематике на следующей конференции
48