CC BY
79
финансовых потерь, то налагается штраф, зависящий от времени просрочки g(T), где
N ni
T=ZZ v, •
i=i j=1
Таким образом, задача состоит в том, чтобы выбрать такой набор мероприятий для каждой операции, чтобы их проведение обеспечило достаточный уровень pA вероятности всего многостадийного процесса проектирования, при условии минимума затрат на проведение данного комплекса мероприятий и соблюдения технических требований и временных ограничений.
N ni ZZ j, „ G ' min i=1 j=1 (2)
N Щ П (pi „Z Zj APj ) > PA i=1 j=1 (3)
z,j > 0, j = 1,...,nt, i = 1,..., N (4)
' 0, если T < At, G = \ [g (T), в противном случае. (5)
Литература
1. Ребрин, Ю. И. Основы экономики и управления производством: Конспект лекций / Ю. И. Ребрин. - Таганрог: Изд-во ТРТУ, 2000. - 145 с.
2. Авсеева, О. В. К постановке задачи оптимизации проектирования систем специальной связи / О. В. Авсеева, А. Э. Говорский, Ю. Б. Тебекин, О. Я. Кравец // Информационные технологии моделирования и управления, № 7 (59), 2009. - Воронеж : Научная книга. - С. 945-949.
3. Авсеева, О. В Управление качеством системы специальной связи при автоматизированном
проектировании / О. В. Авсеева, Ю. Б. Тебекин, О. Я. Кравец // Труды всероссийской конференции «Новые технологии в научных исследованиях, проектировании, управлении, производстве». - Воронеж: ГОУВПО «Воронежский государственный технический
университет», 2010. - С. 64-66.
УДК 004.4.242
РАЗРАБОТКА ВЕБ-ПРИЛОЖЕНИЯ С ИСПОЛЬЗОВАНИЕМ МОДЕЛЬНООРИЕНТИРОВАННОГО ПОДХОДА
Пупыкина Анна Александровна, ведущий программист, Филиал Российского государственного гуманитарного университета в г. Тольятти, Россия, Тольятти, [email protected]
Введение
При разработке сложного программного продукта в настоящее время необходимо использовать средства автоматизации проектирования и разработки. Для того, чтобы сосредоточиться на бизнес-логике приложения, а не на реализации низкоуровневого функционала, применяется модельно-ориентированный подход (Model-Driven Development, MDD) разработки приложения. MDD относится к семейству подходов разработки, основанных на использовании модели в качестве первичного артефакта в жизненном цикле программного продукта. Разработчики используют модели для целого ряда задач: создания технического задания, анализа требований, генерации кода, тестирования, и многого другого.
Разработка пользовательского интерфейса часто становится неотъемлемой частью создания программного продукта. Инструменты MDD позволяют автоматически транслировать высокоуровневые спецификации в качественный код и документацию, что
116
дает преимущество в виде существенной экономии времени, необходимого для реализации информационных систем.
1. AndroMDA
Большинство имеющихся в настоящее время инструментов MDD используют подход трансформации модель-код основанный на шаблонах, например, OpenArchitectureWare, Acceleo, AndroMDA[1] и др. AndroMDA основана на шаблонах Velocity и XDoclet. Шаблон -это часть целевого кода, которая содержит мета-теги для доступа к содержанию исходной модели и для итерационного расширения кода.
AndroMDA на основе моделей UML, сохраненных в XMI формате и плагинов (картриджей и библиотек трансляций) создает пользовательские компоненты. Эта технология позволяет генерировать компоненты для любых языков программирования: Java, .Net, HTML, PHP, или других, для поддержки которых необходимо написать (или настроить существующий) плагин. При создании J2EE проектов есть возможность генерировать код для Hibernate, EJB, Spring, WebServices, и Struts. Сгенерированный код автоматически интегрируется в процессе сборки.
Схема базы данных может быть экспортирована в файл скриптов для создания базы данных приложения. Есть также простой способ отобразить модель существующей схемы базы данных, если база данных была уже создана.
Для того чтобы модели UML стали доступны плагинам, AndroMDA считывает эти модели в память. Плагины точно определяют, что будет генерировать AndroMDA. Каждый плагин полностью настраивается к специфичным потребностям проекта. PSM создается в процессе генерации кода и не доступна для модификации.
Современные приложения уровня предприятия разрабатываются на базе компонентов, взаимодействующих друг с другом и предоставляющих специальные функциональные возможности. Компоненты, которые выполняют подобные типы функций, сгруппированы в уровни. Эти уровни организованы как стек, в котором компоненты более высокого уровня используют службы компонентов уровня ниже. Компонент определенного уровня может использовать функциональные возможности других компонентов этого уровня или уровня ниже. На рис. 1 отображены различные прикладные уровни технологии Java, поддерживаемые AndroMDA.
Рис. 1 Прикладные уровни технологии Java, поддерживаемые AndroMDA
117
AndroMDA в настоящий момент предлагает два варианта технологий для создания уровня представления на базе web-компонентов: Struts и JSF. AndroMDA использует диаграммы состояний UML для того, чтобы определить, как страница изменяется, и сгенерировать Web-компоненты, которые соответствуют среде Struts или JSF.
Бизнес-уровень, генерируемый AndroMDA, состоит в основном из служб, которые конфигурируются, используя среду Spring. Бизнес-логика может быть добавлена в пустые методы классов, содержащих реализацию, создаваемые AndroMDA. Сгенерированные сервисы могут иметь интерфейс EJB. В этом случае сервисы должны быть развернуты в контейнере EJB. Сервисы могут быть Web-сервисами, предоставляющими клиентам платформо-независимый способ доступа к функциональным возможностям. AndroMDA может также генерировать бизнес-процессы и потоки данных для jBPM (входит в состав продукции JBoss).
Для генерации уровня доступа к данным AndroMDA использует распространенное объектно-реляционное средство отображения Hibernate. AndroMDA генерирует интерфейсы DAO (DAOs) для объектов, определенных в UML модели. Эти интерфейсы DAO используют Hibernate API, для того чтобы конвертировать записи базы данных в объекты и наоборот.
Так как AndroMDA генерирует приложения, использующие Hibernate, то в качестве хранилища данных можно использовать любую базу данных, которая поддерживается Hibernate.
2. Разработка интерфейса в AndroMDA
Существующие подходы обычно выделяют три уровня при модельно-ориентированной разработке Web-интерфейсов, ориентированных на обработку данных: уровень данных, который описывает структуру данных предметной области; уровень навигационных структур и уровень пользовательского интерфейса.
Кроме того, некоторые подходы предоставляют возможность описания настройки и адаптации содержимого и представления Web-интерфейса под конкретного пользователя. Часть из них выделяет представление и настройку в качестве отдельных уровней. Уровень представления отделяет задание содержимого Web-страниц от их стилей и форматирования, позволяя задавать различные представления для одного и того же информационного наполнения. Уровень настройки отделяет ее от других аспектов проектирования, облегчая работу разработчикам, которым не нужно принимать во внимание, что может быть подвергнуто настройке для конкретного пользователя, на этапе задания навигационных структур или интерфейса пользователя.
Моделирование Web-интерфейса в AndroMDA делается с помощью UML диаграмм вариантов использования и диаграмм состояния [2].
Уровень представления необходимо представить в виде одного или нескольких вариантов использования. Каждый вариант использования определяет свою специфическую логику. Типичными вариантами использования для веб-приложения являются «Войти», «Зарегистрироваться», «Добавить новый элемент», «Вывести отчет», «Найти». Для вариантов использования применяются два стереотипа UML. Стереотип FrontEndUseCase используется для прецедентов, которые представляют пользовательский интерфейс, и FrontEndApplication используется для указания входной точки веб-приложения.
Чтобы определить сценарий в рамках каждого варианта использования, используются диаграммы состояний. Для того чтобы связать диаграмму состояний с определенным вариантом использования, она должна быть определена как дочерний элемент соответствующего варианта использования. Для определения сценария с помощью диаграмм состояний UML AndroMDA использует следующие элементы: исходное состояние серверное состояние, клиентское состояние, переходы, помеченные значения (tagged value), конечное состояние.
Все вызовы бизнес-логики серверными состояниями должны быть определены в контроллерах. Класс контроллера должен быть задан как дочерний элемент диаграммы
118
состояний. Заглушки методов контроллера генерируются соответствующим картриджем. Разработчик должен реализовать логику этих методов.
3. Rich Internet Applications
Традиционные веб-приложения имеют большие ограничения по интерактивности и удобству пользования своих пользовательских интерфейсов. Новый вид веб-приложений -Rich Internet Applications (RIA) позволяет обойти эти ограничения. Этот тип приложений предлагает ряд преимуществ, например, обеспечивает более богатые и более эффективные графические интерфейсы, напоминающие настольные приложения. RIA - это сложные вебприложения на основе архитектуры толстого клиента с асинхронным взаимодействием и множеством виджетов пользовательского интерфейса. С одной стороны, клиент может управлять данными и процессами, а с другой стороны, сетевой трафик уменьшается из-за улучшения коммуникации. Оба нововведения позволяют повысить удобство пользования и возможность взаимодействия пользователей.
Разработка сложного программного обеспечения RIA требует более трудоемкого процесса разработки. Анализ требований позволяет справиться с определением различных функций, которые RIA может предложить пользователям. Дизайн RIA должен рассматривать различные типы архитектур и связи пользовательского интерфейса. Реализация RIA основывается на интеграции специальных библиотек, которые обеспечивают различные функции пользовательского интерфейса.
В настоящее время разработано множество фреймворков для создания RIA, которые помогают использовать передовые практики дизайна и повышают качество разработки. Примерами RIA фреймворков являются: ICEFaces, Dojo, GWT, Silverlight, Adobe Flash. Применение фреймворков позволяет автоматизировать наиболее трудоемкие задачи программирования как клиентской, так и серверной стороны приложения с помощью специальных примитивов, библиотек и кодогенерации, что обеспечивает повторное использование шаблонов для ускорения разработки. Наиболее быстро развиваются инструменты создания программных средств, которые автоматизируют реализацию типичного поведения. Однако каждая дополнительная автоматизация потенциально увеличивает сложность системы. Нарастающая сложность инструментов разработки может сдерживаться только за счет использования методологий разработки. Разработка сложного программного обеспечения без методологических подходов становится слишком сложным, дорогим и нерациональным процессом. Сильный междисциплинарный характер Интернетприложений только усугубляет эти проблемы. Методологии разработки позволяют повысить производительность, сократить усилия и затраты, улучшить обслуживание и развитие и создавать приложения, менее подверженные ошибкам. Разнообразие и сложность технологий и широкий спектр новых возможностей требуют переосмысления процессов Веб -разработки.
В последнее время было предложено несколько средств моделирования и модельноориентированных подходов для разработки RIA. В основе модельно-ориентированного подхода разработки RIA лежит модель языка, обеспечивающая элементы для моделирования отличительных особенностей RIA. В зависимости от уровня абстракции, требуются различные типы элементов. На бизнес-уровне должны быть определены элементы, которые позволяют описать компоненты, предоставляемые пользователям. На уровне проектирования этих компонентов необходимо их уточнить, например, более точно указать, как будет проходит взаимодействие пользователя и клиент-сервера. Наконец, при создании платформо-зависимой модели или на уровне кодирования, используемые технологии должны быть детализированы.
Выделяются четыре типа подходов поддержки разработки RIA [3]:
• Расширения уже существующих методов для моделирования компонентов RIA, дополнительных преобразований и специальных механизмов генерации (OOHRIA, OOHDM, UWE-R и WebML).
119
• Сочетание методов разработки веб-приложений с методами проектирования и генерации пользовательских интерфейсов (например, RUX в сочетании с WebML и UWE).
• Новые методы для разработки и реализации RIA (например, подход ADRIA или работа Martinez-Ruiz и др.).
• Паттерны как разработанные рекомендации на основе передового опыта (например, библиотеки предложенные Scott и Mahemoff и UML-паттерны предлагаемые UWE).
Программы научных исследований в области методологий разработки RIA включают в себя следующие элементы [4]:
• механизмы проектирования выразительных и компактных предметноориентированных языков и моделей для RIA из ортогональных абстракций (например, аспект ориентации);
• семантика RIA для верификации модели и поддержки тестирования;
• эффективные и прослеживаемые методы трансформации моделей и генерации кода;
• сквозные методологии разработки RIA.
Заключение
Таким образом, для того, чтобы Web-интерфейс был достаточно гибок и имел возможность оперативной настройки на меняющиеся условия, необходимо наличие механизма высокоуровневого средства моделирования предметной области и генерации Web-интерфейса. Данное средство должно выделять несколько уровней, а именно: уровень данных, уровень навигации и уровень пользовательского интерфейса.
Рассмотренный метод модельно-ориентированной разработки Web-интерфейса с помощью AndroMDA имеет ряд недостатков. Главным из которых является слабая поддержка разработки современных RIA приложений. Быстрое развитие технологий RIA, появление новых фреймворков и компонентов требует от инструментов модельноориентированной разработки открытого исходного кода, простых механизмов расширения и создания новых метамоделей и сценариев генерации кода.
Литература
1. AndroMDA homepage [Электронный ресурс]. Режим доступа:
http://www.andromda.org/index.php. свободный.
2. S.V. Vahid Gharavi, Model-Driven Development of AJAX Web Applications, Master’s thesis, Delft University of Technology, 2008
3. M. Busch, N. Koch, Rich Internet Applications State-of-the-Art, Technical Report, Ludwig-Maximilians-Universitat Munchen, 2009
4. P. Fraternali, G. Rossi, F. Sanchez-Figueroa, Rich Internet Applications, IEEE Internet Computing, vol. 14, no. 3, pp. 9-12, May/June 2010
УДК 681.518 Х70
ПРАКТИКА РАЗРАБОТКИ ТИПОВЫХ РЕШЕНИЙ ПО ОБЪЕКТНОРЕЛЯЦИОННОМУ ОТОБРАЖЕНИЮ ПРИ СОЗДАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ С ЭЛЕМЕНТАМИ УЧЕТНОЙ
ФУНКЦИОНАЛЬНОСТИ
Хозяинова Татьяна Вадимовна, ст. преподаватель, Ухтинский государственный технический
университет, [email protected]
В рамках практики создания информационных систем автору в составе коллективов разработчиков кафедры Информационных систем и технологий Ухтинского государственного технического университета (УГТУ) и Тимано-Печорского научноисследовательского центра (ТП НИЦ) пришлось столкнуться с необходимостью разработки
120
